Может ли процесс, который был запущен в сеансе tmux, заснуть?
Может ли процесс, который был запущен в сеансе tmux, заснуть? Если да, то какова причина (причины), как предотвратить это?
Пример причины вопроса: вчера я запустил процесс на сервере (обучающий нейронные сети, он выводит текущую эпоху обучения на стандартный вывод). У меня было разделенное окно, и в том, в котором запущен процесс, я отключил режим прокрутки перед отключением от сеанса.
Сегодня я возвращаюсь, и это не продвинулось вообще.
Точнее, эпоха такая же. После выхода из режима прокрутки, теперь он счастливо продолжился.
Журнал читает что-то вроде
...
Эпоха 40: 1ч несколько минут
Эпоха 41: 12 ч несколько минут
Epoch 42: 12h еще несколько минут
...
Эпоха 73: 13
Это означает, что время, которое потребовалось, чтобы добраться от эпохи 0 до 49, было определенно меньше чем два часа; с эпохи 40 до 41 года это заняло около 11 часов (!), с эпохи 41 до 76 среднее время за эпоху составляло около 1,7 минуты. Эпохи находятся в цикле, и не должно быть причины, по которой один занимает в 400 раз больше времени, чем другие.
Дополнительная информация: этот "сон" не происходит каждый раз, когда я отсоединяюсь, находясь в режиме прокрутки. Но это уже случилось раньше. Режим прокрутки может вообще не иметь к этому никакого отношения.
Программа представляет собой скрипт на Python, включающий в себя код тензорного потока, работающий на графическом процессоре; команда для запуска была:
python train_script.py 2>&1 | tee train_log.txt.
Для Tmux я использую tmux attach повторно прикрепить стандартное сопоставление клавиш и ctrl-b + d отделить, ctrl-b + up(number block) начать прокрутку, q выйти из режима прокрутки.
1 ответ
Я знаю, что опаздываю, но со мной случалось то же самое несколько раз. Среда немного отличается, я запускаю скрипт на языке Python во внешнем интерфейсе, который отправляет задания, перемещает файлы, собирает больше заданий и т. Д. Одно вычисление обычно занимает около часа.
Однажды вечером я запустил свой скрипт на python, несколько раз проверил его, а затем оставил tmux в режиме прокрутки, отсоединился и проверил скрипт утром. Казалось, что он застрял, поэтому я проверил, выполнялись ли какие-либо работы в данный момент, но ни одна из них не была. Я проверил, присутствовали ли ожидаемые файлы, чего не было. Мой сценарий не распечатывал примечание "все работы выполнены успешно", поэтому он все еще работал, но ничего не делал. Я вышел из режима прокрутки, и неожиданно сценарий продолжился, произвел намного больше вывода и, о чудо, отправил еще одну партию вычислительных заданий.
Так вот, это может быть просто странное время, и, к сожалению, у меня нет повторяющихся этапов с метками времени, чтобы увидеть, как долго оно застряло, но это происходит уже третий раз, я действительно сомневаюсь, что это случайное время.
Вы когда-нибудь выясняли, почему / если ваш сценарий застрял? Я выйду из режима прокрутки с этого момента, прежде чем отсоединяться, и посмотрю, имеет ли это значение.
Редактировать: Очевидно, это была известная ошибка в tmux, но не было замечено, исправлена ли она: https://github.com/tmux/tmux/issues/431. Версия tmux на машине, на которой я работаю, устарела: tmux 1.8, Итак, по сути, обходной путь будет:
Всегда выходите из режима прокрутки и правильно отсоединяйтесь от tmux.
Может ли процесс, который был запущен в сеансе tmux, заснуть?
В основном все tmux делать - это прикреплять собственные файловые дескрипторы вместо STDIN/STDOUT/STDERR к запущенному процессу внутри tmux это позволяет ему работать, пока он не подключен к консоли.
Ниже приведен простой скрипт, который вы можете запустить, используя тот же рабочий процесс (присоединение / отсоединение от tmux сеанс) вы описали:
#!/bin/sh
c=1000
while [ $c -ne 0 ]; do
date '+%Y-%m-%dT%H:%M:%S' | tee -a log.txt
sleep 1
done
даже если бы вы переключились в режим прокрутки, а затем отсоединились от tmux сеанс, он все равно будет продолжать работать, вы можете проверить log.txt файл, так что это не проблема с tmux,