После падения сервера служба squidmill не поднялась: *** Log started Process detached (11794) PID-file: /var/run/squidmill/squidmill.pid Open server socket: /var/run/squidmill/squidmill.sock Delete the PID-file: /var/run/squidmill/squidmill.pid Socket error (98): Address already in use 0 main 1 ##execute-program *** Log finished Помогло только удаление файла /var/run/squidmill/squidmill.sock
А это точно ошибка? Кажется, при экстренном падении, нельзя гарантировать удаление файла. Обычно выводится сообщение, что, мол, проверьте всё и удалите lock-файл или socket для нормального запуска службы.
(В ответ на комментарий №1) > А это точно ошибка? Кажется, при экстренном падении, нельзя гарантировать > удаление файла. Обычно выводится сообщение, что, мол, проверьте всё и удалите > lock-файл или socket для нормального запуска службы. Прошлый раз также бились с pid-файлом. Что мешает с сокетом поступить также (принудительно удалять, как pid-файл в логе)?
В логе выше удаляется *новый* PID-файл, который создаётся в рамках попытки запуска службы двумя строками выше. Видимо, служба падает таким образом, что старый PID-файл успевает удалиться, а сокет — нет. Соответственно, squidmill думает, что кто-то запустил другой экземпляр из командной строки (в foreground, поэтому без PID), и не стартует. Я бы предложил разобраться не с тем, что нужно чистить "ошмётки" от падения службы вручную — это нормальная ситуация —, а с тем, почему squidmill вообще падает, если это происходит регулярно.
Снапшот виртуалки сделал, так что всегда можно вернутся. Но всё же а) лучше возвращать код ошибки, чтобы service не показывал, что служба запущена б) лучше критические ошиьбки выводить сразу в stderr, тогда понятно почему служба не стартует (как в httpd2 и dhcpd) в) ещё лучше при старте явно чистить все сокеты и pid во избежание.
а) и б) согласен: нужно проверять всё это до форка.
