1) Заходим по ssh (по ключу) на удаленную машину 2) screen mc Запускаем долгий процесс 3) связь рвется, ssh сессия разорвана 4) Заходим туда же снова 5) screen -r There is no screen to be resumed. @$%!!! Итоги работы компьютера за последние часы пропали. Это теперь так и будет?
Это фича systemd, отключается настройкой.
Подскажите, пожалуйста, как найти эту настройку. В сети море неверных решений проблемы с nohup, disown и т.д. Помогло systemd-run --scope --user screen mc но хочется стандартного поведения и не заучивать длинные лишние команды...
KillUserProcesses=no
Установите пакет systemd-settings-disable-kill-user-processes, это самый простой способ.
действительно, NOTABUG Но чаще всего при коротких процессах результат работы screen отслеживают и ssh-подключение к серверу не закрывают. А вот если что-то длительное запускают и, отключившись по Ctrl+A+D еще и отключаются от ssh-сессии, а потом обнаруживают, что ни процесса, ни screen нет, то это _очень_ неприятно, портит репутацию особенно _серверным_ дистрибутивам.
(In reply to zvn from comment #5) > действительно, NOTABUG > > А вот если что-то длительное запускают и, отключившись по Ctrl+A+D еще и > отключаются от ssh-сессии, а потом обнаруживают, что ни процесса, ни screen > нет, то это _очень_ неприятно, Да. > портит репутацию особенно _серверным_ > дистрибутивам. Тогда надо завести другую багу на _серверный дистрибутив_, наверное, и в ней ставить вопрос о другом дефолте. А в сизифе пакет как пакет. В пространстве решений есть несколько точек. Кому-то удобно настроить KillUserProcesses=no. Кто-то предпочтёт включить linger одному усеру. Иные готовы засунуть screen-сеансы в юниты, которые умирать не будут. Но, конечно, лучше, чтобы такой механизм был уже реализован и приезжал в пакете screen (точно не в пакете systemd).
речь шла не только о серверных дистрибутивах. Например, https://www.altlinux.org/Обновление_ОС содержит рекомендацию использовать screen и, вообще говоря, даже при домашнем использовании можно на это наткнуться и это тоже портит репутацию, уже совсем не серверным дистрибутивам. смотрел в других дострибутивах loginctl show-session $XDG_SESSION_ID | grep KillUserProcesses как-то совсем не yes.
