On Tue, 28 Aug 2018 22:35:38 -0700
Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote:
> > Yeah, I have a similar thing happening on shutdown, except that
> > we're talking about a kernel thread here, so that process is
> > ignored by the mentionned killing spree as a result, thus leaving
> > that process running.
>
> it's not a kernel thread and sounds like there is a bug in your pid 1
> that is worth fixing.
Well, it sure does look like one. By which I mean that looking at
its /proc/$PID entry, one can see that it has an empty command line and
kthreadd as parent (ppid 2), which usually are only true for kernel
threads (unless I'm mistaken).
The tool I'm using to send the signals on shutdown does indeed not use
kill(-1,sig) but instead scans /proc and determines whether or not to
signal a process (thus allowing to ignore a few specific processes to
be killed later on).
Kernel threads are obviously to be skipped, and to identify them it
uses the classic method of checking whether or not it has an empty
command line. As I said, this bpfilter helper does and that's why it is
considered a kernel thread & thus not killed.
This is also what other tools do, like ps or top, which is indeed why
they also show it as a kernel thread ("[none]").
So is this way of doing this wrong? And if so, what would be a better
way to identify kernel threads?
Out of curiosity I also had a look at how systemd does things, and it
looks to me like it does the exact same thing[1], also identifying
kernel threads by their empty command line. So I would think that a
similar issue could be observed under systemd as well.
Thanks.
[1]
https://github.com/systemd/systemd/blob/master/src/core/killall.c#L44
