Знатокам tmux: отследить закрытие эмулятора терминала

если в последнем не запущена какая либо команда

Лучше так: «Если в последнем не ожидается ввода какой-либо команды»

А тебе обязательно, чтобы ЭТ не закрывался, или тебе главное, чтобы программа, в нем запущенная, работала, даже если само окно ЭТ закрылось? Если последнее - то

setsid yourprogramm

Похоже что топикстартер хочет не совсем это.

Он хочет умный детач сессии: если что-то в tmux работает — детач при закрытии терминала с tmux, если нет — закрываем терминалы, завершаем сервер.

Но вряд ли tmux может так сам по себе.

Да, я хочу именно это. Может быть ЭТ (в моём случае st) запускать в какой-нибудь обёртке из bash кода? Всё равно открываю с горячих клавиш. Только не представляю, как убедить st при закрытии вернуть, например, последний заголовок окна?

запускать в какой-нибудь обёртке из bash кода

Если tmux умеет выдавать список потомков, то извратиться можно. Но как я понял, он так не умеет.

Благодарю.

В Linux можно пройтись по procfs, построить дерево процессов (операция небыстрая и затратная) и из него ванговать — надо завершать сервер tmux, или нет. Писать такой скрипт на Bash будет больно, лучше взять какой-нибудь Python.

Что за workflow такой интересный? В жизни не помню, чтобы закрывал tmuxы не в отладочных целях.

Что за workflow такой интересный?

Если ты единственный юзер на машине, то такое не нужно.

То есть ты хочешь сказать, что ТС решил грохать чужие шеллы?

То есть ты хочешь сказать, что ТС решил грохать чужие шеллы?

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

Ну или увести в сон/гибернацию, а рамы мало.

Юзкейсов не так много, но они есть, пусть и не для каждого они имеют смысл.

Появилась идея, как сделать что-то похожее на мой запрос. Правда, теперь непонятно, почему не срабатывает trap _trap_exit EXIT в конфиге zsh, когда запущен tmux. Когда его сессия не открыта, trap работает.

Это естественно.

Но это никак не решает сложность с определением работающих приложений в сессии tmux.

В качестве стартовой точки для размышлений посмотри сюда.

Гиблое дело: tmux себя форкает, так что никаких зацепок по pid-ам нет. Связь ЭТ с окном tmux-а отследить нереально.

Но решение найдено: не пользоваться tmux-ом! Либо запускать по необходимости.

Потыкал — с тайлами в нём особенного смысла нет. А вот для VPS-ки решение годное: доставало, когда соединение обрывалось на apt upgrade: теперь, видимо, с этим проблемы не будет.

Гиблое дело: tmux себя форкает, так что никаких зацепок по pid-ам нет. Связь ЭТ с окном tmux-а отследить нереально.

Сервер не нужно отслеживать, нужно отслеживать клиент (а это разные процессы с разными PID), который привязывается к pts (виртуальное устройство-терминал), который открывается эмулятором терминала и привязывается к нему.

НО! Нужно отслеживать до закрытия терминала, так как при закрытии процесс клиента tmux будет завершён с детачем сессий.

Либо запускать по необходимости.

Я пришёл к тому же выводу.

А вот для VPS-ки решение годное: доставало, когда соединение обрывалось на apt upgrade: теперь, видимо, с этим проблемы не будет.

У меня на удалённых машинах при входе через ssh в шелле открывается tmux, чтобы в случае обрыва ничего не отвалилось.

нужно отслеживать клиент (а это разные процессы с разными PID)

При запуске tmux родителем процесса сервера становится systemd (или что там у тебя). После закрытия терминала, если я правильно понял термин «клиент», последний имеет родителей вида: zsh -> tmux -> systemd. С этого момента сессии и ЭТ никак не связаны pid-ами. Понять какой pid клиента сейчас открыт в ЭТ нереально.

Команды вида tmux list-panes -F '#{client_pid}' у меня выводят пустую строку. Я надеялся, что это то, что мне нужно.

Вообще пока не понял, что именно является клиентом. Шелл? Не st же.

так как при закрытии процесс клиента tmux будет завершён с детачем сессий.

У меня хук на детач не срабатывает при закрыти ЭТ. Хук работает только при явной команде на детач. Значит он не происходит при закрытии ЭТ, и tmux вообще не знает, открыт ЭТ сейчас или нет. tmux, как я понял, имеет отношения только с шелом.

При запуске tmux родителем процесса сервера становится systemd (или что там у тебя).

Не имеет значения кто является родителем процесса.

последний имеет родителей вида: zsh -> tmux -> systemd

Нет, в твоём случае это будет zsh → tmux client, без всего остального, с tmux server общение идёт через сокет.

То есть нужно до закрытия клиента посмотреть к какой сессии сервера он приаттачен, посмотреть процессы работающие в tmux (по привязке к pts) в этой сессии, если таких нет — послать сигнал серверу на завершение сессии. Если сессий не осталось, сервер сам завершится (FIXME: или нет?).

сессии и ЭТ никак не связаны

Правильно, но не поэтому. Дочерние процессы управляются сервером tmux, клиент выступает в качестве просмотрщика.

Тебе нужно получить цепочку server → session → pts → process.

Понять какой pid клиента сейчас открыт в ЭТ нереально.

PID вообще не нужен.

У меня хук на детач не срабатывает при закрыти ЭТ. Хук работает только при явной команде на детач. Значит он не происходит при закрытии ЭТ, и tmux вообще не знает, открыт ЭТ сейчас или нет. tmux, как я понял, имеет отношения только с шелом.

Потому что при работе с удалённой машиной нужно запускать tmux на удалённой машине. ☺

Короче, с тайлами в нём смысла особого нет – всё равно открывается куча эмуляторов, а для удалённой машины эта фича не нужна – там один терминал открыт.

Редкий вопрос потому, видимо, и редкий, что в реальных условиях в нём нет необходимости.

с тайлами в нём смысла особого нет – всё равно открывается куча эмуляторов, а для удалённой машины эта фича не нужна – там один терминал

Судя по описанию, ты запускаешь tmux на локальной машине и уже в нём по ssh подключаешься? Если да, то от факапа при обрыве связи тебя это не спасёт.

Нет, tmux на удалённой. Разные клавиши горячие настроил, чтоб не пересекались – иначе локальный перехватывает. Обрывы связи хорошо обрабатывает, уже проверял. Не знаю, почему я так долго откладывал знакомство с мультиплексером? Штука огонь!