On Mi, 12.08.20 13:03, Harald Dunkel (harald.dun...@aixigo.com) wrote:
> 1 getuid() = 0
> 1 kill(1544456, SIGHUP) = 0
So, first, systemd tries and succeeds to kill the main process of your
service with SIGHUP. So far far so good.
> 1 openat(AT_FDCWD,
> "/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs",
> O_RDONLY|O_CLOEXEC) = 24
> 1 fstat(24, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> 1 read(24, "0\n1544456\n", 4096) = 10
> 1 close(24) = 0
It then goes on, and tries to enumerate the other processes in the
cgroup of the service to kill them too, if their PID is not equal to
the main PID it already killed above. And this is where it gets weird:
the "cgroup.procs" file contains two PIDs. The second one is the main
PID again, as expected. But the first one is "0". That is not a valid
PID, obviously. THis is either a kernel bug, or you joined a foreign
process in there from the outside? Could also be some LXC
weirdness..
systemd sees the PID "0", parses it, notices it is invalid, and
propagates EIO, since we read borked data.
I am not sure why LXC should insert random processes into random
subtrees of our cgroup tree. If it does that, this would really be a
bug...
Lennart
--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
