Russ Allbery wrote:
> Michael Biebl <biebl@debian.org> writes:
Hi Russ
>> 1.) It's not the default on Debian anyway
>
> It is, however, a standard and supported option and it's the default in
^^^^^^^^
Hm, what standard exactly do you refer too.
> 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.
>> 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.
We will se such services more and more in the future (like it or not).
>> As I said, I don't see the benefit of a tmpfs for /var/run which would
>> justify this policy change so would very much appreciate to here valid
>> reasons for this change.
>
> Did you already read the Policy bug? It contains a rationale, although I
> don't know if it's a complete enough one for you.
I just skimmed over the bug report.
And I think it completely misses to justify, why it is a good idea to have tmpfs
on /var/run.
I provided a list of cons of tmpfs (you could probably also add, that it breaks
selinux). Is there actually a list of pros?
>> For people, that want to use a tmpfs for /var/run, there could be a
>> script on shutdown which backups (or copies) the content of /var/run and
>> restores it on boot
>
> I assume you mean only the directory structure? Otherwise, this would be
> an FHS violation.
Right, only the directories. would be as simple as tar -cpf /tmp/foo.tgz $(find
-type d)
> 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".
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