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_addition_to_systemd_unit_files 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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list