Это странная ситуация, с которой я столкнулся. У нас есть тестовый сервер вне сайта (или вне сайта, где я работаю). Чтобы получить доступ к серверу, мне нужно подключиться к его сети через VPN.
Я запустил screen для выполнения долго работающего процесса. После запуска процесса я сделал следующее, чтобы проверить жизнеспособность screen:
- Я оторвался от сессии
- выполнил screen -ls для проверки PID
- ps -ef | grep экран
- экран -r PID
После выполнения этих команд и повторного присоединения/отсоединения к сеансу я увидел, что был сеанс экрана.
Вот странная часть. Я возвращаюсь на следующий день, а сеансов screen нет. Я запустил эти cmds выше, чтобы проверить, но ничего нет. Однако мой процесс все еще работает. Я не использовал nohup для запуска своего процесса, но по какой-то счастливой причине мой процесс не умер вместе с сеансом.
Кто-нибудь знает, что могло произойти? Почему я потерял сеанс экрана и почему мне повезло, и мой процесс продолжал работать?
Спасибо за любое просвещение. =)
решение1
Вместо этого вы можете воспользоваться grep, SCREENчтобы убедиться, что ваш экран действительно не запущен.
В некоторых системах есть очистители tmp, которые удаляют файлы в /tmp, /var/tmp, /var/run, или подобных. Это может привести к screenневозможности найти файлы сокетов. Если вы можете определить PID своего сеанса, вы можете сделать, kill -CHLD <PID>чтобы указать screenпереписать его файл сокета. screen -rтогда это должно снова работать.
Если это то, что происходит, вам, вероятно, следует настроить screenиспользование другого каталога для сокетов.
решение2
Это случилось со мной и моим коллегой снова недавно, и он предложил это как возможную причину, почему это произошло. Он думает, что из-за того, что компания задерживает наше соединение, она убивает экран.
У нас было запущено несколько сеансов screen, каждый со своей собственной долго выполняющейся задачей (для простоты назовем их сеансами A и B). Задача в сеансе A завершилась раньше времени, и этот сеанс вернулся к приглашению. Когда из-за бездействия истек период ожидания, он вывел нас из сеанса A. Сеанс B все еще выполнял свою задачу, когда это произошло, но мы думаем, что когда родительский процесс умирает (в данном случае screen), он забирает с собой все сеансы.
Процесс, работавший в сеансе B, теперь наследуется родительским процессом screen, который является процессом init или процессом 1, и, таким образом, продолжает работать, когда мы проверяем его на следующее утро.
Эта гипотеза была как бы подкреплена запуском эксперимента. Он был запущен на Centos. Мы запустили screen и открыли два сеанса. В одном сеансе мы периодически запускали cmd, чтобы он оставался активным. Другой мы игнорировали. Примерно через 10 минут screen был завершен, а вместе с ним и оба сеанса, которые мы открыли.