On 02/14/2012 01:37 AM, Martin Kletzander wrote: 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... 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). 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_ad... That page also states: with a similar wording for systemd: https://fedoraproject.org/wiki/Packaging:Systemd 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(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On 02/15/2012 11:57 AM, Daniel P. Berrange wrote: 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/20/2012 06:55 PM, Eric Blake 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 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 04:23 PM, Eric Blake wrote: I didn't mean it that way but I'm happy we came to an agreement :) Patch is sent (it was starting the service on only one place, so it's really small one). And thank you for having such patience with me :)