Steve Langasek wrote: > On Sat, Apr 04, 2009 at 01:14:51AM +0200, Michael Biebl wrote: >>> Ubuntu. The FHS is silent about directories in /var/run across reboots >>> but requires that all files in /var/run be deleted on reboot. > >>>> 4.) You have to manually cleanup in postrm. (I guess most packages will forget >>>> that, leaving cruft around) > >>> If you're creating any files in /var/run during the operation of the >>> package (and if not, why do you have a directory in /var/run in the first >>> place?), then you have to do this anyway, so this isn't new. (Well, I >>> suppose you could just rely on the next reboot deleting them, but that >>> doesn't feel very clean and I'm not sure that's really in the spirit of >>> our requirements.) > >> Not really. Say you have a pretty standard system daemon >> When the daemon is stopped in postinst, the pid file will be automatically >> deleted and dpkg will cleanup the remaining /var/run/$foo directory. > > I think he's referring to the fact that the FHS requires all files in > /var/run to be cleared on boot. We have an init script > (/etc/rcS.d/S36mountall-bootclean) that takes care of this at the system > level, though, on behalf of all packages; the trouble is it's a lot less > efficient, overall, to have to repeatedly clean /var/run on boot than it is > to just write it to a tmpfs and let the contents be lost on reboot. I think that is one of them main questions: Is it more efficient, to cleanup /var/tmp (i.e. remove everything besides directories) on boot in a single place (mountall-bootclean), or is it more efficient to use a tmpfs and let every package create it's run directory on boot. It's probably hard to tell without proper benchmarking. What can be said though is, that all packages that need a /var/run/ directory must be fixed. (for the numbers: maybe a new archive scan with the new lintian would help to see, how many packages are affected) so it at least requires work by the maintainers. >>>> 5.) If your package does not have an init script (I happen to maintain >>>> two such packages), I now have to create init scripts simply to create a >>>> /var/run directory. That's insane and even more wasting cpu cycles. > >>> Could you provide more details about what package without an init script >>> uses /var/run? The only other case that I can think of is packages that >>> create transient UNIX-domain sockets. > >> policykit is such an example. Potentially as D-Bus system bus activated system >> services are affected by this, because they (usually) don't ship any init script. > > $ grep -A4 'start)' /etc/init.d/policykit > start) > mkdir -p /var/run/PolicyKit > chown root:polkituser /var/run/PolicyKit > chmod 770 /var/run/PolicyKit > ;; > $ > > That's what I have on an Ubuntu system; why can't the Debian package do the > same? Sure it can. But I consider this solution very ugly and refused to do this so far. For the reasons already mentioned it also makes the (previouly init system agnostic) D-Bus service dependend on sysv-rc. > (Yes, this is the only function of this init script. But still, either you > create the directories on boot or you have to clean all the files on boot.) > >> We will se such services more and more in the future (like it or not). > > No. Services that work that way are Doing It Wrong, and we should not > accept this as inevitable. Ok, what do you think are they doing wrong: Being started on-demand via D-Bus, i.e. not shipping a sysv init script? >> I provided a list of cons of tmpfs (you could probably also add, that it >> breaks selinux). Is there actually a list of pros? > > "Probably"? In what case does this break selinux? I'm not a selinux expert, but I read somewhere, that the security context is lost, so you'd have to relabel the directory. I don't know, how costly that operation is (and if this is necessary for a directory in /var/tmp). Maybe Russell or Manoj can chime in here, if they read this. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature