[Service] EnvironmentFile=-/etc/sysconfig/libvirtd
/etc/conf.d is even more invalid.
(In reply to Michał Górny from comment #1) > /etc/conf.d is even more invalid. But I guess that it's what we should use in Gentoo, no? :/ What would be the alternative then?
The proper location for systemd specific configuration files is /etc/systemd/system/libvirtd.service.d, etc.
(In reply to Matthias Maier from comment #3) > The proper location for systemd specific configuration files is > /etc/systemd/system/libvirtd.service.d, > etc. Do we really want ebuilds sticking files in here? This should just be for user-provided configuration overrides. Also, I don't think that this is where we want things like environment files, is it?
(In reply to Richard Freeman from comment #4) > Also, I don't think that this is where we want things like environment > files, is it? No, we need some other palce in /etc
The policy about where to place config files (if really needed) is at: https://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy#Unit_file_guidelines If you don't need any config file, no problem, even keeping: EnvironmentFile=-/etc/sysconfig/libvirtd as it won't try to load that file if not present (due the "-")
(In reply to Pacho Ramos from comment #6) > The policy about where to place config files (if really needed) is at: > https://wiki.gentoo.org/wiki/Project:Systemd/ > Ebuild_policy#Unit_file_guidelines > > If you don't need any config file, no problem, even keeping: > EnvironmentFile=-/etc/sysconfig/libvirtd > > as it won't try to load that file if not present (due the "-") Ugh - I don't particularly like having packages stick stuff in /etc/systemd/system, but I suppose if every line is commented out it isn't the end of the world. I can just ignore that file and make my changes in an entirely different one. :) Apologies - I realize this isn't an issue for libvirt.
So, there is net-misc/ntp /etc/systemd/system/sntp.service.d/00gentoo.conf /etc/systemd/system/ntpdate.service.d/00gentoo.conf net-misc/dhcp /etc/systemd/system/dhcrelay6.service.d/00gentoo.conf /etc/systemd/system/dhcrelay4.service.d/00gentoo.conf and the systemd.eclass has systemd_install_serviced (for installing exactly this file) which is used by half a dozen of packages. And we're talking about /etc/sysconfig/libvirtd overriding Environment attributes, so it would nicely fit in. But this ultimately a question of policy... so, how to proceed? ($ rm -r /etc/sysconfig is hardly an option because on looses the file explaining what one can configure...)
as I have seen, upstream is providing that /etc/sysconfig/libvirtd and the systemd unit files using it. Personally, I would prefer to keep it as that way upstream will completely support us (well, if some problem arises with service activation, they will need to hear us as we do all in upstream way)... but maybe you should wait for other systemd team members opinions :/
(In reply to Pacho Ramos from comment #9) I'm guessing that upstream happens to be a Fedora project? That would explain the use of /etc/sysconfig. We don't generally utilize that directory on Gentoo, and I don't think we should start now.
The problem is that upstream systemd looks to not define any directory to place that config files and, since Fedora, Arch, Mandriva/Mageia and openSuSE tend to use /etc/sysconfig... I don't know if this has been discussed at any time in systemd upstream side as current situation is so inconsistent... :|
I think a big question is whether it makes more sense to use the Gentoo config directory which isn't going to align with upstream units, or put systemd configs in a directory most upstreams use. I think the latter makes sense since this creates the possibility of cross-distro configs.
After reading again all the involved files, I change my opinion and I think we should use the same as we do for ntp and others if really needed to pass other options to libvirt. The reasons for changing my opinion on this concrete issue are that upstream is simply relying on /etc/sysconfig/libvirtd for LIBVIRTD_ARGS variable. All the other variables will simply be ignored (I guess they are still there for historical reasons). Then: - Does libvirt really need to let people play appending more options to it using LIBVIRTD_ARGS? - In that case it can use a file with something like: [Service] Environment="LIBVIRTD_ARGS=" And you don't need to ever touch provided unit files
(In reply to Pacho Ramos from comment #13) > - Does libvirt really need to let people play appending more options to it > using LIBVIRTD_ARGS? AFAIK, the only way to make libvirtd listen on TCP port is to pass "--listen" option to it.
I should have inspected the actual content of the files earlier :-/ - passing options to libvirtd is actually unnecessary. --listen is only a safeguard to _allow_ configuration of network sockets (via listen_tls and listen_tcp in /etc/libvirt/libvirtd.conf) *) - The rest is very esoteric and could be safely removed. (Or a 00gentoo.conf stub could be provided). - virtlockd does not need any user supplied configuration options either. (Otherwise overriding the service file is the better approach) So, only libvirt-guests.service remains that needs two configuration options via environment (and the policy issue discussed here remains valid for the location of those). *) Just always passing --listen to the libvirtd is a subtle change, though. We would have to make sure that (a) all user configuration is updated to set above options in /etc/libvirt/libvirtd.conf - otherwise we would open up an immediate security issue.
(In reply to Matthias Maier from comment #15) [...[ > So, only libvirt-guests.service remains that needs two configuration options > via environment (and the policy issue discussed here remains valid for the > location of those). [...] Reading that file, looks like variables are not used directly by the unit, instead, I guess /usr/libexec/libvirt-guests.sh should be getting the needed variables from relevant file by itself. And that file could be placed in a "more general" place, I mean, something like /etc/yourprogram.conf (libvirt-guests.conf in the directory where general libvirt stuff is configure even for people running it manually?)
Good point, a closer look at libvirt-guests.sh reveals that this very redhat centric piece of code already needs some further adjustment. I'll phase out /etc/sysconfig in an -r1 along with some further fixups (unrelated bugs). Specifically: - I'll drop a short (completely commented) file into /etc/systemd/system/libvirt.d/00gentoo.conf with something like "for libvirtd listening on TCP/IP connections, uncomment the following lines". (I really do not want to touch this default behavior - this just asks for trouble.) - remove /etc/sysconfig/virtlockd entirely - no point for this file, - refactor libvirt-guests.sh to use configuration in /etc/libvirtd/libvirt-guests.conf (and hope for upstream removing it soon), - provide an elog notification that explains this change. Does this sound good?
Sounds fine to me :)
(In reply to Matthias Maier from comment #17) > - I'll drop a short (completely commented) file into > /etc/systemd/system/libvirt.d/00gentoo.conf with something like "for > libvirtd listening on TCP/IP connections, uncomment the following lines". (I > really do not want to touch this default behavior - this just asks for > trouble.) This seems like a good idea - set ENVIRONMENT in an add-in. I actually have one or two of my own unit files that I can convert in this manner and submit them for other packages (replacing conf.d was the only thing missing).
Starting with version 1.2.9-r1, /etc/sysconfig is gone. 03 Nov 2014; Matthias Maier <tamiko@gentoo.org> libvirt-1.2.9-r1.ebuild: fix typo, print elog message when replacing... *libvirt-1.2.9-r1 (03 Nov 2014) 03 Nov 2014; Matthias Maier <tamiko@gentoo.org> +files/libvirt-1.2.9-do_not_use_sysconf.patch, +files/libvirtd.service.conf, +libvirt-1.2.9-r1.ebuild, -files/libvirt-1.2.6-numa.patch, libvirt-9999.ebuild, metadata.xml: add wireshark-plugins use flag, bug 508340; do not install into runtime paths, bug 520408; do not install into units use /etc/sysconfig, bug 477524
