Elias Probst <m...@eliasprobst.eu> schrieb: > On 04/12/2015 05:47 PM, Kai Krakow wrote: >> Elias Probst <m...@eliasprobst.eu> schrieb: >> >>> 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: >>> >>> A# >>> - the package manager creates /run/openvpn as part of of its postinst >>> routine. This is duplicated effort and could easily go out of sync with >>> the definition in OpenVPN's tmpfiles.d configuration >>> >>> B# >>> - the package manager calls "systemd-tmpfiles --create …" whenever a >>> tmpfiles.d configuration was installed. This might still be the most >>> straightforward way, but it could still happen that a user manually >>> deletes the directory and than at a later point attempts to start a >>> service depending on it >>> >>> C# >>> - the user has to create /run/openvpn manually (I don't think I have to >>> outline why this is no "correct" solution) >>> >>> D# >>> - 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) >>> >>> E# >>> - the service unit contains something like "ExecPre=/bin/mkdir …". Again >>> duplicated effort and the wrong place to do it. >> >> F# >> - the service file contains a RuntimeDirectory directive. >> >> ;-) >> > > Ha! Perfect! Thanks a lot for pointing this out.
You're welcome... > My initial bugreport against Gentoo [1] regarding this issue is older > than the implementation of RuntimeDirectory [2] - time for updating the > bugreport + getting upstream (OpenVPN) involved to ship an updated > service unit and get rid of their tmpfiles.d conf. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=462118 > [2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=e66cf1a3 A lot of packages should use this directive in Gentoo if I looked at /usr/lib/tmpfiles.d... There seem to be a lot of Gentoo-generated files (those without any comments) which could by migrated into the service file instead. But, as Lennart pointed out, it would really be better if daemons created those directories by themselves. I'd not put that under the term "duplicated effort" - indeed you are having duplicated effort currently because every init system has to take care of creating those directories, sometimes even depending on configuration files, e.g. mysql configures this in the configuration file but also in the init file. As a sysadmin I have to take care to change all possible places. If, in this example, mysql would simply create this directory on its own, all would be good - no more duplicated effort. Well, OTOH mysql isn't started as root, thus it cannot create this directory. So, such services are dependent on duplicated work - but at least RuntimeDirectory is the right place to do it then. I'd really prefer systemd's idea of services should create their runtime environment themselves on first start as complete as possible. Letting the package manager create all those empty runtime directories with .keep files so they become part of backups and do not become cleaned up, is really cumbersome and incomplete, and duplicate work because you have configuration in two places: the config file and the package manager. If I wanted to move runtime directories I'd have to configure the new directories but also create them or move them. Upon update, the package manager will recreate empty bogus directories. This should really go away. -- Replies to list only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
