On Mi, 12.08.20 13:03, Harald Dunkel (harald.dunkel@xxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel