Как отобразить работу скрипта Python запущенного через systemctl?

Question

[Денис]

Есть скрипт бота на Python, работал на Windows в Pycharm, я следил в консоле за сообщениями, которые скрипт иногда выдавал (простенькая аналитика, типа сколько раз нажали на кнопку).
Затем, после отладки, скрипт перенёс на Линукс сервер (Debian11).
Запускаю: python3 bot.py
Всё работает, в консоле вижу ответы скрипта, всё замечательно.
Затем, как и положено, запустил скрипт через systemctl как сервис. Так же всё работает отлично, но я не могу понять как мне увидеть то, что я раньше видел в консоле - ответы скрипта (эхо, принты)
Попробовал через: journalctl -f -u bot
Выводит только что запущен сервис и всё.
Попробовал через: strace -p PID -s 513615 -e write
выводит внутрисистемный обмен работы скрипта.

Подскажите, как мне при входе по SSH набрать команду и увидеть вывод работы скрипта, а именно то, что заложено в логику скрипта - Эхо, принты и всё то, что я раньше видел в консоле Pycharm

Comments

[Valentin Barbolin]

https://github.com/systemd/journal2gelf
https://gist.github.com/derlinkshaender/5995776

Answer 1

[Vindicar]

ОП, ты хочешь странного. Осознай, что демоны (а systemd управляет как раз программами типа daemon) по определению не предназначены для взаимодействия непосредственно с пользователем, в частности через терминал. А значит, у тебя два выхода:

1. Перестать хотеть странного, и реализовать нормальные логи и анализировать их. Тогда можно будет в любой момент посмотреть историю, выведенную в лог.
При необходимости отслеживать файл лога в реальном времени можно использовать команду tail -f файл.log. Почитай про неё.
Также можно натравить на лог какую-нибудь утилиту мониторинга, которая будет его читать и посылать тебе оповещения о событиях по другому каналу.
Если лог большой, есть logrotate.
Минус - специфические терминальные фишки в логе работать не будут. Скажем, прогрессбар там не сделаешь, и ввести текст не получится.

2. Отказаться от запуска программы как классического демона, и запускать её через утилиту screen. Тогда ты сможешь сконнектиться к сессии screen когда угодно.
Плюс - взаимодействие с терминалом как обычно. В том числе из разных ssh сессий.
Минус - screen не самая удобная штука, сочетания клавиш там мозголомные. Плюс всё равно запуск screen придётся заворачивать в systemd если тебе нужен автозапуск и автоперезапуск.

Comments

[Денис]

демоны (а systemd управляет как раз программами типа daemon) по определению не предназначены для взаимодействия непосредственно с пользователем, в частности через терминал.

Я об этом догадывался, теперь вопрос снят. Спасибо за ответ!

[ValdikSS]

Vindicar, боюсь, написанное вами целиком не соответствует реальному положению вещей. Systemd+journald по умолчанию логируют весь вывод stdout/stderr, а также самостоятельно демонизируют процессы. Автору не нужно добавлять какую-либо другую систему логирования в файл в свой скрипт, как и демонизировать его (в вопросе не указано, что скрипт демонизируется).

[Vindicar]

ValdikSS, ну демонизируется скрипт как раз самим systemd. Во всяком случае, я так интерпретировал эту фразу автора:

запустил скрипт через systemctl как сервис

Демонизировать вручную я и не предлагаю.

Также я не вполне помню, как из journalctl выцарапать stdout/stderr скрипта. Логфайл в этом отношении куда проще и универсальнее, хоть и велосипед. Опять же, работает независимо от способа запуска.

[ValdikSS]

Vindicar, Любая foreground-программа, запущенная через systemd service со стандартными параметрами, перенаправляет свои stdout/stderr в syslog, в стандартном случае это journald. Ничего дополнительно делать не нужно.

Проблема у автора в том, что python по умолчанию буферизирует stdout/stderr, из-за чего journald получает данные с задержкой, после накопления достаточного количества буфера и его очистки.
У автора не интерактивное приложение, взаимодействовать по stdin или tty с ним не нужно, поэтому ваш ответ мне не понятен. Если вы не используете journald/systemd, то не следует писать вредные, в этом случае, советы.

Answer 2

[Алан Гибизов]

Как вариант можно в начале скрипта переобъявить стандартный вывод как вывод в файл, и до окончания работы скрипта все print-в будут выводиться в указанный файл.

Comments

[Денис]

Скрипт работает 24/7 он не остановится очень долго, мне не нужно ничего выводить в файл. Я бы для этого БД просто бы добавил.

[Алан Гибизов]

Денис, в БД, кмк, без переделки скрипта выводить просто так не получится. Наверно, можно сколхозить перенаправление вывода в какой-нибудь fifo и затем тупо запись каждой строки в отдельную запись БД…
Но это какое-то дикое велосипедостроение.
Может, лучше правильно поставить задачу? А то похоже на XY-проблему.

[Денис]

Алан Гибизов, задача проста.
Мне нужно видеть, что выводит в консоль исполняемый скрипт, который работает как сервис.
Точно так же, как запущенный в терминале python3 bot.py
Нажали кнопку, я тут же в консоле вижу - "нажали кнопку"

[Алан Гибизов]

Денис, ну то-есть вы сидите дома, подключившись к серверу по ssh 24/7, и смотрите в экран, когда же там ченьть отобразится? Реализовать это - и есть конечная цель всего мероприятия?

[Денис]

Алан Гибизов, да )
Мне просто важно знать можно сделать как я описал, либо всё это возможно только через логирование, а далее разбор логов, выборка мне нужного и т.д. и т.п.

Просто интересно, могу я видеть консоль работы скрипта как я это привык видеть в Pycharm, юпитер и т.п. или нет.
Как это, например, в JS я смотрю консоль в отладчике браузера онлайн.

[Денис]

GNUBack, немного стал понимать, что мне нужно.
Нужно Интерактивный ввод/вывод, т.е. смотреть в сторону stdout и разбираться с этим.

Answer 3

[Валентин]

Всё работает, в консоле вижу ответы скрипта, всё замечательно.

ну так соответственно это при запуске через systemd попадает в лог сервиса, который просматривается через journalctl -u имясервиса А если там этого вывода нет - то уже вопрос, куда именно вы выводите сообщения? STDOUT или STDERR?

Comments

[Денис]

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

Answer 4

[ValdikSS]

Скорее всего, если ваш скрипт пишет в stdout/stderr, а вы это не видите в журнале, проблема с буферизацией вывода.
Запускайте скрипт как python3 -u bot.py. Параметр -u отключает буферизацию.

-u Force the stdout and stderr streams to be unbuffered. This option has no effect on the stdin stream.

Comments

[Денис]

Если быть внимательным, то я писал, что запуск как обыкновенного скрипта через python3 bot.py всё прекрасно выводится. У меня скрипт запущен как служба.

[ValdikSS]

Денис, Нужно использовать команду python3 -u bot.py в systemd-сервисе, а не python3 bot.py.

[Денис]

ValdikSS, пробовал, но я вижу совсем не то, что ожидал. Там просто вообще ВСЁ.