4

I'm using Linux Ubuntu 20.04.

I have a process with PID 21:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs

After running either of

  • sudo pkill -9 21
  • sudo kill 21

the process is still visible in the outputs of top or ps aux.

How can I kill it?

Improve this question
12
  • 3
    Please edit your question and add the output of top or ps aux showing the command. Also, when you say "Linux 20.04", I suppose you mean you are running Ubuntu 20.04, right? Commented Jun 22, 2021 at 8:05
  • 3
    Low-numbered processes are assigned to root/kernel processes -- user processes are usually 1000 and up. What is the command for pid 21, and why do you feel it has to die? Either you can't kill it (even as root), or it instantly gets restarted. My 21 is kdevtmpfs and it defines the mount point for /dev. However, there is a known crypto miner called kdevtmpfsi too, which auto-restarts. Commented Jun 22, 2021 at 8:07
  • 4
    Your first command would kill any process that contained 21 as part of their name. Commented Jun 22, 2021 at 8:14
  • 5
    That's a kernel thread: not killable. You can recognize it because it uses 0 space (RSS = 0) (and is not a zombie). Commented Jun 22, 2021 at 9:47
  • 3
    kdevtmpfs probably means it's handling the tmpfs filesystems. You need it. You probably have an XY problem: xyproblem.info Commented Jun 22, 2021 at 9:55

1 Answer 1

Reset to default
13

As A.B pointed out this is a thread (for one functionality) of the Linux kernel and as such cannot be killed. Also, there would be no benefit killing/removing it.

It can be seen more clearly when calling ps with arguments like these:

# ps auxfww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ? S Jun07 0:00 [kthreadd] (...) root 21 0.0 0.0 0 0 ? S Jun07 0:00 \_ [kdevtmpfs] (...)

There you can see that it is a descendant of the kernel. The RSS=0 and VSZ=0 are also indicators.

If the above flags don't work with your version of ps, please try ps -ejfH to see every process, with job details, in a hierarchy.

Improve this answer
5
  • Why can't it be killed? I mean, what's special about it? Does the kernel protect its own threads from SIGKILL so it refuses to kill itself? Commented Jun 22, 2021 at 17:25
  • 6
    @terdon Kernel threads can choose to do whatever they like upon receiving a signal (eg. by looking at fatal_signal_pending()), but most of them simply don't handle it. So the reason that it can't be killed is just because nobody thought there was any point to implement that for this particular thread (and indeed, for most threads there's not much use in responding to signals). In general: signals are checked implicitly as part of coming back to userspace, and kernel threads don't return to userspace, so any check must be explicit. Commented Jun 22, 2021 at 17:41
  • @ChrisDown ah of course, because presumably since this is the kernel, it doesn't handle itself using the same mechanisms as for normal threads and you would have to explicitly write code designed to catch and handle these signals as though you were a non-kernel process. That makes sense, thanks. Commented Jun 22, 2021 at 17:42
  • 2
    @terdon No worries :-) To give a counterexample to the "generally we don't do explicit signal handling in the kernel" statement (although this one has a userspace component): for example, we do it as part of cgroup v2 memory allocator throttling (see schedule_timeout_killable, which allows exiting from throttling more quickly if we know that the thread has been sent a fatal signal). :-) Commented Jun 22, 2021 at 17:44
  • 1
    @terdon Kernel threads have every signal disposition set to SIG_IGN by default, including SIGKILL (which normally cannot be ignored). However, it can manually register a handler for it, but the default dispositions do not apply. Commented Jun 22, 2021 at 22:52

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.