On Wed, 13.08.14 14:03, Leonid Isaev (lis...@umail.iu.edu) wrote: > Hi, > > On Wed, Aug 13, 2014 at 07:45:28PM +0200, Lennart Poettering wrote: > > Well, maybe some script in the boot process invokes "systemctl > > daemon-reload" or so? Anything in the logs? > > None that I can find... Also, "journalctl | grep -i reload" returns nothing. > > But anyway, I can reproduce this by disabling all networking-related services, > rebooting (to a networkless system), and then enabling/starting the relevant > (above) services. I'll try in a clean VM next and get back here... > > As I said before, systemd-cgls shows the correct cgroup tree for all units. > Does it simply look in /proc, unlike systemctl?
Correct. "systemd-cgls" goes directly to /sys/fs/cgroup, and doesn't care about PID 1 understanding of the tree. > > Maybe netctl is used in your initrd, and the reexec for the transition > > from initrd to the host os is the issue here? > > No, netctl is not a part of my initramfs image... and neither is systemd for > that matter. Hmm, this is weird... So, the cgroup path is flushed in unit_destroy_cgroup(), which is invoked in two cases for a service: 1) when we enter an inactive state (meaning "dead" or "failed"), for all unit types 2) only for service units, when we enter the "exited" substate (which is still considered active otherwise) What surprises me about this is that both your services were actually in "exited" state, which means that really both of them should have forgotten about the cgroup... And the only way i see that this could be confused, if there's some reload/reexec of pid 1 involved here.... Hmm, could you maybe add some log_error() message to unit_destroy_cgroup() and check if this gets invoked at all for both your units, properly? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel