Настраивай автозапуск сеанса через ~/.bash_profile или ~/.zshrc. Пример:
if [ -z "$TMUX" ]; then
exec tmux attach-session -t default || tmux new-session -s default
fi
Такой фрагмент автоматически подхватывает существующий сеанс. Если он не существует – создаёт новый. Никаких alias. Только прямой вызов. Проверено на Red OS 7.3 и 8.2.
С переносом сеанса другого пользователя всё интереснее. Допустим, пользователь dev запустил screen, а ты – root. Проверяешь PID:
ps aux | grep SCREEN
Затем экспортируешь переменные окружения, перехватываешь сокет и подключаешься. Но только если у тебя CAP_SYS_PTRACE и права на файловую систему. Без этого – никак.
Важно: Red OS по умолчанию монтирует
/dev/ptsс ограничениями. Проверь/etc/fstabиmount, иначе ничего не заработает.
Командная сборка в многооконном режиме? Разбей на 3–4 панели. В первой – cmake. Во второй – make -j$(nproc). В третьей – tail -f на лог. В четвёртой – интерактивная оболочка или shell-интерпретатор проекта. Это не модно – это удобно. Особенно если собираешь в оффлайне или под замороженные зависимости.
Ctrl-A :hardcopy -h /var/log/screen_output.log
Помните: если соединение оборвалось, но ты сохранил лог – ты победил. А если нет – считай, ничего не было.
Содержание статьи
Настройка автозапуска tmux-сессии при входе в систему
Пропиши автозапуск прямо в ~/.bash_profile, если используешь Bash. Для Zsh – ~/.zshrc. Команда должна быть строгой, без условий – иначе однажды не сработает.
if [ -z "$TMUX" ]; then
exec tmux attach-session -t default || tmux new-session -s default
fi
Такой блок гарантирует: если сессия есть – подключишься. Если нет – создастся. Название фиксированное: default. Хочешь другое – меняй, но учитывай конфликты. Не называй как hostname – запутаешься.
Red OS иногда грузит не ~/.bash_profile, а ~/.profile. Особенно в окружениях с lightdm или gdm. Проверяй запуск оболочки через getent passwd $USER и убедись, что вход – интерактивный. Без этого автозапуск не произойдёт.
Важно помнить: systemd может игнорировать пользовательские конфигурации, если активен PAM с ограничениями. Смотри
/etc/pam.d/loginи убедись, что там нет запрета на переменные окружения.
Для запуска при старте терминала внутри графики – совсем другой подход. Используй ~/.xprofile или автозагрузку среды. Пример для GNOME:
cat > ~/.config/autostart/session.desktop <<EOF
[Desktop Entry]
Type=Application
Exec=gnome-terminal -- tmux attach-session -t default || tmux new-session -s default
Hidden=false
X-GNOME-Autostart-enabled=true
Name=AutoSession
EOF
Схема нестабильна. Графическая оболочка может запускать несколько терминалов, что приведёт к гонке процессов. Лучше – через systemd user unit.
mkdir -p ~/.config/systemd/user
Создай юнит:
cat > ~/.config/systemd/user/tmux-session.service <<EOF
[Unit]
Description=Autostart tmux session
[Service]
ExecStart=/bin/tmux new-session -A -s default
RemainAfterExit=true
[Install]
WantedBy=default.target
EOF
Активируй юнит:
systemctl --user daemon-reexec
systemctl --user enable --now tmux-session.service
Теперь при каждой инициализации пользовательского сеанса запускается нужная оболочка. Без лишних файлов. Без хаоса.
Внимание! Если systemd не работает в пользовательском режиме – запусти
loginctl enable-linger $USER. Без этого unit не стартует после выхода из сессии.
Проверяй. Не верь логам – смотри journalctl --user -u tmux-session. Там всё. Или ничего.
Перенос активной screen-сессии между пользователями
Нужен доступ к чужому сеансу? Без root-прав не обойтись. Простая смена пользователя через su не сработает. Понадобится ручная настройка прав и захват сокета. Действовать надо точно. Без промедлений.
Алгоритм следующий:
- Узнай имя сеанса и его PID:
ps aux | grep SCREEN
ls -la /run/screens/S-* # или /var/run/screens/S-*
- Зайди под root. Назначь временные права на каталог сокета:
chown -R другой_пользователь: /run/screens/S-другой_пользователь
chmod -R 770 /run/screens/S-другой_пользователь
- Добавь нужного пользователя во временную группу или выдай ACL:
setfacl -m u:новый_пользователь:rwx /run/screens/S-другой_пользователь
- Теперь переключись:
su - новый_пользователь
screen -r имя_сеанса
Если система использует SELinux (актуально для Red OS), проверь контекст. Иногда он мешает. Смени на permissive или пропиши исключение через semanage fcontext.
Важно: если сокет лежит в нестандартном месте (например, после chroot), ручной доступ невозможен. Придётся использовать bind-mount и прокидывание псевдотерминалов через
devpts.
Иногда проще не переносить, а дублировать. Включи логирование в первом сеансе:
Ctrl-A :logfile /tmp/session.log
Ctrl-A :log on
А затем читай в real-time через tail -f с правами второго пользователя. Но это уже подглядывание, а не полноценный захват. Разница принципиальная.
Помните: изменение владельца сокета может повредить сеанс. Работай быстро и точно. Если потеряешь дескриптор – не восстановишь.
Если нужно делать это регулярно – напиши wrapper-скрипт с sudo и ACL-обёрткой. Не доверяй руками. Автоматизируй.
Организация многопанельной компиляции кода в tmux
Создай отдельное окно для сборки. Назови его прямо: build. Всё должно быть прозрачно. Не пиши лишнего.
tmux new-session -s dev -n build
Разбей его на панели. Вертикально, потом горизонтально. Быстро:
tmux split-window -h
tmux split-window -v
tmux select-pane -L
tmux split-window -v
Назначь в каждой панели команду:
- Левая верхняя:
cmake ../src -DCMAKE_BUILD_TYPE=Release - Правая верхняя:
make -j$(nproc) - Левая нижняя:
tail -f build.log - Правая нижняя: интерактивный
gdbилиlldb
make -j$(nproc) 2>&1 | tee build.log
Не пиши в лог руками. Не чекай stderr отдельно. Tee делает всё. Пиши скрипт, а не команды в ручную. Пример:
#!/bin/bash
cd /home/dev/project/build
cmake ../src -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake
make -j$(nproc) 2>&1 | tee build.log
Сохрани его как build.sh. Назначь на горячую клавишу в панели. Простой вызов – минимум кликов.
Не хочешь каждый раз настраивать? Используй автозагрузку конфигурации через ~/.tmux.conf или пиши отдельный layout-скрипт на Shell или expect. Пример автоматизации сессии:
tmux new-session -d -s dev -n build
tmux send-keys -t dev 'cd /home/dev/project/build' C-m
tmux send-keys -t dev 'cmake ../src' C-m
tmux split-window -h -t dev
tmux send-keys -t dev:0.1 'make -j$(nproc) 2>&1 | tee build.log' C-m
tmux split-window -v -t dev:0.0
tmux send-keys -t dev:0.2 'tail -f build.log' C-m
tmux split-window -v -t dev:0.1
tmux send-keys -t dev:0.3 'gdb ./binary' C-m
tmux attach-session -t dev
Важно помнить: без предварительного создания директории и CMake-файлов сборка не стартует. Проверь структуру проекта заранее.
И не забывай про alias. Убери их. Они ломают скрипты. Всё должно быть чисто. Прямой вызов бинарников. Без лишней магии.
Помните: каждая панель – как ядро в процессоре. Дай ей чёткую задачу. Тогда сборка не развалится, даже если ты оторвёшься от терминала.
Включи логирование сразу. Не надейся на scrollback. Он исчезает без следа при разрыве SSH или сбое питания. Только файл. Только жёсткое сохранение.
Ctrl-A :logfile /var/log/screen/session.log
Ctrl-A :log on
Путь укажи явный. Без относительных. Каталог должен существовать и быть доступен на запись. Проверь владельца и SELinux-контекст:
chown user: /var/log/screen
semanage fcontext -a -t user_tmp_t "/var/log/screen(/.*)?"
restorecon -Rv /var/log/screen
Если нужно включать лог автоматически при запуске – пропиши в ~/.screenrc:
logfile /var/log/screen/session.log
log on
Но если открываешь несколько окон в одном сеансе – каждому нужен свой лог. Добавляй имя окна в путь:
logfile /var/log/screen/session-%t.log
%t – имя текущего окна. Так удобнее отлаживать. Один лог – один процесс. Без путаницы.
Важно помнить: при перегрузке системы логи могут не сохраниться, если файловая система в режиме read-only. Используй внешние точки монтирования или отдельный лог-сервер.
Проверяй включение записи по индикатору в статусной строке. Если видишь [Log] – пишется. Если нет – команду не приняли. Запусти ещё раз.
Автоматизация? Добавь запуск через wrapper-скрипт:
#!/bin/bash
LOG="/var/log/screen/$(date +%F-%H%M%S).log"
screen -L -Logfile "$LOG" -S build-session
Разорвалось соединение? Лог останется. Отматываешь less или grep – всё видно. Ошибки, варнинги, даже тайминги компиляции.
Помните: если ты не сохранил лог – ты проиграл. Всё остальное неважно.
Для хранения истории команд изнутри сеанса – активируй HISTORY. Стандартный bash может забыть незавершённые строки. Используй shopt -s histappend и PROMPT_COMMAND:
export PROMPT_COMMAND='history -a'
shopt -s histappend
Пусть каждый ввод записывается сразу. Не доверяй буферу. Пиши в камень. Или в лог. Всё остальное – иллюзия стабильности.

