Как вы поддерживаете работу пользовательских сервисов systemd через mosh?
Единственное, что абсолютно требует перезагрузки, - это изменение ядра. Любой процесс может быть убит, если программа (или какая-то библиотека или другой файл, от которого она зависит) была обновлена, но это не относится к ядру.
На самом деле, иногда можно исправить ядро Linux прямо в памяти. Есть несколько инструментов, которые работают хотя бы в некоторых случаях: Ksplice , Kpatch , kGraft … Каждый из них работает в некоторых простых случаях, но не во всех; они обычно работают с обновлениями безопасности, поскольку они не меняют никакого внутреннего интерфейса (особенно форматов структур данных), но не для обновления между версиями ядра. Ubuntu LTS поддерживает исправление ядра с помощью livepatch с 16.04 с ядром 4.4 с проприетарным клиентом.
Хотя все, чего нет в ядре, можно обновить в работающей системе, для этого по-прежнему требуется перезапуск затронутых процессов. На сервере это означает перезапуск серверов, использующих исполняемый файл, библиотеку, плагин, файл данных, конфигурацию или другую зависимость, которая была обновлена. На настольном компьютере это может означать, что пользователи должны выйти и снова войти в систему (например, если это ошибка в графическом драйвере). Точное определение того, что нужно перезапустить, может быть трудным, поскольку это зависит от точного характера исправления ошибки и того, как используется программа. Вместо того, чтобы выполнять огромный объем работы, необходимой для точного определения этого, Ubuntu не рискует и рекомендует перезагрузку пакетов, которые думают, что перезапуск службы будет слишком утомительным.Это работает так: вы получаете запрос на перезагрузку, когда сценарий после установки пакета (в данном случае после обновления) объявляет, что требуется перезагрузка (см. Как я могу определить, для какого пакета требуется перезагрузка моего система? ).
В очередной раз наблюдается несоответствие между концепцией systemd о пользовательских -сеансах входа в пространство и тем, как работает такая программа, как mosh. (Это далеко не единственный подобный конфликт. Были проблемы с tmux, screen, emacs в новом режиме демона, deluged и другими. Однако они не входят в рамки этого ответа.)
Понятие systemd заключается в том, что подключаемый модуль PAM -передает набор -вверх и вниз -сеансов входа в систему на logind, который, в свою очередь, обрабатывает запуск и останов -управление пользовательскими службами, при первом входе в систему -и при последнем выходе из системы -.
Это вступает в силу с сеансом SSH, который вы используете для инициации mosh-server. Но этот сеанс -недолговечен и заканчивается после того, как mosh-serverзапущен и запущен. Более того, mosh-serverне является программой входа в систему и не имеет никакого отношения к PAM, поэтому подключаемый модуль PAM -не работает. Следствием этого является то, что logindвидит только один очень короткоживущий SSH-сеанс и в результате запускает, а затем снова быстро останавливает вашу подсистему управления службами для -пользователей.
Единственный способ, которым systemd может справиться с этим, — сообщить logind, что управление вашими -пользовательскими службами «задержится» после окончательного -выхода из системы. Вы делаете это с помощью подкоманды enable-lingerкоманды loginctl.
Более того, это относится не только к мошу. Любая система, использующая кратковременные сеансы SSH, особенно если их много, сталкивается с проблемой logindзапуска и остановки для -управления пользовательскими службами снова и снова.