Broken logic in /etc/init/libvirt-cgred-wait.conf
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libcgroup (Ubuntu) |
New
|
Medium
|
Unassigned |
Bug Description
Hi,
Since some time, libvirt-bin fails upgrading at the time "start libvirt-bin" is run during upgrades; I have start_libvirtd="no" in /etc/default/
Looking a bit into this, I tried understanding the structure of the upstart jobs around cgred/cgconfig/
I've added some "logger" based debug to /etc/init/
# If already started, just exit
status cgred | grep -q "start/running"
[ $? -ne 0 ] || { stop; exit 0; }
[...]
The line after "grep" is never reached when cgred isn't considered "running" by upstart. I think this is because the script is run under sh -e (set -e), but I don't know why testing for $? doesn't prevent the set -e behavior.
I changed the code to this slightly nicer syntax:
# If already started, just exit
[ `status cgred` = "start/running" ] && { stop; exit 0; }
and this time saw the logging statements go through, so I would recommend changing the script to use this syntax.
However I'm worried by "sleep 3600"; this seems to be a 60 minutes timebomb.
Also, for some reason cgroups weren't listed in my /proc/mounts; starting cgconfig manually I saw this in syslog:
Mar 5 01:03:13 localhost CGRE[17054]: Started the CGroup Rules Engine Daemon.
and then cgroups were mounted, however this:
/usr/sbin/
fails every second run and leaves /sys/fs/cgroup empty; I suspect this might play a role in breaking the startup expectations.
(I'm not sure how all these scripts are supposed to play, so I'm reporting all the weird things I'm seeing; the main point of this specific bug report is to mention the syntax issues with /etc/init/
Cheers,
Aha, during my last upgrade libvirt-bin started after two minutes, which seems to be exactly the TIMEOUT set in /etc/init/ libvirt- cgconfig- wait.conf.