Add support for systemd unit files available from upstream Reproducible: Always
Created attachment 340222 [details, diff] libvirt-ebuild-add-systemd-support.patch Patch to the latest ebuild adding support to systemd unit files.
@systemd: The problem here is that patched ebuild installs environment files in /etc/sysconfig/. Should systemd units in getnoo use /etc/conf.d/ instead? If yes, then there is another problem: variables used by units differ from variables used by initscripts. So either initscripts or units should be modified in this case. What do you advise?
(In reply to comment #2) > @systemd: > > The problem here is that patched ebuild installs environment files in > /etc/sysconfig/. Well, that sucks a fair bit and it feels like some poor user submitted the units upstream without knowing the systemd policies. One of them is not to use /etc/sysconfig or any other distro-specific location for EnvironmentFiles. > Should systemd units in getnoo use /etc/conf.d/ instead? If > yes, then there is another problem: variables used by units differ from > variables used by initscripts. No, definitely not. > So either initscripts or units should be > modified in this case. What do you advise? Well, that depends on libvirtd. In a perfect world, it would support a configuration file with all the options necessary for the users and it will need no EnvironmentFile. In that case, you could just drop the line. If that's not the case, I would prefer if we did some effort to find out where to place the file. Especially wrt the common systemd unit repo [2], I don't really want us to introduce a custom location for the config file. [2]:https://github.com/teg/systemd-units
(In reply to comment #3) > (In reply to comment #2) > > @systemd: > > > > The problem here is that patched ebuild installs environment files in > > /etc/sysconfig/. > > Well, that sucks a fair bit and it feels like some poor user submitted the > units upstream without knowing the systemd policies. One of them is not to > use /etc/sysconfig or any other distro-specific location for > EnvironmentFiles. libvirt mainly developed by redhat, so I think he/she was not a simple user. :) > > > Should systemd units in getnoo use /etc/conf.d/ instead? If > > yes, then there is another problem: variables used by units differ from > > variables used by initscripts. > > No, definitely not. > > > So either initscripts or units should be > > modified in this case. What do you advise? > > Well, that depends on libvirtd. In a perfect world, it would support a > configuration file with all the options necessary for the users and it will > need no EnvironmentFile. In that case, you could just drop the line. > > If that's not the case, I would prefer if we did some effort to find out > where to place the file. Especially wrt the common systemd unit repo [2], I > don't really want us to introduce a custom location for the config file. > > [2]:https://github.com/teg/systemd-units Yes, I understand that using EnvironmentFile is bad, but it still needed for some programs. And looks like all distros are using their own locations. As for libvirt, the situation is as follows: - libvirtd.service The only way to make libvirtd listen on TCP port is to pass "--listen" option to it. EnvironmentFile in libvirtd.service is used for that purpose. But /etc/systemd/system/libvirtd.service.d/*.conf can be used instead. - libvirt-guests.service This unit really doesn't need EnvironmentFile. Script /usr/libexec/libvirt-guests.sh read it iself and need to be patched since it uses /etc/sysconfig/ dir. from libvirt-guests.sh: "... test -f "$sysconfdir"/sysconfig/libvirt-guests && . "$sysconfdir"/sysconfig/libvirt-guests ..." from libvirt-guests.service: "... EnvironmentFile=-/etc/sysconfig/libvirt-guests # Hack just call traditional service until we factor # out the code ExecStart=/usr/libexec/libvirt-guests.sh start ExecStop=/usr/libexec/libvirt-guests.sh stop ..." - /etc/sysconfig/virtlockd This file is not used by any systemd units. from virtlockd.service: "... EnvironmentFile=-/etc/sysconfig/virtlockd ExecStart=/usr/sbin/virtlockd ..." $ cat /etc/sysconfig/virtlockd # # Pass extra arguments to virtlockd #VIRTLOCKD_ARGS=
Come up with what you guys want to see. I'm upstream for this project so if we can make it work as an upstream patch that would make me happier.
How about a distro independent config/env location for systemd? Something that "binds" to systemd itself and not gentoo (conf.d), redhats/whatever (sysconfig) and whatever.
(In reply to comment #5) > Come up with what you guys want to see. I'm upstream for this project so if > we can make it work as an upstream patch that would make me happier. Well, making it the shortest explanation possible, we'd like to see no need for 'conf.d' file. As in, everything being configured in upstream-specified configuration file, and init.d being solely responsible for launching it. Optionally, conf.d allowing alternate config file location.
(In reply to comment #6) > How about a distro independent config/env location for systemd? > Something that "binds" to systemd itself and not gentoo (conf.d), > redhats/whatever (sysconfig) and whatever. https://github.com/teg/systemd-units/blob/master/README.md "Avoid EnvironmentFile= to the extent possible. If it must be used, don't place configuration files in distro-specific locations. Probably /etc/$tarballname/*.conf or /etc/$tarballname.conf is best. Prefer to patch the upstream sorce to read config file(s) directly."
Added this in 1.0.5.1
Thank you! But AFAIK according to current gentoo policies, systemd use flag shouldn't be used to control installation of unit files.
