По умолчанию, sshd стартует чуть ли не одним из последних (в том числе после squid’a, samb’ы, spamd и других демонов). Если на каком-то этапе один из таких демонов будет ожидать ввода пользователя, получим нерабочую систему, с невозможностью зайти удалённо. Почему так происходит? Ответ, оставлю цитатой юзера Eugene Grosbein:
Проблема, действительно, есть. Осложняется текущей политикой: при повышенном 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 и корректно раскидает их на такие группы?
После некоторых обсуждений, “родился” вот такой патч:
--- /etc/rc.d/sshd 2014-12-22 15:12:14.000000000 +0200 +++ /etc/rc.d/sshd 2014-12-22 15:11:22.000000000 +0200 @@ -4,7 +4,8 @@ # # PROVIDE: sshd -# REQUIRE: LOGIN FILESYSTEMS +# BEFORE: LOGIN +# REQUIRE: DAEMON # KEYWORD: shutdown . /etc/rc.subr
