[libvirt] RFC: Post-install behavior of libvirt(-client)
Hello everyone, I have a small bug #786770 [1] assigned and I discussed this with few people from our team but I'm still not sure what should be the proper fix for this bug. To sumarize the bug, the problem described and discussed there [1] is that when there's a fresh installation of RHEL system with libvirt-client, there are some error messages displayed. These messages are generated by the part of %post client script where we are running this: if [ $1 -ge 1 ]; then level=$(/sbin/runlevel | /bin/cut -d ' ' -f 2) if /sbin/chkconfig --levels $level libvirt-guests; then # this doesn't do anything but allowing for libvirt-guests to be # stopped on the first shutdown /sbin/service libvirt-guests start > /dev/null 2>&1 || true fi fi The messages are generated because "/sbin/runlevel" returns "unknown" in chrooted installation environment. But there's more to that. While looking at this part of code, I wonder what we are trying to do here :) There are some problems, let me revise: - 1st parameter of this script is 1 for install and 2 for upgrade, thus "[ $1 -ge 1 ]" is always true - we are trying to get the current runlevel and then check if libvirt-guests is enabled in this runlevel. As mentioned before, the latter doesn't work because we are using command "/sbin/runlevel" there. There is another option, but unfortunately, running "/sbin/chkconfig libvirt-guests" fails as well. Both of these are trying to get current runlevel from "/var/run/utmp" which is empty in the chrooted env during installation. Thinking about this a little more, I see two more "unconsistencies" let's say: - we are starting libvirt-guests if it is enabled (rpm post script should not start services) - we don't check if libvirtd is running, so during shutdown we can get even more error messages that the script is not able to connect to libvirt etc. So I'm wondering if I can just remove the starting part (because if someone wants to use it after first install, he has to start libvirtd anyway and then should know to start libvirt-guests as well) or if I have to come up with some totally different solution how to do this. Maybe I'm missing something here or I don't understand it correctly, any correction is appreciated. Thanks in advance for all suggestions. Have a nice day Martin [1] https://bugzilla.redhat.com/show_bug.cgi?id=786770
On 02/14/2012 01:37 AM, Martin Kletzander wrote:
Hello everyone,
I have a small bug #786770 [1] assigned and I discussed this with few people from our team but I'm still not sure what should be the proper fix for this bug.
Thinking about this a little more, I see two more "unconsistencies" let's say: - we are starting libvirt-guests if it is enabled (rpm post script should not start services)
Ultimately, I see two possible useful behaviors: 1. We install but don't start services. Since both libvirtd and libvirt-guests have a Default-Start: 3 4 5 (for init script) or [Install]WantedBy=multi-user.target (for systemd), then the user will get both services running after their next reboot (by virtue of their defaults), but not beforehand. If the user wants to start the services before rebooting, then they should start both services - if the user starts libvirtd but not libvirt-guests, it is their own fault for not realizing that libvirt-guests was useful. 2. We install services, and if it is the initial install, we also default those services to start immediately. And, since libvirt-client can be installed without libvirtd, we make sure that the libvirt-guests init script has sane default behavior when it cannot connect to a running libvirtd. Where is it written that rpms may not start services? Finding a concrete policy on the matter should influence our answer...
- we don't check if libvirtd is running, so during shutdown we can get even more error messages that the script is not able to connect to libvirt etc.
That's a service dependency - if both libvirt-guests and libvirtd are installed services, then starting libvirt-guests should automatically start libvirtd first (that is, assuming the default libvirt-guests behavior of probing local URIs that require libvirtd). I think that is done by a Should-Start: libvirt-guests in the init version (oops, that's missing), and by [Unit]Before=libvirt-guests.service in the systemd version. Meanwhile, the dependency must be weak; either libvirtd or libvirt-guests in isolation makes sense (well, libvirt-guests in isolation is less likely, since then it can only manage remote URIs, but should still be possible).
So I'm wondering if I can just remove the starting part (because if someone wants to use it after first install, he has to start libvirtd anyway and then should know to start libvirt-guests as well) or if I have to come up with some totally different solution how to do this. Maybe I'm missing something here or I don't understand it correctly, any correction is appreciated. Thanks in advance for all suggestions.
Other food for thought - now that we switched libvirt to systemd init scripts in F16, we should be creating new libvirt-sysvinit and libvirt-client-sysvinit packages for the init scripts: https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addit... That page also states:
Why don't we....
run 'chkconfig <service> on'?
If a service should be enabled by default, make this the default in the init script. Doing otherwise will cause the service to be turned on on upgrades if the user explicitly disabled it.
Note that the default for most network-listening scripts is off. This is done for better security. We have multiple tools that can enable services, including GUIs.
start the service after installation?
Installations can be in changeroots, in an installer context, or in other situations where you don't want the services started.
with a similar wording for systemd: https://fedoraproject.org/wiki/Packaging:Systemd
Why don't we....
Start the service after installation?
Installations can be in changeroots, in an installer context, or in other situations where you don't want the services autostarted.
libvirtd is network-listening, libvirt-guests is not; but libvirt-guests without libvirtd isn't quite as useful. I'm starting to lean towards option 1 - we should install, but not start, services. But there might be another option for systemd: if we make libvirtd.service support socket-activation _in addition to_ boot activation, then we could make things so that the first 'virsh -c qemu:///system' starts up libvirtd, if it is not already running, as well as the fact that we want libvirtd to start at boot in order to start any autostart domains without waiting for a socket connection. I'm not sure how much additional work that would be (certainly beyond the scope of your initial question of how to silence the messages during rpm installation due to mis-use of chkconfig). And if we _do_ make libvirtd socket-activated, then we have to figure out how to make libvirt-guests start at the same time. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Tue, Feb 14, 2012 at 03:17:40PM -0700, Eric Blake wrote:
On 02/14/2012 01:37 AM, Martin Kletzander wrote:
Hello everyone,
I have a small bug #786770 [1] assigned and I discussed this with few people from our team but I'm still not sure what should be the proper fix for this bug.
Thinking about this a little more, I see two more "unconsistencies" let's say: - we are starting libvirt-guests if it is enabled (rpm post script should not start services)
Ultimately, I see two possible useful behaviors:
1. We install but don't start services. Since both libvirtd and libvirt-guests have a Default-Start: 3 4 5 (for init script) or [Install]WantedBy=multi-user.target (for systemd), then the user will get both services running after their next reboot (by virtue of their defaults), but not beforehand.
If the user wants to start the services before rebooting, then they should start both services - if the user starts libvirtd but not libvirt-guests, it is their own fault for not realizing that libvirt-guests was useful.
2. We install services, and if it is the initial install, we also default those services to start immediately. And, since libvirt-client can be installed without libvirtd, we make sure that the libvirt-guests init script has sane default behavior when it cannot connect to a running libvirtd.
Where is it written that rpms may not start services? Finding a concrete policy on the matter should influence our answer...
It is a basic Fedora requirement that you may *not* start any services during %post scripts. The reason for this is that the RPMs need to be installable in virutal chroot directories for the purposes of building RPMs. The only permissable things are - Mark the service to be started by default - Issue a conditional restart - ie, if we detect the service already running, it is permissable to restart it. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 02/15/2012 11:57 AM, Daniel P. Berrange wrote:
On Tue, Feb 14, 2012 at 03:17:40PM -0700, Eric Blake wrote:
On 02/14/2012 01:37 AM, Martin Kletzander wrote:
Hello everyone,
I have a small bug #786770 [1] assigned and I discussed this with few people from our team but I'm still not sure what should be the proper fix for this bug.
Thinking about this a little more, I see two more "unconsistencies" let's say: - we are starting libvirt-guests if it is enabled (rpm post script should not start services)
Ultimately, I see two possible useful behaviors:
1. We install but don't start services. Since both libvirtd and libvirt-guests have a Default-Start: 3 4 5 (for init script) or [Install]WantedBy=multi-user.target (for systemd), then the user will get both services running after their next reboot (by virtue of their defaults), but not beforehand.
If the user wants to start the services before rebooting, then they should start both services - if the user starts libvirtd but not libvirt-guests, it is their own fault for not realizing that libvirt-guests was useful.
2. We install services, and if it is the initial install, we also default those services to start immediately. And, since libvirt-client can be installed without libvirtd, we make sure that the libvirt-guests init script has sane default behavior when it cannot connect to a running libvirtd.
Where is it written that rpms may not start services? Finding a concrete policy on the matter should influence our answer...
It is a basic Fedora requirement that you may *not* start any services during %post scripts. The reason for this is that the RPMs need to be installable in virutal chroot directories for the purposes of building RPMs.
The only permissable things are
- Mark the service to be started by default - Issue a conditional restart - ie, if we detect the service already running, it is permissable to restart it.
Daniel
I'm inclining to the former as well. It seems more clear and straightforward for me. I also spoke with Dave about this and he had one more idea about this. In order to change the behavior as less as possible, we could leave it this way and just check if /sbin/runlevel returns the runlevel as it should or not and in case of an error, just skip the starting, otherwise leave it as it is. Martin
On 02/14/2012 03:17 PM, Eric Blake wrote:
On 02/14/2012 01:37 AM, Martin Kletzander wrote:
Hello everyone,
I have a small bug #786770 [1] assigned and I discussed this with few people from our team but I'm still not sure what should be the proper fix for this bug.
with a similar wording for systemd:
https://fedoraproject.org/wiki/Packaging:Systemd
Why don't we....
Start the service after installation?
Installations can be in changeroots, in an installer context, or in other situations where you don't want the services autostarted.
libvirtd is network-listening, libvirt-guests is not; but libvirt-guests without libvirtd isn't quite as useful.
I'm starting to lean towards option 1 - we should install, but not start, services.
Another wrinkle to the question: https://fedoraproject.org/wiki/Starting_services_by_default documents that services must not be enabled by default if it is network-enabled, unless it has FESCo approval. libvirtd is network-enabled, since it can be configured to accept connections from the outside world; but its default configuration is useful without network configuration. Likewise, libvirt-guests is primarily useful for only local guests, but it can be argued that since it can connect to hypervisors over a network, it is network-enabled. Do we need to apply for FESCo exception on either of these two services? -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 02/20/2012 06:55 PM, Eric Blake wrote:
On 02/14/2012 03:17 PM, Eric Blake wrote:
On 02/14/2012 01:37 AM, Martin Kletzander wrote:
Hello everyone,
I have a small bug #786770 [1] assigned and I discussed this with few people from our team but I'm still not sure what should be the proper fix for this bug.
with a similar wording for systemd:
https://fedoraproject.org/wiki/Packaging:Systemd
Why don't we....
Start the service after installation?
Installations can be in changeroots, in an installer context, or in other situations where you don't want the services autostarted.
libvirtd is network-listening, libvirt-guests is not; but libvirt-guests without libvirtd isn't quite as useful.
I'm starting to lean towards option 1 - we should install, but not start, services.
Another wrinkle to the question:
https://fedoraproject.org/wiki/Starting_services_by_default
documents that services must not be enabled by default if it is network-enabled, unless it has FESCo approval. libvirtd is network-enabled, since it can be configured to accept connections from the outside world; but its default configuration is useful without network configuration. Likewise, libvirt-guests is primarily useful for only local guests, but it can be argued that since it can connect to hypervisors over a network, it is network-enabled. Do we need to apply for FESCo exception on either of these two services?
To me it seems more reasonable to just don't start anything. I don't want any service on my system started just because I installed it. I know it's not the same, but there are some cases where I'm sure others wouldn't like that too. For example when you just want the development libraries or when you remotely install some firewall that could cut you out of the connected machine. Having libvirt-guests set remotely is not very common I guess. If you have a vm running somewhere else you most probably don't want to have it saved when shutting down your computer. Maybe that's another case when you don't want to have it started. I think services should be started only when the user went through the configuration and knows he wants to have them started. I know I seem very stubborn in this decision but unless proved otherwise I have no reason to change my mind about removing these parts of the script but if anyone has anything to add to this I will very warmly welcome any other views. I'm not talking about enabling, that's something else. For this I think it can be left as is as default configuration is only local for all installed services (am I right?). So to summarize it. Please tell me if I can remove the parts of the %post script dealing with starting services. If not, please let me know as well, because then I have a patch prepared that only (without any functional change) fixes the bug that originally led me to this discussion. All criticism appreciated ;-) Regards, Martin
On 02/23/2012 07:25 AM, Martin Kletzander wrote:
To me it seems more reasonable to just don't start anything. I don't want any service on my system started just because I installed it.
I think we've reached a state of violent agreement :)
I'm not talking about enabling, that's something else. For this I think it can be left as is as default configuration is only local for all installed services (am I right?).
Enabled by default is fine. That means the user has to either reboot or manually start things when first installing, but thereafter, the service starts at boot.
So to summarize it. Please tell me if I can remove the parts of the %post script dealing with starting services.
Yes, and I will gladly ACK such patches. Thanks for tackling this, and for making me do further research onto Fedora packaging guidelines. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 02/23/2012 04:23 PM, Eric Blake wrote:
On 02/23/2012 07:25 AM, Martin Kletzander wrote:
To me it seems more reasonable to just don't start anything. I don't want any service on my system started just because I installed it.
I think we've reached a state of violent agreement :)
I didn't mean it that way but I'm happy we came to an agreement :)
So to summarize it. Please tell me if I can remove the parts of the %post script dealing with starting services.
Yes, and I will gladly ACK such patches.
Patch is sent (it was starting the service on only one place, so it's really small one).
Thanks for tackling this, and for making me do further research onto Fedora packaging guidelines.
And thank you for having such patience with me :)
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Martin Kletzander