On Mon, 04.04.11 10:56, Ludwig Nussel ([email protected]) wrote: > > Lennart Poettering wrote: > > On Fri, 01.04.11 16:37, Ludwig Nussel ([email protected]) wrote: > > > In any case declaring some directory as the standard place for lock > > > files doesn't fully solve the problem anyways. The exact lock file > > > naming isn't quite standardized either. There's at least the FHS > > > "LCK..name" method and the SVr4 "LK.dev.maj.min" method. > > > > I have never seen LK.x.y.z files. Documentation link? > > http://www.airs.com/ian/uucp-doc/uucp_7.html#SEC86 > http://www.columbia.edu/kermit/ckuins.html#x10 > > > It's one thing extending the base that the FHS describes in a distro, > > it's another thing dropping things that it defines, such as the > > /var/lock directory. > > > > Now, the only improvement on the brokeness of LCK..xxx style locks we > > can pull off easily is seperating them from the other stuff that is > > stored in /var/lock. And this is usually simple (compile time switches > > in various programs), and actually implemented in Fedora. > > > > I hope this makes some sense. > > So as long as there are no inherently unsolvable problems > with lockdev using /var/lock directly I see no need to go the a half > solution /var/lock/lockdev.
There are. A lot of software creates subdirectories beneath /var/lock, for example LVM. If you allow creation of lockfiles in /var/lock, then this enables the same programs to break LVM (and everything else creating subdirs there), and even use LVM to break the system even further. That's the point that https://bugzilla.redhat.com/show_bug.cgi?id=581884 tries to make. > I'd rather add an rpmlint check to ban > use of /var/lock/subsys on openSUSE, there are only a few packages > using it anyways. On Fedora and a lot of other distros /var/lock/subsys is used by the main RC script to synchronize execution of SysV scripts. > How many packages in Fedora that did not use lockdev already were > actually patched to use /var/lock/lockdev anyways? No idea, this happened before my time. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
