The systemd eclass currently is able to deal with the installation of tmpfiles.d files through systemd_newtmpfilesd(). But this only installs, but doesn't apply the tmpfiles.d configuration which causes at least trouble for net-misc/openvpn-2.3.0 (and possibly other packages too). net-misc/openvpn-2.3.0 installs the following two systemd files: /usr/lib/systemd/system/openvpn@.service /usr/lib/tmpfiles.d/openvpn.conf The file openvpn@.service contains the lines: PIDFile=/var/run/openvpn/%i.pid ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf as part of the [Service] definition. This means, to start the service, the directory "/var/run/openvpn" needs to exist, otherwise the PID-file can't be written and starting OpenVPN will fail like this: Options error: --writepid fails with '/var/run/openvpn/companyvpn.pid': No such file or directory There are several workarounds like: - create the directory manually - tell the user via elog to run "systemd-tmpfiles --create openvpn.conf" before starting any OpenVPN service instance - reboot But IMHO, the correct solution would be, to trigger "systemd-tmpfiles --create openvpn.conf" automatically via the eclass as part of pkg_postinst(). This should only happen conditionally based on "has_version sys-apps/systemd" and automatically pick up the name of the newly installed config files based on the files installed via systemd_newtmpfilesd() - calling this manually should not be needed, as this might be easily forgotten - leading to probably numerous future bugreports about similar cases as described above for OpenVPN.
(In reply to comment #0) > But IMHO, the correct solution would be, to trigger "systemd-tmpfiles > --create openvpn.conf" automatically via the eclass as part of > pkg_postinst(). > > This should only happen conditionally based on "has_version > sys-apps/systemd" and automatically pick up the name of the newly installed > config files based on the files installed via systemd_newtmpfilesd() - > calling this manually should not be needed, as this might be easily > forgotten - leading to probably numerous future bugreports about similar > cases as described above for OpenVPN. I have no problem adding a wrapper to run systemd-tmpfiles if it is available. That is, letting you do: pkg_postinst() { systemd_run_tmpfiles --create openvpn.conf } But I'm not sure if any kind of automation is possible here. We would have to save variables in src_install(), and src_install() is not executed during binary package installs. Therefore, I don't know if binary packages will have the file list.
(In reply to comment #1) Yeah, I think a helper function would be appropriate for this. Regardless of the binpkg variable issue, I don't think we should call EXPORT_FUNCTIONS in systemd.eclass. We would really need to create a new eclass for that.
Is there any way to access the list of files installed by an ebuild during pkg_postinst? If so, then implementing this would be rather straightforward and wouldn't need any explicit calling of "systemd_run_tmpfiles()" in the ebuild's pkg_postinst, as it could be handled completely transparent by the eclass. ${D} is already cleaned up at this point, so we can't simply look up the paths for systemd tmpfiles definitions.
(In reply to comment #3) We could gather a list of files in pkg_preinst, and reference it in pkg_postinst. However, we really need a new eclass if we start exporting functions. And I think this is a case of over-engineering.
Something similar affects "sysctl.d" files which would require to either automatically restart systemd-sysctl.service or at least notify the user to do so manually. See also: http://0pointer.de/public/systemd-man/sysctl.d.html
Please also remember that ebuilds don't actually depend on systemd, and tmpfiles.d affect OpenRC users as well. If we're to do a wrapper, that wrapper would need to detect which init is used, and run appropriate commands. @openrc, does OpenRC support explicitly calling a run of a single tmpfiles.d file?
(In reply to Michał Górny from comment #6) > Please also remember that ebuilds don't actually depend on systemd, and > tmpfiles.d affect OpenRC users as well. > > If we're to do a wrapper, that wrapper would need to detect which init is > used, and run appropriate commands. > > @openrc, does OpenRC support explicitly calling a run of a single tmpfiles.d > file? No, it does not, so if you go that route, this would be something I would have to add. I am going to agree with Mike ; I think this is a case of over-engineering.
*** Bug 542356 has been marked as a duplicate of this bug. ***
Since systemd-211 (oldest currently provided by Gentoo is 215) there's support for RuntimeDirectory= and RuntimeDirectoryMode= [1] which would solve this issue completely. I filed a PR against OpenVPN at [2] to solve this issue. [1] http://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory= [2] https://github.com/OpenVPN/openvpn/pull/22
Created attachment 428216 [details, diff] Add systemd_tmpfiles_create function Here's a patch to call systemd-tmpfiles if it is installed.
(In reply to Michał Górny from comment #6) > Please also remember that ebuilds don't actually depend on systemd, and > tmpfiles.d affect OpenRC users as well. > > If we're to do a wrapper, that wrapper would need to detect which init is > used, and run appropriate commands. > > @openrc, does OpenRC support explicitly calling a run of a single tmpfiles.d > file?
(In reply to Mike Gilbert from comment #10) Pushed to gentoo with a couple tweaks. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b480b389a39dc6b8d9cdaf99c0e554ab82ef5ca8 If/when openrc exposes its tmpfiles implementation with a public binary/script, we can add that as a fallback.
