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?

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Dean Van Greunen
  • 147
  • 1
  • 7
  • Is the process in state `D` perhaps? – Panki Jun 22 '21 at 08:04
  • 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? – terdon Jun 22 '21 at 08: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. – Paul_Pedant Jun 22 '21 at 08:07
  • 4
    Your first command would kill any process that contained `21` as part of their name. – Kusalananda Jun 22 '21 at 08:14
  • 1
    **You're doing it wrong**. `man pkill`, `man kill`, `man killall` – Artem S. Tashkinov Jun 22 '21 at 08:59
  • @Panki its not in D state, its S state – Dean Van Greunen Jun 22 '21 at 09:29
  • kernel threads can be in S state: still not killable (unless they want to). That would be so much easier if you wrote the complete information of this process. – A.B Jun 22 '21 at 09:41
  • @A.B please see my edit – Dean Van Greunen Jun 22 '21 at 09:47
  • 5
    That's a kernel thread: not killable. You can recognize it because it uses 0 space (RSS = 0) (and is not a zombie). – A.B Jun 22 '21 at 09:47
  • @A.B there must be a way to kill it...any ideas? – Dean Van Greunen Jun 22 '21 at 09:53
  • 3
    kdevtmpfs probably means it's handling the tmpfs filesystems. You need it. You probably have an XY problem: https://xyproblem.info/ – A.B Jun 22 '21 at 09:55
  • 2
    Why do you want to kill it? – marcelm Jun 22 '21 at 19:20

1 Answers1

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.

Ned64
  • 8,486
  • 9
  • 48
  • 86
  • 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? – terdon Jun 22 '21 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. – Chris Down Jun 22 '21 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. – terdon Jun 22 '21 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](https://lore.kernel.org/patchwork/patch/1103564/) (see `schedule_timeout_killable`, which allows exiting from throttling more quickly if we know that the thread has been sent a fatal signal). :-) – Chris Down Jun 22 '21 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. – forest Jun 22 '21 at 22:52