Процесс не убивается linux

What if ‘kill -9’ does not work?

Stuck in a system call into the kernel, cannot be interrupted. I have a problem with Xorg going into that state, likely because of a GPU driver bug. Trying to attach any debugger (gdb, strace) just causes the debugger to hang as well (but at least they still respond to SIGKILL). Bad kernel design (blocking uninterruptible system calls) combined with buggy code here and there and you have a deadlock. Usually only a reboot can fix it, and that certainly seems to be the case with my Xorg problem as well.

If anyone is still designing new operating systems, avoid blocking system calls at all cost and go full async. You should have syscalls to initiate operations but that return immediately to user space, and then a poll syscall for the process to sleep until some response arrives (a single syscall for polling also allows waiting for many things simultaneously). Then the only syscall that needs to be interruptible is poll, instead of the zillion I/O operations that different drivers and subsystems implement.

15 Answers 15

kill -9 (SIGKILL) always works, provided you have the permission to kill the process. Basically either the process must be started by you and not be setuid or setgid, or you must be root. There is one exception: even root cannot send a fatal signal to PID 1 (the init process).

However kill -9 is not guaranteed to work immediately. All signals, including SIGKILL, are delivered asynchronously: the kernel may take its time to deliver them. Usually, delivering a signal takes at most a few microseconds, just the time it takes for the target to get a time slice. However, if the target has blocked the signal, the signal will be queued until the target unblocks it.

Normally, processes cannot block SIGKILL. But kernel code can, and processes execute kernel code when they call system calls. Kernel code blocks all signals when interrupting the system call would result in a badly formed data structure somewhere in the kernel, or more generally in some kernel invariant being violated. So if (due to a bug or misdesign) a system call blocks indefinitely, there may effectively be no way to kill the process. (But the process will be killed if it ever completes the system call.)

A process blocked in a system call is in uninterruptible sleep. The ps or top command will (on most unices) show it in state D (originally for “disk”, I think).

A classical case of long uninterruptible sleep is processes accessing files over NFS when the server is not responding; modern implementations tend not to impose uninterruptible sleep (e.g. under Linux, since kernel 2.6.25, SIGKILL does interrupt processes blocked on an NFS access).

If a process remains in uninterruptible sleep for a long time, you can get information about what it’s doing by attaching a debugger to it, by running a diagnostic tool such as strace or dtrace (or similar tools, depending on your unix flavor), or with other diagnostic mechanisms such as /proc/PID/syscall under Linux. See Can’t kill wget process with `kill -9` for more discussion of how to investigate a process in uninterruptible sleep.

You may sometimes see entries marked Z (or H under Linux, I don’t know what the distinction is) in the ps or top output. These are technically not processes, they are zombie processes, which are nothing more than an entry in the process table, kept around so that the parent process can be notified of the death of its child. They will go away when the parent process pays attention (or dies).

Источник

Почему команда kill не убивает процесс?

Команда kill используется для того, чтобы остановить работу процесса, синтаксис команды:

sudo kill ИДЕНТИФИКАТОР-ПРОЦЕССА

Вы можете столкнуться с ситуацией, когда использование kill не приводит к завершению процесса.

Получить идентификатор процесса зная имя исполнимого файла можно командой:

Этой же командой можно проверять, работает ли ещё процесс.

Обычно достаточно команды kill для остановки большинства процессов. Но может быть так, что какой-то процесс совершенно не реагирует на kill, в том числе если запустить её с sudo.

Название команды kill продолжает вводить в заблуждение многих, многих пользователей (включая меня в начале). Предполагается, что когда вы говорите «kill X», это в точности означает «убить процесс X». Но на самом деле это далеко не так. Команда kill всего лишь посылает процессу один из сигналов.

Если kill вызывается без каких-либо параметров, он отправляет сигнал номер 15 (SIGTERM). Этот сигнал может игнорироваться процессом. Этот сигнал уведомляет процесс о необходимости привести в порядок свои вещи, а затем процесс сам правильно завершает работу. Это хороший способ.

Вы также можете «послать» сигнал номер 9 (SIGKILL), который процесс не может игнорировать. Процесс даже не распознает его, потому что ядро завершает процесс, а не сам процесс. Это злой путь.

Процессы могут игнорировать некоторые сигналы. Если вы отправите SIGKILL, он не сможет его игнорировать и не выполнит подготовительные для завершения действия, например, сохранение данных или очистку.

kill -9 ИДЕНТИФИКАТОР-ПРОЦЕССА

Если вы приостановите процесс с помощью CTRL-z, он будет блокировать большинство сигналов, пока он приостановлен (то есть, пока вы не выполните fg или bg для процесса).

Также обратите внимание, что в некоторых очень специфических обстоятельствах процесс может находиться в состоянии зомби/неработоспособности, что даже SIGKILL не может убить процесс. В этом случае вам нужно будет найти родительский процесс и убить родительский процесс.

Некоторые говорят, что kill -9 всегда срабатывает. Это заблуждение. Бывают ситуации, когда даже kill -9 не убивает процесс. Например, когда процесс находится в состоянии D (непрерывный сон). Процесс переходит в это состояние каждый раз, когда ожидает ввода-вывода (обычно не очень долго). Итак, если процесс ожидает ввода-вывода (например, на неисправном жёстком диске) и он не запрограммирован должным образом (с таймаутом), то вы просто не можете убить процесс. Что бы вы не делали. Вы просто можете попытаться сделать файл доступным, чтобы процесс продолжился.

open("/dev/video0", O_RDWR) = 3 ioctl(3, VIDIOC_QUERYCAP or VT_OPENQRY, 0xbfef888c) = 0 ioctl(3, VIDIOC_ENUMINPUT, 0xbfef88f4) = 0 ioctl(3, VIDIOC_ENUMINPUT, 0xbfef88f4) = 0 ioctl(3, VIDIOC_ENUMINPUT, 0xbfef88f4) = 0 ioctl(3, VIDIOC_ENUMINPUT, 0xbfef88f4) = 0 ioctl(3, VIDIOC_ENUMINPUT, 0xbfef88f4) = -1 EINVAL (Invalid argument) ioctl(3, 0x800476c6, 0xbfef89e8) = -1 EINVAL (Invalid argument) ioctl(3, VIDIOC_S_INPUT И всё.