Description of problem: the tool uses "vdsm-tool service-status" to check for libvirtd status, this runs service libvirtd status instead of using upstat over RHEL. It reports the libvirtd is stopped while it doesn't . the configure proceed but without restarting the service or alert the it runs How reproducible: 100% Steps to Reproduce: run libvirtd, stop vdsmd and supervdsmd run vdsm-tool configure (without --force) we configure libvirtd.conf without managing the service Actual results: libvirt is running with old configuration, althought the configure ran and modified the configuration file underneath the service. Expected results: vdsm-tool configure should not start and alert that libvirtd is running. Additional info:
my mistake. vdsm-tool service verbs try to use initctl before sysV methods. although if admin ran - "service libvirtd start" and then run vdsm-tool configure, we have mixed up operations -> libvirtd will be up, but vdsm-tool service-status will report that libvirtd is down and won't restart it even with --force flag. Is that a bug ? I'm not sure.. it was always like that, but we never let admin to start and stop libvirtd before, we did it automatically, and now we have this risk that can cause some async situations
anything you do should be consistent. or I miss something.
It's a RHEL6 problem that it does not provide a way to redirect SysV "service" commands to Upstart. In recent Ubuntu releases you can just create a soft link "/etc/init.d/libvirtd -> /lib/init/upstart-job", and all "service libvirtd XXX" are redirected to Upstart. The Upstart version in RHEL6 is too old, and its SysV compatibility feature is too weak.
OK, afaiu we (ovirt) don't handle such cases, and the service tool does work as expected if libvirtd is started by initctl as required with vdsm. I'll add better comments during handling bz 1029812 which will tell the admin to use initctl when managing libvirtd manually Closing the bug