1

Я хочу использовать один сценарий для запуска 2 сеансов, сеанса демона и сеанса пользователя. Я хочу, чтобы скрипт запускался при загрузке без входа пользователей.

Сценарий, который я создал, работает при запуске напрямую, но только частично при запуске с systemctl, запускает daemon.service от имени пользователя root (также при загрузке).

По сути, скрипт делает это:

# Clean up any old tmux sessions
tmux kill-session -t daemon > /dev/null 2>&1 
tmux kill-session -t user > /dev/null 2>&1 
rm -rf /tmp/tmux-`id -u`

tmux new-session -d -s daemon
tmux send-keys "$DAEMON" C-m

# Start the main tmux session from which we'll create 
#  all window panes 
export TMUX=
export TERM=xterm
tmux new-session -d -s user
tmux list-sessions >> $LOG

# Various window setup using "tmux split-window -h" 
#  or "tmux split-window -v" - no other args

# Window panes created. Now wait for daemon process to open socket, then
echo "Daemon is now listening." >> $LOG

tmux send-keys -t 1 "$CMD1" C-m
echo "Sent $CMD1 to pane 1" >> $LOG
tmux send-keys -t 1 "$CMD2" C-m
echo "Sent $CMD2 to pane 2" >> $LOG
...

# Spin in a loop until the daemon process stops listening, then exit

Это оно. Просто. Нет вложенных сессий, тем не менее предупреждает tmux. Зачем? В другом месте я читал, что установка TERM и сброс TMV env vars необходимы для процесса systemd, поскольку tmux для tmux не используется. Похоже, это помогло, хотя я прошел через так много испытаний, не мог дать вам никаких подробностей.

Симптомом является начало обоих сеансов, демон выглядит нормально, но панели пользовательских сеансов пусты, но все панели созданы правильно. Клавиши отправки, похоже, не отправляются им, хотя журнал выглядит отлично, нигде ничего не висит.

Мне это нужно для работы на разных версиях tmux от 1.9 до 2.1 (Ubuntu 16.04 и Debian 8.7 и 8.8). Пользовательская часть запускает "менее" пейджер для просмотра журнала демона и 2 процесса, которые могут взаимодействовать с пользователем. Я поместил «tmux attach-session -t user» в свой .profile, чтобы при входе в систему я видел все окна и мог взаимодействовать с ними. Важно, чтобы пользовательские процессы также запускались с демоном, даже если ни один пользователь не присутствует.

Я не понимаю, почему tmux, кажется, думает, что сессии являются вложенными, просто b/c 2 запускаются из того же сценария. Когда скрипт завершает работу, что-то не так, и systemd затем снова вызывает скрипт, чтобы перезапустить все. Для тестирования у меня есть # Restart = on-fail закомментировано.

Я вижу, что клавиши send выполняются, глядя на ps, они все работают. Я думаю, что переменные TMUX & TERM являются ключом к проблеме, но я не уверен, как ее решить, так что A) tmux разделяет сессии и B) нет проблем при запуске без пользователей или с открытым терминалом ttys.

1 ответ1

0

Это была довольно кроличья нора и потребовалось много копать, чтобы выяснить. IMO разработчикам systemd / OS нужно решить несколько вопросов. Я не уверен насчет Ubuntu, но Debian 8.8 определенно требует некоторого внимания.

С информацией, которую я предоставлю здесь, не должно быть трудно получить рабочую настройку. Заметьте, однако, что у меня нет конкретного ответа на вопрос, почему tmux запутывается и считает вышеприведенный "вложенный" сеанс.

Эта проблема возникла при попытке автоматизировать запуск процесса демона и сценария tmux во время загрузки. Я попытался использовать один скрипт, чтобы сделать все это, и затем возникла проблема tmux "множественный сеанс".

Моим конечным решением было разделить запуск окон daemon и tmux на 2 отдельных процесса, оба автоматизированных с помощью systemd. Я решил использовать системный модуль systemd для запуска демона и модуль сеанса для запуска сценария tmux. Хотя я не пробовал помещать скрипты daemon и tmux в системные сессионные модули пользователя, я считаю, что это можно сделать без проблем. Есть преимущества в разделении, я не буду здесь вдаваться.

Чтобы выяснить, как использовать системные сессионные пользовательские блоки на не-X-windows, tty only server потребовал большую часть усилий, чтобы выяснить это. Вот основные шаги:

1) В качестве пользователя root запустите apt-get install libpam-systemd . В некоторых системах Debian 8.8, которые я использовал, это было необходимо даже после apt-get update . Это устанавливает область сеанса DBus и системный диспетчер пользовательских процессов при входе пользователей, включая важные переменные среды. К сожалению, не ВСЕ важные переменные настроены, и это то, что нужно исправить ОС Debian.

2) Если вы хотите, чтобы ваш пользовательский сеанс запускался во время загрузки, чтобы пользователю не нужно было входить в систему, и чтобы он сохранялся при перезагрузке, от имени пользователя root выполните loginctl enable-linger <user account name> . Это позволяет процессу systemd пользователя @ .service оставаться даже после закрытия всех сеансов входа в систему и автоматически запускаться при загрузке системы.

3) К сожалению, важные переменные среды не установлены правильно в Debian 8.8 и должны быть исправлены, однако это не сложно сделать. В пользовательском сценарии .profile или .bashrc добавьте: export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/systemd" Вы должны иметь возможность проверить /run/user/$UID/ для конечной папки, содержащей гнезда для сеанс пользователя DBus Communication. На Debian 8.8 это "systemd".

Обратите внимание, что вам может потребоваться перезагрузка для всех модулей systemd для правильной последовательной инициализации. Если вы выполняете export без аргументов, вы должны увидеть XDG_RUNTIME_DIR = "/run/user/id -u " и XDG_SESSION_ID установить в какое-то значение. Если нет, проблема с сеансом пользователя systemd все еще существует. Если вы входите через ssh, убедитесь, что в вашем /etc /ssh /sshd_config для UsePAM установлено значение yes, чтобы был выполнен код libpam-systemd.

Я подозреваю, что модули systemd, связанные с libpam-systemd, должны быть обновлены, поэтому они устанавливают все отсутствующие в настоящее время переменные env. Возможно сделать исправление в /etc/systemd/user.conf, раскомментировав DefaultEnvironment= и установив для него значение DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/systemd" , но я не уверен, что это сработает.

Вот несколько ссылок, которые могут вам пригодиться: 1: 7.10.Использование и настройка Systemd 2: анализ D-Bus из командной строки 3. Управление сессией с помощью systemd

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .