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

ЗЫ
Я не так давно с линуксом занимаюсь, и поэтому думаю, что на самом деле кучу ещё информации должен был вам сообщить, поэтому переспросите пожалуйста и помогите разобраться.

Это сообщение отредактировал(а) Rickert - 16.5.2007, 05:34

существует не знаю насколько официальная конвенция, что процесс-демон при получении сигнала SIGHUP:

снова считывает конфигурационные файлы.
т.е., если демон написан корректно, его можно перестартовать при помощи сигнала hang-up:


удачи.

бывает, что kill неснимает такие процессы тада учим команду(юзать осторожно)
killall -s KILL <name>

если состояние будет TASK_UNINTERRUPTIBLE  то не снимает ) хотя init переиодически вроде как делает переназначение зомби на себя/ 

намучался я один раз с TASK_UNINTERRUPTIBLE   
запустил mount CD-ROM-а, а он (CD-ROM) видно был не исправен (шли постоянные попытки чтения, которые завершались неудачно), никакой kill не помогал вырубить mount, физическое нажатие на кнопку привод тоже игнорировал... пришлось перезагружать систему 

Это сообщение отредактировал(а) MAKCim - 15.5.2007, 22:01

Мне нужно именно убить процесс kill'ом, а потом запустить заново, потому что используются сторонние программы, которые не факт что перчитают конфиги при перезапуске.

для начала попробуй это, чтобы знать, в debug mode.

в крайнем случае, спиши один из скриптов в /etc/init.d/
и подкрути его создавать pid файлы на все процессы, а потом их убивать, и оживлять.

удачи.

В частности эксперементирую сейчас над dhcpd. Он изначально в фоне стартует, если ему передать принудительно -d, а потом в фон через &, после чего убить - то всё нормально


Как в него перейти?

Как это сделать?

ЗЫ
init.d нету, rc.d


Бага именно в том, когда программы, которые сами в фон уходят стартуются через daemon - при убиении становятся zombie. Может какая маза с pid файлом?

Это сообщение отредактировал(а) Rickert - 16.5.2007, 11:11

в какой-то папке есть все скрипты стартования и остановки демонов.
пусть будет rc.d
возьми какой-то из них и подправь под свои нужды.

зомби это статус, когда процесс уже убит, но его ресурсы еще не уже освобождены, но "учетная записть" в таблице процессов - еще не стерта, т.е. его PID еще не может быть использован системой для создания нового процесса. запись в таблице процессов еще не стирается, пока родитель данного процесса не сделает вызов wait(PID). 
если родитель этого не делает еще, то процесс остается в статусе ZOMBIE (defunct), а если не делает вообще, то теоритически процесс может остаться так до сл. перегрузки системы.

если зомби появляются - это обычно баг в процессе родителя, само по себе - не ужос, но если система загружена тучей таких процессов, то постепенно таблица процессов ( не бесконечная штука ) заполняется этими мертвыми душами, и система не сможет создавать новые процессы - нет свободных идентификаторов PID, абсурдная патология.

для "убития" зомби, нужно убить родителя. PID родителя находится в столбце PPID в таблице ps.

bilbobagginz, народ тут думает, что возможно должны быть какие-то зависимости от других приложений.

когда статус TASK_ZOMBIE - ресурсы уже освобождены, не освобожден дескриптор процесса в слябовом распределителе и структура thread_info в в стеке ядра(в 2.6.22 это чуть может отличаться)


Это сообщение отредактировал(а) kirjanov - 16.5.2007, 19:57

хмм.. подправил хрень, которую сам и написал.

Ну хорошо, что такое zombie, само по себе  - ясно. А вопрос: как с ним бороться-то? Запускается он от init'а.

Оказывается, init, которым пользуется наша контора, полностью переписывался одним программером, который сейчас в отпуске. Видать он не вызывает wait(PID). Приедет, будем смотреть.

интересненько он init оптимизировал.... 
расскажи как потом все закончилось!

bilbobagginz, ok  

Смотрел код init'а. Я понять не могу одной вещи. Там fork'а вообще нет. Смотрите как получается: когда мы стартуем что - либо, не из какого-либо приложения, по умолчанию pid родителя нового процесса (по сути программы), ppid, выставляется = pid'у init'а. в таком случае вопрос: что делать?  
В конце init'а бегает бесконечный цикл, со sleep'ом: как получить уведомление о том, что один из "детей" перешёл в состояние zombie, то бишь собирается завершиться, и соответственно, помочь ему, вызвав wait?

Это сообщение отредактировал(а) Rickert - 22.5.2007, 10:55

посмотри что такое signal.
после смерти каждого "дитяти" родитель получает SIGCHILD
нужно писАть обработчик этого сигнала.

Сейчас посмотрим...

Это сообщение отредактировал(а) Rickert - 23.5.2007, 04:22

Делаю так:

Файл /tmp/initconf.pid.log не создаётся.
То, что приведено - исходник init'а с которого грузится система.

Чувствую придётся брать исходный инит и править его руками... Аминь

честно говоря дебажить не хочется этот код, но:
1. системные вызовы принято спрашивать что они вернули.
2. советуют использовать не signal, а sigaction
3. что за вызов getedid() ? ( имелось в виду getegid() ? )
4. есть стандартный init, к которому можно обратиться и посмотреть как там все написано.

bilbobagginz, 

Функция самописная, не обращая внимания.

Вот, ищу исходник инита от слаки сейчас.
Что-то на http://packages.slackware.it не видать пока

зачем вам было переписать init  ?

Потому что надо ускорить загрузку ОСи. Распараллеливать процессы загрузки некоторых модулей и грузить ещё доп. ПО. Как всегда: директор заявил в документации, а программисты - мучайся  

init-ng не смотрели ?

bilbobagginz, что это такое? Можно по-подробнее?

Это сообщение отредактировал(а) Rickert - 24.5.2007, 06:56

Rickert, поток вопросов сам по себе дело положительное, но качество оных не на пике, поэтому начинаю острить (или выеживаться, называем как удобно).
и так на вопрос:

ответ: нет, нельзя подробнее, это секретная информация. не раскрою.

Юмор оценил