[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)



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.

> >> 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?

(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.

> 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?

> > Personally, I'm not inclined to revert this change.  I think it's correct
> > and continues to be correct, and I'd rather not undo the work that's
> > already been put into making it work.  This was added to Policy in part
> > because of various bug reports against packages not working as expected,
> > so removing it from Policy won't make those bug reports go away again.
> > And I think it's better to fix the packages than to add something to
> > preserve /var/run directories across boot, which seems like a hack to me.

> Not more of a hack than adding init scripts which do nothing else then creating
> /var/run/foo, with the added benefit that only the users (minority) which
> actually use RAMRUN would have to live with this "hack".

I would like to see /var/run become the default on Debian as well,
eventually...

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org


Reply to: