[systemd-devel] Missing forked processes in 'systemctl status'

[Lennart Poettering]

On Wed, 13.08.14 14:03, Leonid Isaev (lisaev at 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