Control: severity -1 important Hello Faidon,
thanks for your report! I downgrade the severity to important as per https://www.debian.org/Bugs/Developer#severities (and with #781209 we have the bug that triggers this one); nevertheless, this is still an important issue of course. Faidon Liambotis [2015-03-26 4:50 +0200]: > #6 0x00007f8fb8f6cc8f in cg_is_empty_recursive.constprop.53 (path=0x0, > ignore_self=ignore_self@entry=true, controller=<synthetic pointer>) > at ../src/shared/cgroup-util.c:913 > d = 0x0 > fn = 0x7f8fba8a4d90 "\001" > r = <optimized out> > #7 0x00007f8fb8ff21c3 in manager_notify_cgroup_empty (cgroup=<optimized > out>, m=0x7f8fba893b50) at ../src/core/cgroup.c:978 > u = 0x7f8fba894d30 > r = <optimized out> > #8 signal_agent_released (bus=<optimized out>, message=0x7f8fba8a3b40, > userdata=0x7f8fba893b50, error=<optimized out>) at ../src/core/dbus.c:90 > m = 0x7f8fba893b50 > cgroup = 0x7f8fba923684 "/system.slice/ipsec.service" So "cgroup" in manager_notify_cgroup_empty() is valid, and manager_get_unit_by_cgroup(m, cgroup) returns some unit u, but u->cgroup_path is NULL. I suppose u->id is "ipsec.service" (if you can easily reproduce this, confirming this in gdb would be appreciated), so as the first iteration this smells like a bug in the cgroup_unit hashmap maintenance. I don't get quite the same effect as you, but I can reproduce the wrong cgroup and that "systemctl restart strongswan" leaves the old processes around and does not actually kill them. I don't get the assertion or crash, though. 219 in experimental behaves much better, the processes gets put into the "strongswan.service" cgroup, and stopping, starting, restarting works properly. Can you confirm this? Thanks! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
