On Sun, 12.04.15 16:46, Elias Probst (m...@eliasprobst.eu) wrote: > On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: > > I'm wondering if we should provide better per-user tmpfiles support. > > For example, if we allowed a set of "user" tmpfiles, which would > > be executed by the system instance, but would be considered relative to > > the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home > > directory, > > %t to XDG_RUNTIME_DIR, ...). We would execute that for every user. > > Which makes me wonder again, why tmpfiles.d was never implemented in the > way all other units are implemented. > Currently, it's impossible to declare a dependency of a service upon a > tmpdir, which feels out of line with the way things are usually handled > in a systemd-based system. > > For example: > OpenVPN requires /run/openvpn/ to exist before being able to start. > This leads to the following possible scenarios to make OpenVPN usable on > a system where OpenVPN was just installed (and there was no reboot to > trigger tmpfiles.d creation) yet:
It should just create the dir on its own. Invoking the mkdir() syscall is hardly the most complex thing in the world. If it's really about just this dir, it's certainly easier to make openvpn just invoke one more syscall than to add a tmpfiles snippet an RPM scriplet invocation and whatnot else. Also, it's much easier for everybody to grok, and the thing will be a ton more robust... > - creation of tmpfile directories is left to the application (again > duplicated effort and the wrong place to do it, when there is a > centralized mechanism for handling this properly) I strongly disgaree. Invoking "mkdir()" is trivial, openvpn really should do that. (unless it always runs unrpivileged, see below) > are there any real technical/conceptual reasons, why tmpfiles.d handling > wasn't implemented in the "systemd unit" way which would allow a service > to depend on the correct state of one or more tmpfiles.d items, so on > each service startup, the existence + state of the required directories > would be verified and ensured. We have RuntimeDirectory= as a native unit setting. However, it is only really useful for daemons that run unprivileged all the time (i.e. also use User= or so), and cannot create the directory on their own. For all others: they really should create their runtime dirs on their own. Don't bother with tmpfiles for no reason, please... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
