У меня есть .rpm, который я создал. В своем %post часть, я делаю кое-что, и в конце этого скрипта я вызываю service httpd restart. Выдает следующую ошибку:
+ service httpd restart
Stopping httpd: [FAILED]
Starting httpd: (98)Address already in use: make_sock: could not bind to address [::]:81
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:81
no listening sockets available, shutting down
Unable to open logs
[FAILED]
Я получил это из подробного набора rpm (-vv). Итак, я знаю его о самом httpd restart, ни о чем другом. Согласно netstat только один процесс (httpd) прослушивает порт 81.
$ sudo netstat -nlp | grep 81
tcp 0 0 :::81 :::* LISTEN 29670/httpd
Я не понимаю, почему запуск http FAILS при остановке и снова FAILS при запуске.
Есть идеи, как это решить?
Сценарий init.d (вызываемый служебной командой) в зависимости от реализации не так умен, как вы думаете. То, что я вижу во многих из этих реализаций, заключается в том, что выполнение "start" убирает номер процесса исходного процесса httpd (то есть того, который выполняется как root). Затем, когда вы выполняете процесс 'stop', он просто убивает (с соответствующим номером сигнала) корневой процесс httpd.
Иногда подчиненные процессы становятся сиротами и не уничтожаются (потому что они могут быть сломаны и не реагировать должным образом на сигнал родителей). Если это так, то порт все еще присоединен подчиненными процессами, и выполнение «перезапуска» или «старта» не удастся.
Что вам нужно сделать, так это сделать "ps -aef | grep httpd | grep -v grep"найти сломанные подчиненные процессы и убить их напрямую (используя kill -9 pid#). Вполне может быть несколько сломанных процессов.
После того, как все неработающие процессы будут удалены, вы можете снова «запустить» сервер Apache.
Это иногда указание на то, что хост скомпрометирован или выполняет некорректный процесс. Я говорю «скомпрометировано», потому что многие вредоносные программы переходят в фоновый режим и игнорируют сигналы. Однако они обычно не закрывают дескрипторы открытых файлов, которые присутствовали при вилке.
Это приводит к ситуации, когда сокет, который был открыт apache, унаследован вредоносной программой, которая игнорирует сигналы завершения. Это вызывает проблему «невозможно привязать для решения».
Попробуйте ввести команду pgrep -l -u apache и посмотрите, появятся ли какие-либо процессы, не относящиеся к apache.