[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fetchmail: does it lock ? I don't think so.
On Sat, Feb 06, 1999 at 05:56:20PM +0200, Peter L. Peres wrote:
>
> It's me again (g). I am trying to set up fetchmail in a way that
> prevents it from losing mail. Question: does fetchmail lock itself/its
> session so another fetchmail won't run concurrently with it (assuming
> retrieval from multiple hosts) or does the POP/other daemon have the
> responsability to maintain atomicity ? The fetchmail runs as some user but
> a root crontab script can fight with it. The docs say that there is a
> per-user lock when running.
This is true and verifiable. Even if it weren't, there would still be
no risk on the local spool side of things, because fetchmail doesn't
do delivery itself but rather forwards mail to your local sendmail (okay,
whatever MTA you happen to be running :)
> What happens when more than one client tries to access the same mailbox
> on a POP3 etc server ? Is this documented somewhere ? In the protocol RFCs
> ?
On the server side, the server is naturally reqponsible to lock the
mailbox. It would be sad indeed if this was the client's job!
>From RFC 1939:
Once the POP3 server has determined through the use of any
authentication command that the client should be given access to the
appropriate maildrop, the POP3 server then acquires an exclusive-
access lock on the maildrop, as necessary to prevent messages from
being modified or removed before the session enters the UPDATE state.
If the lock is successfully acquired, the POP3 server responds with a
positive status indicator. The POP3 session now enters the
TRANSACTION state, with no messages marked as deleted. If the
maildrop cannot be opened for some reason (for example, a lock can
not be acquired, the client is denied access to the appropriate
maildrop, or the maildrop cannot be parsed), the POP3 server responds
with a negative status indicator. (If a lock was acquired but the
POP3 server intends to respond with a negative status indicator, the
POP3 server must release the lock prior to rejecting the command.)
After returning a negative status indicator, the server may close the
connection. If the server does not close the connection, the client
may either issue a new authentication command and start again, or the
client may issue the QUIT command.
> What is the most popular locking method excepting lock files for a
> non-file resource such as a database or table ? A registry + a set of
> methods ? (flameproof suit on). If I remember well, in Linux syscalls are
> interruptible so simple lock files are a bad idea anyway, no ?
I'm sure there are quite a few people better-qualified to answer
this one on the list but... my shot:
1. don't put your mail folders (and certainly not your spool) on NFS
("yeah right" #1)
2. use procmail to do the actual delivery, not sendmail. put procmail
in your sendmail.cf . procmail is bulletproof. procmail is good for
you. etc.
3. "A registry + a set of methods" sounds like an application solution;
never trust applications to do things your OS can do for them.
4. use kernel mandatory locking?
> PS: This question is directly related to Linux of course.
Naturally. <g>
gaal