[systemd-devel] binding tmpfiles.d to unit startup
Colin Walters
walters at verbum.org
Sat Mar 1 11:46:15 PST 2014
On Sat, Mar 1, 2014 at 2:18 PM, Tom Gundersen <teg at jklm.no> wrote:
> And a bit further down that thread there was this proposal from Lennar
> (which doesn't seem far from what Colin wants):
> <http://lists.freedesktop.org/archives/systemd-devel/2013-July/012024.html>.
>
Right...so rereading that, the discussion seemed to peter out after:
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012090.html
I see Michael's point here as well:
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012037.html
Certainly it magnifies the pain for the RPM world in that there's
nothing that scans the build directory and says "hey you installed
something that looks like a tmpfiles.d snippet, let me auto-generate
some postinst shell script".
I think any postinsts like this are still pretty ugly though. It means
the directories are created when the daemon is *installed*, not when
it's run. Which is odd and against the generally dynamic nature of
systemd.
Also, running shell script as root is just full of fail, sorry package
people =) Even if it's auto-generated from a centrally maintained
place.
I admit this is sometimes what you want, e.g. if you need a way to
install postgres and then restore a dump file from backup *before*
starting it. Those cases could be covered of course by an
administrator doing a mkdir manually and if they're careful about
SELinux, using restorecon.
So basically here'd what I'd propose, which is an extension of
Lennart's:
RuntimeDirectory=/run/mydaemon
PersistentStateDirectory=/var/lib/mydaemon
We could cover a lot of simple cases with that - default to being owned
by User= and mode 0700, and have RuntimeDirectoryMode= and
PersistentStateDirectoryMode= to override that last bit.
Note - the previous discussion seemed largely about /run, but I am most
interested in real permanent directories in /var.
The primary goal again for me is that I can rm -rf /var/* and reboot,
and have the system be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140301/529559ab/attachment.html>
More information about the systemd-devel
mailing list