Почему systemd выключает ssh первым

то есть ты спрашиваешь почему сетевые подключения к sshd отключаются до отключения сети а не после?

Встречный вопрос. Зачем её отключать последней?

как, зачем чтобы в BIOS залезть 8)

Потому что пользовательские сессии завершаются практически до всего.

и тому есть объяснение - при некоторых настройках юзер может прервать ребут, т.е. сначала все убить а потом, ээ «отменяем» - превратит систему в тыкву. Да и смысла нет сидеть в консоли когда от системы только инит остался.

Я бы сделал исключение для рута, на самом деле. Более того, я почему-то думал, что оно существовало (см. удалённые).

*записал себе в очень длинный TODO-список*

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

зы. в своей практике неоднократно сталкивался с тем что «Type root password or Ctrl-D» - при запуске вгоняет админов, блин в ступор.

Да и смысла нет сидеть в консоли когда от системы только инит остался.

Single user mode? Правда каноничный single user mode работает в безсетевом режиме.

гм, разве что как repair вариант

Потому что systemd-филы решили что тебе это не нужно.

и тому есть объяснение - при некоторых настройках
юзер может прервать ребут,

А может, напротив, подумать-подумать, да и добавить «reboot -f». Необходимось редкая весьма, но вероятность отлична от нуля.

Кстати да. Интересный вопрос. Уже натыкался на ситацию, когда сеть уже поднята, дальше с каким-то юнитом проблемы, а ssh ещё не поднят и приходится зачем-то загружаться в resque.target. Хотя сеть уже поднята, а ssh единственный нормальный вариант работы

Надо посмотреть на зависимости, которые эти мейнтейнеры с потолка написали. А то позор джунглей, почти винда получается

А от какого *.target зависит sshd.service ?

Поставь от более раннего(который раньше запускается) и он будет запускаться раньше и отваливаться позже. Покажи systemctl list-units --type=target .

Вероятно для тебя будет достаточно прописать в файле sshd.service

[Unit]
Wants=network-online.target
After=network.target network-online.target

P.S. Надеюсь меня сейчас поправят, что оригиналы не надо трогать, а надо только вносить изменения к оригиналам. Но вот беда, не помню я как это делать.

Если это не сработает, то воспользуйся самопалом - http://unix.stackexchange.com/questions/209832/debian-systemd-network-online-...

А не проще выкинуть networking и один раз настроить systemd-networkd? По ссылке же дикий скриптовый костыль, который эмулирует systemd-networkd-wait-online.service.

Кмк, если ssh у вас слушает ANY интерфейс, то можно смело стартовать до запуска сети, а тушиться после, ничего страшного в этом нет.

systemd и так кусок г@#$а, зачем ему доверять настройку сети?

Если ssh слушает wildcard, то ещё проще юзать сокет-активацию (sshd@). Да и если не wildcard, всё равно же порт файрволлом огораживать.

Свои личные комплексы оставь при себе. 9999-й срач на эту тему ничего не изменит.

А не проще выкинуть networking и один раз настроить systemd-networkd?

Он может для кого то и не плох, но честно говоря для меня очень упрощен. На своей генте взгромоздил его(networkd) в начале, но спустя время снес и использовал модификацию стандартного net-misc/netifrc с поддержкой systemd. Причина - ни перезапустить интерфейсы, не отработать подключени кабеля, и многое другое для меня критичное.

Это надо доки по systemd-networkd покурить. Там в юнитах хренова тьма опций. Хз на счет рабочести всего этого, но локализация всего в одном месте меня радует.

доки по systemd-networkd покурить

читал в том то и проблема - не реализовано и не собираются реализовывать, а использовать сторонние средства+networkd смысла уже не увидел.

да, все верно говорят. после команды reboot и до отключения сети много чего может произойти - ситуация когда написал ребут и ничего не ребутается не такая и редкая. с другой стороны есть и обратная ситуация когда sshd запускается в конце загрузки системы, на RHEL6 из-за этого была вечная проблема с маунтпоинтам (multipath, iscsi, Powepath и в том духе), когда такой маунтпоинт почему-то недоступен, fsck отваливается с ошибкой и требует пароль рута, сеть поднята, а на сервер не зайти.
Как уже сказали, многие сервисы вообще не зависят от наличия или отсутвия сети, когда они слушают на any. Но их упорно запускают после сети, иногда намного позже.

reboot -f

Не припомню что бы спасло. Если уже попа, то так и есть. (я не про ненужноД)

sysrq почти всегда срабатывает.

А magic power/reset button вообще всегда. Мы вроде про ssh говорили?

*записал себе в очень длинный TODO-список*

Разработчик systemd?

Составитель списков

Добавь сеть и ssh в rescue.target.

Раньше контрибьютил время от времени. Сейчас скорее нет, чем да.

Как уже сказали, многие сервисы вообще не зависят от наличия или отсутвия сети, когда они слушают на any. Но их упорно запускают после сети, иногда намного позже.

Эти зависимости пишут, чтобы они останавливались до сети. Односторонних (only-stop) зависимостей порядка, к сожалению, нет.

Не припомню что бы спасло.

Просто если какое-то приложение не даёт системе завершиться, но ядро ещё живо, то «reboot -f» - это примерно то же самое (или, вовсе, то же самое - можно по коду посмотреть) что и

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Как будто кнопку reset надавили. Но вот это «echo ...» фиг вспомнишь, когда надо, «reboot -f» помнить проще. И зависит ещё от zgrep CONFIG_MAGIC_SYSRQ /proc/config.gz

Просто повторю, мне ни разу не везло. Т.е. полный трындец, ребутаться не будем, а дальше «ноги в руки»/«удаленные руки»/etc. Без физики не получалось. Возможно такая у меня «карма». Но вы верно написали, вероятность все-таки «отличная от нуля», кому-то возможно и помогло.

Ну на моей памяти раз 5-10 приходилось так ребутать. Т.е. просто reboot и reboot -f ничего не делали, приходилось через sysrq. Сейчас просто наплодили всяких виртуализаций, которые лепят как ни попадя, в итоге получай периодами полную хрень. Всякие Oracle Vm только сейчас становятся стабильными, хотя на рынке уже лет 5.