Я также использую:
export TERM=xterm-color
export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad
И если Вам нравится колоризация Ваша подсказка, определенная, цветной Вар может быть полезным:
export COLOR_NC='\e[0m' # No Color
export COLOR_WHITE='\e[1;37m'
export COLOR_BLACK='\e[0;30m'
export COLOR_BLUE='\e[0;34m'
export COLOR_LIGHT_BLUE='\e[1;34m'
export COLOR_GREEN='\e[0;32m'
export COLOR_LIGHT_GREEN='\e[1;32m'
export COLOR_CYAN='\e[0;36m'
export COLOR_LIGHT_CYAN='\e[1;36m'
export COLOR_RED='\e[0;31m'
export COLOR_LIGHT_RED='\e[1;31m'
export COLOR_PURPLE='\e[0;35m'
export COLOR_LIGHT_PURPLE='\e[1;35m'
export COLOR_BROWN='\e[0;33m'
export COLOR_YELLOW='\e[1;33m'
export COLOR_GRAY='\e[0;30m'
export COLOR_LIGHT_GRAY='\e[0;37m'
И затем моя подсказка - что-то вроде этого:
case $TERM in
xterm*|rxvt*)
local TITLEBAR='\[\033]0;\u ${NEW_PWD}\007\]'
;;
*)
local TITLEBAR=""
;;
esac
local UC=$COLOR_WHITE # user's color
[ $UID -eq "0" ] && UC=$COLOR_RED # root's color
PS1="$TITLEBAR\n\[${UC}\]\u \[${COLOR_LIGHT_BLUE}\]\${PWD} \[${COLOR_BLACK}\]\$(vcprompt) \n\[${COLOR_LIGHT_GREEN}\]→\[${COLOR_NC}\] "
$ (vcprompt) называет сценарий Python в моем ~/sbin, который печатает информацию об управлении версиями о текущем пути. Это включает поддержку Подвижного, Мерзавца, Svn, Cvs, и т.д. У автора сценария есть источник здесь.
Это - полный источник моей быстрой конфигурации:
kill -9
(SIGKILL) всегда работает, если у Вас есть разрешение уничтожить процесс. В основном или процесс должен быть запущен Вами и не быть setuid или setgid, или необходимо быть корнем. Существует одно исключение: даже корень не может отправить фатальный сигнал в PID 1 ( init
процесс).
Однако kill -9
как гарантируют, не будет сразу работать. Все сигналы, включая SIGKILL, поставляются асинхронно: ядро может занять время, чтобы поставить им. Обычно, поставка сигнала занимает самое большее несколько микросекунд, только время, которое требуется, чтобы цель получила интервал времени. Однако, если цель заблокировала сигнал, сигнал будет поставлен в очередь, пока цель не разблокирует его.
Обычно, процессы не могут заблокировать SIGKILL. Но код ядра может, и процессы выполняют код ядра, когда они называют системные вызовы. Блоки кода ядра все сигналы при прерывании системного вызова привели бы к плохо сформированной структуре данных где-нибудь в ядре, или в более общем плане в некотором нарушаемом инварианте ядра. Таким образом, если (из-за ошибки или misdesign) системный вызов блоки неограниченно долго, не может эффективно быть никакого способа уничтожить процесс. (Но процесс будет уничтожен, если он когда-нибудь завершит системный вызов.)
Процесс, заблокированный в системном вызове, находится в бесперебойном сне. ps
или top
команда будет (на большинстве нельдов), показывают его в состоянии D
(первоначально для “диска”, я думаю).
Классический случай длинного бесперебойного сна является процессами, получающими доступ к файлам по NFS, когда сервер не отвечает; современные реализации имеют тенденцию не налагать бесперебойный сон (например, в соответствии с Linux, intr
смонтируйте, что опция позволяет сигналу прервать доступы к файлу NFS).
Можно иногда видеть отмеченные записи Z
(или H
в соответствии с Linux, я не знаю то, что различие) в ps
или top
вывод. Это технически не процессы, они - процессы-зомби, которые являются не чем иным как записью в таблице процессов, имевшей в наличии так, чтобы родительский процесс мог быть уведомлен относительно смерти своего ребенка. Они уйдут, когда родительский процесс обратит внимание (или умирает).
Когда-то процесс существует и не может быть уничтожен из-за:
top
это сообщено Ztop
это сообщено D.Это кажется, что у Вас мог бы быть процесс-зомби. Это безопасно: единственный ресурс, который использует процесс-зомби, является записью в таблице процессов. Это уйдет, когда родительский процесс будет умирать или будет реагировать на смерть своего ребенка.
Вы видите, является ли процесс зомби при помощи top
или следующая команда:
ps aux | awk '$8=="Z" {print $2}'
ps
. Кто может быть уверен, что обязательное поле всегда будет 8-м со всеми реализациями ps
во всех Нельдах? спасибо
– syntaxerror
07.02.2015, 19:15
Проверьте Ваш /var/log/kern.log
и /var/log/dmesg
(или эквиваленты) для любых подсказок. По моему опыту, это произошло со мной только, когда сетевое соединение монтирования NFS внезапно отбросило или разрушенный драйвер устройства. Мог произойти, если поломки жесткого диска также, я верю.
Можно использовать lsof
видеть то, что файлы устройств процесс имеют открытый.
kill -9
обычно не работал, даже после ожидания 60 минут. Единственное решение состояло в том, чтобы перезагрузить.
– Stefan Lasiewski
11.01.2011, 19:02
Если ответ @Maciej и @Gilles не решает Вашу проблему, и Вы не распознаете процесс (и выяснение, что это с Вашим дистрибутивом, не поднимает ответы). Проверьте на Руткит и любые другие знаки, что Вы принадлежали. Руткит более, чем способен к препятствованию тому, чтобы Вы уничтожили процесс. На самом деле многие способны к препятствованию тому, чтобы Вы видели их. Но если они забывают изменять 1 небольшую программу, они могли бы быть определены (например, они изменили top
, но нет htop
). Скорее всего, дело обстоит не так, но лучший сейф, чем извините.
Уничтожьте на самом деле средства, отправляют сигнал. существует несколько сигналов, которые можно отправить. уничтожьте-9, специальный сигнал.
При отправке сигналу приложение имеет дело с ним. если не ядро имеет дело с ним. таким образом, можно захватить сигнал в приложении.
Но я сказал, уничтожают-9, было особенным. Это является особенным в этом, приложение не получает его. это переходит прямо к ядру, которое затем действительно уничтожает приложение в первой возможной возможности. другими словами, уничтожает его мертвый
уничтожьте-15, отправляет сигналу SIGTERM, который обозначает СИГНАЛ, ОКОНЕЧНЫЙ, другими словами, говорит приложению выходить. Это - дружественный способ сказать приложению, что пора завершить работу. но если приложение не отвечает, уничтожают-9, уничтожит его.
если уничтожают-9, не работает, это, вероятно, означает, что Ваше ядро в неисправном состоянии. перезагрузка в порядке. Я не могу вспомнить это никогда случай.
Процесс init неуязвим для SIGKILL.
Это также верно также для потоков ядра, т.е. "обрабатывает" с PPID, равным 0.
Существуют случаи, где даже при отправке уничтожения-9 в процесс тот pid остановится, но перезапуски процесса автоматически (например, при попытке его gnome-panel
, это перезапустит): это могло иметь место здесь?
Как другие упомянули, процесс в бесперебойном сне не может быть сразу уничтожен (или, в некоторых случаях, вообще). Стоит отметить, что другое состояние процесса, TASK_KILLABLE, было добавлено для решения этой проблемы в определенных сценариях, особенно общий падеж, где процесс ожидает на NFS. См. http://lwn.net/Articles/288056/
К сожалению, я не полагаю, что это используется где угодно в ядре, но NFS.
ls
процесс, получающий доступ sshfs
смонтируйтесь, когда удаленный сервер будет иметь недостижимый биом. Существует ли решение для FUSE или sshfs, который я мог использовать в будущем для предотвращения таких ситуаций? 2.6.30 ядер
– imz -- Ivan Zakharyaschev
28.03.2013, 16:57
Сделанный небольшой сценарий, который помог мне много смотреть!
Можно использовать его для уничтожения любого процесса с именем в его пути (обратите внимание на это!!) Или можно уничтожить любой процесс данного пользователя, использующего "-u имя пользователя" параметр.
#!/bin/bash
if [ "$1" == "-u" ] ; then\n
PID=`grep "$2" /etc/passwd | cut -d ":" -f3`
processes=`ps aux | grep "$PID" | egrep -v "PID|ps \-au|killbyname|grep" | awk '{ print $2}'`
echo "############# Killing all processes of user: $2 ############################"
else
echo "############# Killing processes by name: $1 ############################"
processes=`ps aux | grep "$1" | egrep -v "killbyname|grep" | awk '{ print $2}' `
fi
for process in $processes ; do
# "command" stores the entire commandline of the process that will be killed
#it may be useful to show it but in some cases it is counter-productive
#command=`ps aux | grep $process | egrep -v "grep" | awk '{ print $2 }'`
echo "Killing process: $process"
echo ""
kill -9 $process
done
Во-первых, проверьте, является ли это Процесс-зомби (который очень возможен):
ps -Al
Вы будете видеть что-то как:
0 Z 1000 24589 1 0 80 0 - 0 exit ? 00:00:00 soffice.bin <defunct>
(Отметьте "Z" слева),
Если 5-й столбец не 1, то это означает, что это имеет родительский процесс. Попытайтесь уничтожить тот идентификатор родительского процесса.
Если его PPID = 1, не УНИЧТОЖАЙТЕ IT!!, думайте, который другие устройства или процессы могут быть связаны с ним.
Например, при использовании смонтированного устройства или самбы попытайтесь размонтировать ее. Это может выпустить Процесс-зомби.
Примечание: Если ps -Al
(или top
) показывает "D" вместо "Z", он мог быть связан с удаленным монтированием (как NFS). По моему опыту, перезагрузка является единственным способом пойти туда, но можно проверить другие ответы, которые касаются того случая более подробно.
из здесь изначально:
проверьте, показывает ли что-нибудь strace
strace -p <PID>
попробуйте подключиться к процессу с помощью gdb
gdb <path to binary> <PID>
если процесс взаимодействовал с устройством, которое вы можете размонтировать, удалить модуль ядра или физически отключить/отключить... тогда попробуйте это.
Tuve un tipo de este problema. Este fue un programa que había iniciado con strace
e interrumpido con Ctrl
+ C
. Terminó en un estadoT
(rastreado o detenido ). No sé cómo sucedió exactamente, pero no se podía matar con SIGKILL
.
Para resumir, logré matarlo congdb
:
gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit
Основываясь на подсказке из ответа Жиля, у меня был процесс, помеченный «Z» вверху(<defunct>
в ps ), который использовал системные ресурсы, у него даже был открыт порт, который ПРОСЛУШИВАЛ, и вы могли подключиться к этому порту. Это было после выполнения kill -9
. Его родителем был "1" (, т.е. init
), поэтому теоретически он должен просто повториться и исчезнуть. Но нет, он торчал, хотя и не бегал, и «не умирал»
Так что в моем случае это был зомби, но все еще потребляющий ресурсы... FWIW.
И он не мог быть убит никаким числом kill -9
х
И его родителем был init
, но он не собирался (очищаться ). т.е. init
был ребенок-зомби.
И перезагрузка не понадобилась для решения проблемы. Хотя перезагрузка «сработала бы» вокруг проблемы / ускорила выключение. Просто не грациозно, что еще было возможно.
И это был порт LISTEN, принадлежащий процессу-зомби (и несколько других портов, таких как CLOSE _Состояние WAIT, подключенное между локальным хостом и локальным хостом ). И он еще даже принимал соединения. Даже будучи зомби. Я предполагаю, что еще не удосужились очистить порты, поэтому входящие соединения по-прежнему добавлялись в журнал ожидания порта прослушивания tcp, хотя у них не было шансов быть принятыми.
Многие из вышеперечисленных заявлены как "невозможные" в различных местах в интерсетях.
Оказалось, что у меня был внутренний поток внутри него, который выполнял «системный вызов» (ioctl в этом экземпляре ), на возврат которого уходило несколько часов (это было ожидаемое поведение ). По-видимому, система не может завершить процесс «полностью», пока он не вернется из вызова ioctl
, думаю, он входит в землю ядра. Через несколько часов он вернулся, все прояснилось, все розетки были автоматически закрыты и т. д., как и ожидалось. Это какое-то томительное время в камере смертников! Ядро терпеливо ждало, чтобы убить его.
Поэтому, чтобы ответить на ОП, иногда приходится ждать. Долго. Тогда убийство, наконец, возьмет.
Также проверьте dmesg, чтобы узнать, была ли паника ядра (, то есть ошибка ядра ).
man 5 nfs
:"intr
/nointr
смонтируйте, что опция удерживается от использования после ядра 2.6.25. Только SIGKILL может прервать незаконченную операцию NFS на этих ядрах, и, если указано, эта опция монтирования проигнорирована для обеспечения назад совместимости с более старыми ядрами". – Reinstate Monica - M. Schröder 07.08.2012, 23:05sshfs
процесс (и аналогично с любой другой файловой системой FUSE: Вы всегда можете размонтирование силы этот путь). – Gilles 'SO- stop being evil' 28.03.2013, 21:42