On 07.11.2014 20:04, [email protected] wrote:

> Долго не обращал внимание на порядок старта rc-скриптов, пока одним 
> утром из-за проблем со стартом squid'a (как оказалось позже) я не смог 
> зайти на сервер через ssh. То есть вывод завис на старте squid'a и 
> чего-то ждёт, и соответственно не отрабатывает дальше остальные 
> rc-скрипты, в том числе и sshd.
> И действительно, rcorder показывает его в списке чуть ли не последним, 
> хотя должно быть наоборот (ИМХО). Ведь это чуть ли не самый важных 
> демон. Пускай не стартонёт mysql, squid, named, ftp, spamd, nginx, ... я 
> смогу зайти по ssh и понять, что, как и где исправлять.

Проблема, действительно, есть. Осложняется текущей политикой: при повышенном 
securelevel
система должна пускать локальных юзеров уже после того, как запущены все 
сервисы,
см. комментарии в /etc/rc.d/LOGIN

В Porters Handbook сказано, что практически все сервисы, запускаемые портами,
должны использовать REQUIRE: LOGIN, если нет особых причин делать иначе.
squid в том числе использует REQUIRE: LOGIN.

Получается конфликт зависимостей: при повышенном securelevel нельзя пускать 
юзеров
до старта сервисов, но надо запустить sshd до старта squid. Можно было бы 
выделить
новый класс сервисов, которые таки можно запускать после LOGIN и переместить
в него squid, но заставить всех маинтейнеров портов разом переделать свои порты 
нереально.

Более реально создать новый барьер SLOGIN по типу LOGIN, для того чтобы
критические скрипты типа fsck/mount/syslogd запускались до него
и sshd был бы предпоследним из них, а последним securelevel.
А остальные, включая все те, что REQUIRE: LOGIN (squid и почти все остальные 
портовые),
строго после нового барьера SLOGIN.

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

Только вот кто возьмется за анализ зависимостей существующих системных скриптов
в /etc/rc.d и корректно раскидает их на такие группы?

Ответить