Re: Policy wrt mail lockfile (section 4.3)
Lars Wirzenius wrote: [replying to the list instead of privately, since this is of common interest, IMHO :-] If the protocol in the publib library has a way to get around that problem, I'd be interesting in learning more about it (and, possibly, dreaming up cases in which it might fail :-) I don't know if it does, but it tries. Please do find any problems. Here's the code: [...] fndir(dir, lockname); fnjoin(tempname, dir, .temp-lock); fd = open(tempname, O_CREAT | O_EXCL, 0600); if (fd == -1) return -1; This can create a lockfile that is never deleted. Consider the following case: Client code does open(tempname, O_CREAT | O_EXCL, 0600); Client kernel translates this into a NFSPROC_CREATE RPC call and sends it out on the wire as a UDP packet. Server receives the RPC call and executes it via doing an open(tempname, O_CREAT | O_EXCL, 0600) itself; the lockfile is created. Server sends back the the acknowledgement of success via a UDP package. UDP package is lost on the wire. Client kernel receives no confirmation and re-transmits the NFSPROC_CREATE request. Server receives RPC call and does open(tempname, O_CREAT | O_EXCL, 0600); This call fails; server transmits back indication of failure. Client user-space code sees call to open(tempname, O_CREAT | O_EXCL, 0600) fail and thinks that somebody else has already locked things. Result: oops... There is a - partial - way around this. Each RPC call is accompanied with a unique 32-bit number, the xid. A server can cache the first request and simply send back a done successfully if it sees the same (hostname,xid) tuple again within a certain time. However, there is no guarantee in the NFS protocol that this is indeed being done (and I don't know wether the current Linux nfsd does indeed follow that strategy). This will also not survive a server crash, and there is no way to enquire wether the server does support xid caching. -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
Christian == Christian Schwarz [EMAIL PROTECTED] writes: What happens? Can you describe the problem? Explain your setup in more detail, please. I would like to know more about the problems that are encountered with nfs. Christian The servers receives all mails from the Internet Christian through sendmail (via UUCP). I have a .forward on my Christian account to transfer all mails to procmail. procmail Christian sorts the Debian mailing lists out (puts them in Christian specific folders). All other mails are stored in Christian /var/spool/mail/schwarz. If you make `procmail' your local mailer, with FEATURE(local_procmail)dnl ... in /etc/sendmail.mc, then run sendmailconfig on it, you won't need a .forward anymore, and your .promailrc will get run through procmail automaticly. It's a lot more efficient this way, I think. Christian When I access that folder with pine exactly when Christian procmail modifies it (this happens frequently!) pine Christian complains about some other process modifying his Christian folder and aborts. I guess that Pine doesn't conform to our locking policy. It should see that the file is 'locked' and block until the .lock to goes away. I've never used `pine'. Is there a setting to have it do this? I'm using Gnus, in XEmacs,[1] to read my mail now. In the Gnus info manual, I found settings for using procmail delivery folders, so that Gnus will honor the locking files. It took a short afternoon to set up, and I really like it. It's got the advantage of putting newsgroups and email in the same interface. And, in XEmacs, it's fully MIME capable, with sound and pictures and everything. (I've got to quit advertising.) Footnotes: [1] It's also in Emacs. -- Karl M. Hegbloom [EMAIL PROTECTED] finger or ytalk: http://www.inetarena.com/~karlheg [EMAIL PROTECTED] Portland, OR USA Debian GNU 1.3 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
Miquel == Miquel van Smoorenburg [EMAIL PROTECTED] writes: Miquel I now have open() in a preloaded library, /lib/nfslock.so Miquel that gets preloaded on all our machines through Miquel /etc/ld.so.preload. Does about the same thing, and lets us Miquel safely share mail over NFS. A bit (a bit?!) of a hack, Miquel though. May we have it? Please? -- Karl M. Hegbloom [EMAIL PROTECTED] finger or ytalk: http://www.inetarena.com/~karlheg [EMAIL PROTECTED] Portland, OR USA Debian GNU 1.3 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
According to Karl M. Hegbloom: Miquel == Miquel van Smoorenburg [EMAIL PROTECTED] writes: Miquel I now have open() in a preloaded library, /lib/nfslock.so Miquel that gets preloaded on all our machines through Miquel /etc/ld.so.preload. Does about the same thing, and lets us Miquel safely share mail over NFS. A bit (a bit?!) of a hack, Miquel though. May we have it? Please? Sure, at your own risk.. it really is a hack, you know. It's at ftp://ftp.cistron.nl/pub/people/miquels/nfslock/ Mike. -- | Miquel van Smoorenburg | I need more space Well, why not move to Texas | | [EMAIL PROTECTED] | No, on my account, stupid. Stupid? Uh-oh..| | PGP fingerprint: FE 66 52 4F CD 59 A5 36 7F 39 8B 20 F1 D6 74 02 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
John Goerzen [EMAIL PROTECTED] writes: However, why is it bad if a given program (like Elm-ME+ which I maintain, which brought the issue to my attention this time) uses *both* locking mechanisms? The only problem I know of is that with two locking schemes, if all programs don't agree on the schemes and the order of their use, you can end up with nasty deadlock situations. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
[EMAIL PROTECTED] said: Hmm, but why would that cause a problem with mailers/programs that use lockfile locking *and* flock/fcntl locking at the same time? Last time this discussion came up, Bruce found some info in the debian mail archive related to this. Can't find it now, though. If I remember correctly, the problem is that flock/fcntl locking on NFS mounted filesystems can cause complete lockup ( :-) ) of the process. cheers, Lukas --- Dr. Lukas Nellen | Email: [EMAIL PROTECTED] Depto. de Fisica Teorica, IFUNAM | Apdo. Postal 20-364 | Tel.: +52 5 622 5166 01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
In article [EMAIL PROTECTED], Lars Wirzenius [EMAIL PROTECTED] wrote:
--==_Exmh_970021023P
Publib uses the return value from the stat call, which
you're not supposed to do. (I don't know why yet.)
I check that the link count is two to see if I managed to create
the lock file with link(2). If the stat fails, I can't check
the link count. I _must_ check the return of the stat.
The link count is not guaranteed to be updated because of inode
caches etc. Really.. The only thing you can do is stat the original
file and the link, and compare dev/ino pairs. Only then you're sure
the link() call succeeded.
As I said before, the implementation in qpopper-2.2-4 is IMO correct.
Looking at the code now, I only see one problem and that is:
time(now);
/* Locks are invalid after 5 minutes. */
if (now st.st_ctime + 300)
continue;
It should really do
/* Locks are invalid after 5 minutes. */
if ((fd = open(lockfile, O_RDONLY)) = 0) {
(void)read(fd, 1, buf);
fstat(fd, st1);
now = st1.st_atime;
close(fd);
} else
time(now);
if (now st.st_ctime + 300)
continue;
To compensate for when the clocks of the 2 systems are out of sync.
Mike.
--
| Miquel van Smoorenburg | I need more space Well, why not move to Texas |
| [EMAIL PROTECTED] | No, on my account, stupid. Stupid? Uh-oh..|
| PGP fingerprint: FE 66 52 4F CD 59 A5 36 7F 39 8B 20 F1 D6 74 02 |
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
In article [EMAIL PROTECTED], Lars Wirzenius [EMAIL PROTECTED] wrote:
--==_Exmh_970021023P
Content-Type: text/plain; charset=us-ascii
[ Please don't Cc: public replies to me. ]
Karl M. Hegbloom:
What happens? Can you describe the problem? Explain your setup in
more detail, please. I would like to know more about the problems
that are encountered with nfs.
When you try to create a lock file with open(2) using O_CREAT|O_EXCL
(i.e., you ask the kernel to create the file, but fail if it exists
already), the operation will sometimes fail, when you network drops
a packet. That operation simply isn't guaranteed to work over NFS,
even though it is for normal Unix filesystems.
It's more the case that the O_EXCL flag doesn't exist in the NFS protocol.
So the operation is not atomic. The kernel itself does:
[pseudo code]
if (flags O_EXCL) {
if (stat(file) = 0)
return EEXIST;
}
return open (file, flags);
This is atomic on local file systems but not on NFS file systems. Usually
it will work, but I tested it by running a program repeatedly getting
a lockfile on 2 computers on a NFS mounted file system, and every once
in a while this method fails, as you would expect ofcourse.
I once wrote a patch where the kernel does:
if (flags O_EXCL) {
/*
* Here the kernel uses a method with link() ing to the
* file, similar to NFS mailbox locking, to create the
* file atomically
*/
...
...
}
return open (file, flags);
It worked like a charm, but Linus wouldn't accept it in the kernel.
Too bad, all of our problems would have been solved..
I now have open() in a preloaded library, /lib/nfslock.so that gets
preloaded on all our machines through /etc/ld.so.preload. Does about
the same thing, and lets us safely share mail over NFS. A bit (a bit?!)
of a hack, though.
Mike.
--
| Miquel van Smoorenburg | I need more space Well, why not move to Texas |
| [EMAIL PROTECTED] | No, on my account, stupid. Stupid? Uh-oh..|
| PGP fingerprint: FE 66 52 4F CD 59 A5 36 7F 39 8B 20 F1 D6 74 02 |
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
On 20 Jun 1997, Karl M. Hegbloom wrote: Christian == Christian Schwarz [EMAIL PROTECTED] writes: Christian This is buggy since it's not working over NFS. (I'm Christian running into problems every few days since I use Christian sendmail/procmail/pine over a NFS mounted Christian /var/spool/mail !) Christian That's the exact reason why I started this discussion Christian again. What happens? Can you describe the problem? Explain your setup in more detail, please. I would like to know more about the problems that are encountered with nfs. I have a server running Debian 1.2.x, sendmail 8.8.5-1, procmail 3.10-4 and a client running Debian 1.3, pine 3.96L-2. The servers receives all mails from the Internet through sendmail (via UUCP). I have a .forward on my account to transfer all mails to procmail. procmail sorts the Debian mailing lists out (puts them in specific folders). All other mails are stored in /var/spool/mail/schwarz. When I access that folder with pine exactly when procmail modifies it (this happens frequently!) pine complains about some other process modifying his folder and aborts. Thanks, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
John Goerzen [EMAIL PROTECTED] writes: Why are we using dotfile locking only? There are much better mechanisms (flock, etc.) that should be used instead. I can see no place where dotfile locking would work and flock-style locking would fail... I think flock can fail across NFS in certain situations, but I'm no locking expert. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
John Goerzen wrote: Why are we using dotfile locking only? There are much better mechanisms (flock, etc.) that should be used instead. I can see no place where dotfile locking would work and flock-style locking would fail... We don't have a lock daemon for NFS. -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
Rob == Rob Browning [EMAIL PROTECTED] writes: Rob I think flock can fail across NFS in certain situations, but Rob I'm no locking expert. You can read the man page to open(3) for a partial explaination. -- Karl M. Hegbloom [EMAIL PROTECTED] finger or ytalk: http://www.inetarena.com/~karlheg [EMAIL PROTECTED] Portland, OR USA Debian GNU 1.3 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
On Fri, 20 Jun 1997, Lars Wirzenius wrote: [ Please don't Cc: public replies to me. ] John Goerzen: Why are we using dotfile locking only? There are much better mechanisms (flock, etc.) that should be used instead. I can see no place where dotfile locking would work and flock-style locking would fail... NFS. Scripts that use procmail's lockfile. (If it doesn't already, the policy manual should explain the reasons behind policy. I'd check if it does, but I don't have a copy and am offline.) The current policy manual (2.1.3.3) only says: Mailboxes are locked using the username.lock lockfile convention, rather than fcntl, flock or lockf. This is buggy since it's not working over NFS. (I'm running into problems every few days since I use sendmail/procmail/pine over a NFS mounted /var/spool/mail !) That's the exact reason why I started this discussion again. AFAIK, there is at least one safe way to lock a file over NFS. The procedure is partially explained in the open(2) man page and is also implemented, for example, in your publib library. Since the procedure is not that simple, I suggested to provide a shared library that the other packages could be linked against, so that not every maintainer has to program this on his/her own (this is likely to produce new bugs!). And I suggested to produce modules for Perl/Python etc. Someone else mentioned that the UN*X (at least Linux) world is laking such a library and we should therefore build not a debian specific lib, but a new upstream library which can be used by the other distributions as well. IMHO, that's a very good idea. Note, that all programs will have to use the same locking mechanism (this has been discussed before). Thus, we should implement the simpliest available algorithm that is NFS-safe, since a few maintainers will probably need to hand-code this themselves (for example, for other programming languages, etc.). There are also tools available, that do locking, for example lockfile in the procmail package. However, calling this program with system produces IMHO too much unnecessary overhead and the source code of this program is a bit to complicated to force all our developers to implement this. IMHO, the code in publib looks very good. I suggest that we extract the necessary files and put them together in a new package, called liblockfile (or similar). This package should install a shared library liblockfile.so that contains a few necessary commands to lock/unlock/test a file. In addition, we could create a new lockfile binary (just as in procmail) that can be used by shell scripts or other programs (via system). We'll also provide modules for Perl/Python/etc. Any comments? (I feel like I presented these arguments several times now on this list, but we've not got any results so far.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
: Mailboxes are locked using the username.lock lockfile convention, rather : than fcntl, flock or lockf. : This is buggy since it's not working over NFS. (I'm running into problems : every few days since I use sendmail/procmail/pine over a NFS mounted : /var/spool/mail !) I am using exim/exim/pine here over NFS mounted /var/spool/mail for around 1000 users with no problems at all. Some of the gizmos you are using might have a problem with the lock scheme. I know that exim is pretty reliable with its locking and I also use exim instead of procmail (build in mailfilter). -- --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- Please always CC me when replying to posts on mailing lists. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
Christian == Christian Schwarz [EMAIL PROTECTED] writes: Christian This is buggy since it's not working over NFS. (I'm Christian running into problems every few days since I use Christian sendmail/procmail/pine over a NFS mounted Christian /var/spool/mail !) Christian That's the exact reason why I started this discussion Christian again. What happens? Can you describe the problem? Explain your setup in more detail, please. I would like to know more about the problems that are encountered with nfs. Christian There are also tools available, that do locking, for Christian example lockfile in the procmail package. However, Christian calling this program with system produces IMHO too Christian much unnecessary overhead and the source code of this Christian program is a bit to complicated to force all our Christian developers to implement this. Unix is designed around peicing things together from small utility programs, and fork/exec/wait probably doesn't really cost that much... on the other hand, putting the lockfile stuff into a shared library is more estheticly appealing. Christian IMHO, the code in publib looks very good. I suggest Christian that we extract the necessary files and put them Christian together in a new package, called liblockfile (or Christian similar). This package should install a shared library Christian liblockfile.so that contains a few necessary commands Christian to lock/unlock/test a file. Solaris has a maillock library that is cloned in `qpopper'. A manual page for Sun's maillock can easily be found on the web. I think that qpopper's algorithm is superiour to the one in publib. Will you have a look at it? Publib uses the return value from the stat call, which you're not supposed to do. (I don't know why yet.) Christian In addition, we could create a new lockfile binary Christian (just as in procmail) that can be used by shell scripts Christian or other programs (via system). I guess we should mimic the maillock library, but add a more general function for creating a lock for any file, not just mail spools. How does DCE do it, I wonder? I found libuuid in the ext2fsprogs. What's a lockd do? I will search for that today. Christian We'll also provide modules for Perl/Python/etc. Can you use SWIG for that, once we make a .so? -- Karl M. Hegbloom [EMAIL PROTECTED] finger or ytalk: http://www.inetarena.com/~karlheg [EMAIL PROTECTED] Portland, OR USA Debian GNU 1.3 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
This sounds good to me. When finished, we should announce this on c.o.l.a. and try to see if the Red Had folks will adopt it as well. If we both adopt it as policy, then it will live on forever! -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- On Fri, 20 Jun 1997, Lars Wirzenius wrote: [ Please don't Cc: public replies to me. ] John Goerzen: Why are we using dotfile locking only? There are much better mechanisms (flock, etc.) that should be used instead. I can see no place where dotfile locking would work and flock-style locking would fail... NFS. Scripts that use procmail's lockfile. (If it doesn't already, the policy manual should explain the reasons behind policy. I'd check if it does, but I don't have a copy and am offline.) The current policy manual (2.1.3.3) only says: Mailboxes are locked using the username.lock lockfile convention, rather than fcntl, flock or lockf. This is buggy since it's not working over NFS. (I'm running into problems every few days since I use sendmail/procmail/pine over a NFS mounted /var/spool/mail !) That's the exact reason why I started this discussion again. AFAIK, there is at least one safe way to lock a file over NFS. The procedure is partially explained in the open(2) man page and is also implemented, for example, in your publib library. Since the procedure is not that simple, I suggested to provide a shared library that the other packages could be linked against, so that not every maintainer has to program this on his/her own (this is likely to produce new bugs!). And I suggested to produce modules for Perl/Python etc. Someone else mentioned that the UN*X (at least Linux) world is laking such a library and we should therefore build not a debian specific lib, but a new upstream library which can be used by the other distributions as well. IMHO, that's a very good idea. Note, that all programs will have to use the same locking mechanism (this has been discussed before). Thus, we should implement the simpliest available algorithm that is NFS-safe, since a few maintainers will probably need to hand-code this themselves (for example, for other programming languages, etc.). There are also tools available, that do locking, for example lockfile in the procmail package. However, calling this program with system produces IMHO too much unnecessary overhead and the source code of this program is a bit to complicated to force all our developers to implement this. IMHO, the code in publib looks very good. I suggest that we extract the necessary files and put them together in a new package, called liblockfile (or similar). This package should install a shared library liblockfile.so that contains a few necessary commands to lock/unlock/test a file. In addition, we could create a new lockfile binary (just as in procmail) that can be used by shell scripts or other programs (via system). We'll also provide modules for Perl/Python/etc. Any comments? (I feel like I presented these arguments several times now on this list, but we've not got any results so far.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
Rob Browning [EMAIL PROTECTED] writes: John Goerzen [EMAIL PROTECTED] writes: Why are we using dotfile locking only? There are much better mechanisms (flock, etc.) that should be used instead. I can see no place where dotfile locking would work and flock-style locking would fail... I think flock can fail across NFS in certain situations, but I'm no locking expert. Hmm, but why would that cause a problem with mailers/programs that use lockfile locking *and* flock/fcntl locking at the same time? -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
-BEGIN PGP SIGNED MESSAGE- On 20 Jun 1997, John Goerzen wrote: I think flock can fail across NFS in certain situations, but I'm no locking expert. Hmm, but why would that cause a problem with mailers/programs that use lockfile locking *and* flock/fcntl locking at the same time? You create fun deadlocks when one program does it lockfile/flock and the other does it flock/lockfile. ++ | Scott K. Ellis | Argue for your limitations and | | [EMAIL PROTECTED] | sure enough, they're yours. | ||-- Illusions | ++ -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv iQCVAwUBM6rjeKCk2fENdzpVAQFN+gP+NAomXn0fmPG4YIYb4ObdHTHYuvmwMCsO xcJ+EYPxFcBvMY/p4FG7S8Nj0ToAAkcM3Lj6vZ/ox2sjnHVX/dNd9U/WBbzgdhKB RiYRoLMp/G7kI9P3qW4gGDT08O0IHOxnX5sVC7es+6jE8gySsH+vRlHHU5vnhxlF WX2BX3ih1dY= =x6Jq -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
