Re: Bug#39005: Mail loss over NFS with Kernel 2.2.*
Miquel van Smoorenburg <miquels@cistron.nl> wrote:
>>I sent a copy of this message to debian-devel, because I think, that
>>this means, that all mail accessing programs should be changed to
>>use fcntl() in addition to dotlock! Maybe I should file bug reports
>>against all mail locking applications?
> No, first have the policy changed, _then_ file bug reports.
Oh, we don't have to change policy for this, you (as the maintainer of
liblockfile) only have to change this library and all other programs
have to change to keep compatible :-)
That's why the policy doesn't say how the looking should be
implemented, but it only says, that every program should use
liblockfile or some compatible mechanism:
All Debian MUAs and MTAs have to use the `maillock' and `mailunlock'
functions provided by the `liblockfile' packages to lock and unlock
mail boxes. These functions implement a NFS-safe locking mechanism.
(It is ok if MUAs and MTAs don't link against liblockfile but use a
_compatible_ mechanism. Please compare the mechanisms very carefully!)
The strange effect here is, that I didn't find some documentation, how
liblockfile implements locking, but had to look into the source to
find out, that it doesn't use fcntl().
I fear that not using fcntl() for locking is not NFS-safe with kernel
2.2.* involved, so liblockfile doesn't follow policy ("These functions
implement a NFS-safe locking mechanism.") and should file a bug
against it. If you fix this bug, all other mail programs have to be
changed, if they don't link against liblockfile.
> Also make sure you specify in which order the different types of
> locking and unlocking have to take place, to prevent deadlocks!
IMHO this should be specified in the policy or at least in the
liblockfile documentation (which should be referenced in the policy).
> That probably means checking existing practice by reading a lot of
> source code.
I know the problems. But if we want to make kernel 2.2.* the default
kernel in potato, we should use a NFS safe locking mechanism! The
actual one isn't and I'm not sure whether a plain (unpatched) kernel
is able to support correct locking (at least it doesn't work without
Olaf's patch when the server runs 2.0.* while the client runs 2.2.*).
Tschoeeee
Roland
--
* roland@spinnaker.de * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Reply to: