On Tue, 16.07.13 03:24, Michael Biebl (mbi...@gmail.com) wrote: > Hi, > > an interesting issue was raised as part of reviewing a patch for > iodione [1], a system service which needs a runtime directory. We > thought this might need further dicussion, so reposting the issue to > systemd-devel: > > For system services needing a runtime directory, we basically have two > (three) options nowadays > 1/ use ExecStartPre=/usr/bin/mkdir /var/run/foo > 2/ use a tmpfile snippet > (3/ let the daemon create the runtime directory itself) > > In [1] we recommended the the usage of 2/ over 1/. > The main reason for that were, that systemd-tmpfiles properly handles > applying security policies, like SELinux labels, and it avoids > spawning unnecessary processes (every ExecStartPre=/usr/bin/mkdir is a > separate process)
I tend to agree with this. > Zbyszek is arguing, that splitting the configuration over two files, a > tmpfile and a service file, complicates things for the administrator, > as things are no longer in a single place. > He also argues, that tmpfiles are active, independently of the > service, which needs them. Which can lead to unused runtime > directories. I am not too concerned about unused runtime directories. After all this is not something that would (or even could) grow without bounds. There will never be more than O(n) runtime directores for n being the number of packages you have installed (or had installed). We will always need setting up of tmpfiles during boot, as many clients expect certain directories to be existant in /run without any specific daemon running. Thus, we couldn't move this stuff into service files --- we could only allow both. However, I am not convinced that allowing tmpfiles to be denoted in unit files would be a good thing though, because it sounds unnecessary. It really sounds as if the daemons which need that should rather create the directories on their own before making use of them. This should generally be the most robust solution. And in such a case there's no need to denote anything about this in the unit files at all... I mean, this is the general recommendation anyway: if possible just fix the daemon to create the dirs as it needs it. Use tmpfiles only if that's not feasible, maybe because the daemon never runs privileged code or because the dirs need to exist at boot already. Something I'd love to see though is if we could make it easier to apply tmpfiles stuff automatically on package installation. More specifically, I'd like an RPM macro to be added that handles this, and which is sufficient for packagers to call for their tmpfiles. ALl in order to ensure that the user can invoke the services right after package installation without requiring a reboot. > One suggestion that came up was, to specficy runtime directories in a > declarative fashion in the .service file itself, which means it would > be only be created if the service itself is enabled. The way I see tmpfiles is that they don't actually do anything active, they just reserve some space where something else then does something active. It just sets up working areas, and doesn't actually play in them. As such the impact, the cost of tmpfiles is minimal. It's like installing a package and then not using it, i.e. you have stuff lying around that is dead, but prepares everything for the time when you actually want to run it, not more. If you want to get rid of the runtime dirs (or the normal packaged files) you should just remove the package in question... I hope this makes some sense? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
