Bug#781210: systemd asserts on function cg_is_empty_recursive, crashes

Faidon Liambotis paravoid at debian.org
Thu Mar 26 17:48:56 GMT 2015


Hi Martin!

On Thu, Mar 26, 2015 at 03:17:16PM +0100, Martin Pitt wrote:
> Control: severity -1 important
> 
> 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.

Well, this does makes the whole system break (the system needs a reboot
to properly function again; daemon-reexec didn't work). I was about to
deploy this to a large fleet of machines and having to reboot all of
them would be quite catastrophic. I think it deserves to at least be RC.

> 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?

I haven't been able to reproduce it again :/ I must be missing
something, as I was able to reproduce it multiple times on two different
servers yesterday. "systemctl restart strongswan" does not leave any
processes behind in my runs (I wrote something to do the same sequence
of events in a loop).

Can you confirm that in your case "systemctl restart strongswan" leaves
unmanageable processes behind (i.e. the ipsec binaries you see do *not*
have --nofork as an argument)? If so, a mere "ipsec stop" after that
should be able to crash systemd.

Thanks,
Faidon




More information about the Pkg-systemd-maintainers mailing list