LINUX.ORG.RU

Killall не видит процессы


0

1

Запукаем стоп апача:

root@supernova:/home/olegchir# /etc/init.d/apache2 stop
 * Stopping web server apache2                                                    * 
 * There are processes named 'apache2' running which do not match your pid file which are left untouched in the name of safety, Please review the situation by hand.

Смотрим, действительно ли остановился. Доверяй да проверяй!

root@supernova:/home/olegchir# ps aux | grep apache2
www-data 11302  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11303  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11304  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11305  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11306  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start

Ну вот, а еще друг называется.

А теперь давай досвиданья! killall apache2

Но что мы видим?

root@supernova:/home/olegchir# killall apache2
apache2: no process found

root@supernova:/home/olegchir# ps aux | grep apache2
www-data 11302  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11303  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11304  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11305  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11306  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start

процессы есть, а killall их не видит

олсо, по kill -9 по отдельнности они убиваются ОК

WTF?

★★★★☆

Ответ на: комментарий от kulti

На сцену выходит Чак Норрис и делает удар с разворота!

killall -9 apache2

Но что же это?

root@supernova:/home/olegchir# killall -9 apache2
apache2: no process found

root@supernova:/home/olegchir# ps aux | grep apache2
www-data 11302  0.0  0.0 357424  7884 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11303  0.0  0.0 357424  7884 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11304  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11305  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start
www-data 11306  0.0  0.0 357176  7176 ?        S    18:31   0:00 /usr/sbin/apache2 -k start

Похоже, это поддельный Чак Норрис!

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от kulti

pkill тоже не работает, кстати

ты знаешь эти ваши седы-авки? Нужен цикл, чтобы пробежался по всему выхлопу ps aux, для каждой строчки выдрал pid (сначала строка, потом пробел, потом интовое число - его), и сделал по ним kill -9

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от kulti

вах. хотел kill -9 $(pgrep apache2), но pgrep apache2 выдает пустоту

а между тем, у меня не галлюцинации! Заходя на localhost отображается страничка, которую рендерит Апач

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)

There are processes named 'apache2' running which do not match your pid file which are left untouched in the name of safety, Please review the situation by hand.

читать научись, да? Ну или открой для себя гуглотранслятор, раз 100 слов не осилил выучить...

emulek
()
Ответ на: комментарий от stevejobs
ps ax -eo pid,cmd | sed -n 's/ \([0-9]*\) apache2.*/\1/p'
anonymous
()
Ответ на: комментарий от stevejobs

ты просил. Это просто печатает, если понравится, смени ~p н ~e в конце

sed -rn 's~^\S+\s+(\S+)\s+.*\s/usr/sbin/apache2\s.*~kill -9 \1~p'

emulek
()
Ответ на: комментарий от stevejobs

Как связана работа утилиты kill c пид-файлами?

утилита kill жрёт PID'ы. Из PID-файлов. В данном случае, с кормлением проблема, нужно из ложечки, ручками. Я не знаю, ппочему у тебя так, читай лог.

emulek
()
Ответ на: комментарий от emulek

утилита kill жрёт PID'ы. Из PID-файлов.

facepalm. А есть что-нибудь, что работает не с пидами, а с реальным деревом процессов?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

facepalm. А есть что-нибудь, что работает не с пидами, а с реальным деревом процессов?

pid-файл — просто семафор. Сигнализирует о том, что ЭТОТ апач уже запущен. Если попытаться запустить ещё один, она

1. скажет — «уже один запущен»

2. убьёт ненужный pidфайл мёртвого апача, и запустит другой

у вас какой-то третий случай. Например если вы ручками убили апач или его файл. Разбирайтесь, в чём проблема...

emulek
()
Ответ на: комментарий от emulek

может, проблема в том, что апач при старте первым процессом спавнит еще несколько раз себя. А при остановке через /etc/init.d/apache2 stop эти процессы не умерли вместе с основным процессом.

решилось ПЕРЕЗАГРУЗКОЙ

Вопрос, почему они не умерли и как это предупредить в будущем?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от i-rinat

уже ничего :-( я решил, что страсть к исследованиям не стоит ждать несколько часов, пока кто-нибудь с лора что-нибудь ответит и сделал физическую перезагрузку. Теперь работает.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

решилось ПЕРЕЗАГРУЗКОЙ

Вопрос, почему они не умерли и как это предупредить в будущем?

Теперь тебе поможет только гадание на кофейной гуще.

i-rinat ★★★★★
()
Ответ на: комментарий от stevejobs

я решил, что страсть к исследованиям не стоит ждать несколько часов, пока кто-нибудь с лора что-нибудь ответит

Ты совета не спрашивал, но я его всё равно дам: нет смысла спрашивать на форуме, если не можешь подождать ответа. Иногда в тему через _неделю_ приходит анонимус и пишет нужный ответ.

i-rinat ★★★★★
()

возможно, что killall получает список процессов, которые прнадлежат uid, который его запустил. А в данном случае они принадлежат www-data, а не root.

dikiy ★★☆☆☆
()
Ответ на: комментарий от dikiy

killall получает список процессов, которые прнадлежат uid, который его запустил

Не-не. У меня тоже апачи под www-data, killall сказал: «у тебя прав нету».

i-rinat ★★★★★
()
Ответ на: комментарий от stevejobs

Вопрос, почему они не умерли и как это предупредить в будущем?

вот на этот вопрос я затрудняюсь ответить. Ибо дочерние процессы в норме умирают вслед за родителем. Что-то пошло не так.

emulek
()
Ответ на: комментарий от dikiy

А в данном случае они принадлежат www-data, а не root.

это нормально. Один апач(от рута) запускает кучу других(от юзера www).

Может проблема в том, что killall отправила сигнал «сдохни» всем процессам, но убились почему-то не все. Надо отдавать сигнал только главному, который от рута.

emulek
()
Ответ на: комментарий от stevejobs

я не знал, что перезагрузка поможет.

наверняка ты что-то там ручками шаловливыми крутил, скажи честно?

а перезагрузка — да, помогает. Ещё можно все процессы ручками грохнуть и pid стереть.

emulek
()

Похоже на взлом. Что на сервере хостится? Есть ли сайты на ПХП и тд? Смотрит ли в инет? Типичный хаксорский прием - запуск скриптов из под пользователя apache/www-data/nobody с именем процесса веб-сервера чтобы замаскировать. Зря не узнали в чем дело, может повториться.

FreeBSD ★★★
()
Ответ на: комментарий от stevejobs

может, проблема в том, что апач при старте первым процессом спавнит еще несколько раз себя. А при остановке через /etc/init.d/apache2 stop эти процессы не умерли вместе с основным процессом.

В htop можно посмотреть, кто кого породил (режим F5-Tree).

justAmoment ★★★★★
()

Ну ты прям в тему, у меня аналогичная история на одном из стендов, только с IBM WebSphere. Пошел по быдло-методу:

#!/bin/bash
was_pids=$(ps aux | grep -i websphere | grep -v grep | awk '{print $2}')
for pid in "${was_pids[@]}"
do
        kill -9 $pid
done

Insomnium ★★★★
()
Ответ на: комментарий от justAmoment

но потом их еще и убивать надо скопом! Не руками! Хорошо бы иметь утилиты для работы с деревом реальных процессов (а не пидов), н-р кроме убийства смену приоритета для дерева

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от Insomnium

а что за ведро? Может, это баг нового ведра?

root@supernova:/home/olegchir# uname -a
Linux supernova 3.11.0-11-generic #17-Ubuntu SMP Tue Oct 1 19:42:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

спасибо за скрипт!

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Не думаю, что тут дело в ведре, но вообще:

Linux <censored> 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
P.S.: CentOS release 6.4 (Final)

Insomnium ★★★★
()
Ответ на: комментарий от stevejobs

У тебя просто приколбасило систему, смотри на предмет глюков железа под высокой нагрузкой. Для диагностики нужно видеть содержимое инит-скрипта, я на память не помню. Оно, по-моему, апач не через kill убивает, а посылает сигнал завершения процессам апача, собственно апач убирает свои семафоры, но сам не прибивается, занимая сокет. Отсюда и ноги. Рекомендую потестить память. А вообще неумение сообщать версии используемого ПО - это моветон, зачатки телепатии и опыт присутствуют далеко не у всех.

Deleted
()

P.S.

* There are processes named 'apache2' running which do not match your pid file which are left untouched in the name of safety, Please review the situation by hand.

Вообще еще и читать следует научиться.

Deleted
()
Ответ на: комментарий от Deleted

я могу дать выхлоп всего состояния системы, но от объема этого текста сервер ЛОРа перегреется и сгорит)

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от Deleted

это тебе читать следует научиться :-) я не спрашивал, почему инитскрипт апача не может его убить. Да насрать на это вообще, я привык, написатели пакетов в убунте упарываются чем-то походу. Удивительно, почему не работает ни одна из утилит для kill кроме непосредственно kill -9, и почему не прибиваются потомки основного процесса апача при смерти родителя.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Достаточно - дистр, версию апача и ядрышка с glibc. Хотя в данном случае дистр не нужен - такое же поведение при High load бывало у меня на центоси. А как выяснилось, та не в курсе, как работает kill.

В общем дело в чем, init-скрипт в убунте написан правильно. Теперь я расскажу тебе, как работает kill.

Команда kill process просто посылает сигнал завершения работы заданному процессу. Т.е. закрытие процесса должно произойти благодаря его собственным стараниям: апач при этой команде должен подчистить свои .pid и завершиться. Но что-то пошло не так и .pid исчезли, а вот процесс остался висеть. Для работы команды kill важно соответствие .pid имени процесса, в противном случае это означает либо скомпрометированную систему, либо еще чего, для чего требуется вмешательство системного администратора. Команда kill process -9 пришибет процесс практически в любом случае, так как здесь уже посылается сигнал не процессу, а конкретно ядру. Т.е. уже механизмы другие и завершает процесс ядро. Поэтому по PID оно убивается через kill, для всех остальных операций для послания корректного сигнала нужно существование файлега .pid или .sock и т.п., сигнализирующего что сокет занят конкретным процессом с конкретным processID. Поэтому команда killall не в состоянии найти соответствие PID имени процесса, а команда kill -9 пославшая ядру KILL PID xxx - отрабатывает.

Оюъяснил как смог.

Deleted
()
Ответ на: комментарий от Deleted

Но что-то пошло не так и .pid исчезли, а вот процесс остался висеть

.pid и не появлялись. При старте он делает .pid только на основной процесс, тот что исполняется от рута.

3.11.0-11-generic #17-Ubuntu SMP, Apache/2.4.6 (Ubuntu), loaded modules = core mod_so mod_watchdog http_core mod_log_config mod_logio mod_version mod_unixd mod_unixd mod_access_compat mod_alias mod_auth_basic mod_authn_core mod_authn_file mod_authz_core mod_authz_host mod_authz_user mod_autoindex mod_deflate mod_dir mod_env mod_filter mod_mime prefork mod_negotiation mod_perl mod_php5 mod_rewrite mod_setenvif mod_status.

#include <stdio.h>
#include <gnu/libc-version.h>
int main (void) { puts (gnu_get_libc_version ()); return 0; }

выхлоп: 2.17

Оюъяснил как смог.

спасибо! а есть программы, которые сразу обращаются к ведру, покладывая прибор на программу?

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Ну это чайлды апача, они свои .pid и не создают. Они должны мониторитсья головным процессом. Насколько я понимаю, в вашем случае могли сработать kill -9 /usr/bin/apache2 -a и killall /usr/sbin/apache2 -e

немного поразмыслил и пришел к выводу, что просто апач прибивался и не убивал своих чайлдов. Не mpm_worker случаем?

Deleted
()
Ответ на: комментарий от stevejobs

P.S. сам такого сота не знаю - грепаю ps -aux и прибиваю по PID.

Deleted
()
Ответ на: комментарий от stevejobs

Удивительно, почему не работает ни одна из утилит для kill кроме непосредственно kill -9

то есть ты не понимаешь, как работает kill?

false ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.