Intereting Posts

Просмотр stdout / stderr службы systemd

Я создал простой служебный файл systemd для пользовательского приложения. Приложение работает хорошо, когда я запускаю его вручную, но мой CPU становится максимальным, когда я запускаю его с помощью systemd.

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

Вот мой служебный файл:

[Unit] Description=Syncs files with a server when they change Wants=network.target After=network.target [Service] ExecStart=/usr/local/bin/filesync-client --port 2500 WorkingDirectory=/usr/local/lib/node_modules/filesync-client Restart=always [Install] WantedBy=multi-user.target 

Во всем приложении я выводю на stdout и stderr.

Как я могу прочитать вывод моего демона?

Редактировать:

Я нашел man systemd.exec , который упомянул параметр StandardOutput= , но я не уверен, как его использовать. На странице руководства:

StandardOutput =

Элементы управления, к которым подключен файловый дескриптор 1 (STDOUT) выполняемых процессов. Принимает одну из наследований: null, tty, syslog, kmsg, kmsg + console, syslog + console или socket .

Если установлено для наследования, дескриптор файла стандартного ввода дублируется для стандартного вывода. Если установлено значение null, стандартный вывод будет подключен к / dev / null, то есть все записанные в него будут потеряны. Если установлено значение tty, стандартный вывод будет подключен к tty (как указано через TTYPath =, см. Ниже). Если TTY используется для вывода, только выполненный процесс не станет процессом управления терминалом и не будет терпеть неудачу или ждать, пока другие процессы освободят терминал. syslog подключает стандартный вывод к системному регистратору syslog (3). kmsg связывает его с буфером журнала ядра, который доступен через dmesg (1). syslog + console и консоль kmsg + аналогичны, но копируют вывод на системную консоль. socket подключает стандартный вывод к сокете из активации сокета, семантика аналогична соответствующей опции StandardInput =. По умолчанию этот параметр наследуется.

Означает ли это, что это мои единственные варианты? Я хотел бы, например, поставить вывод в /dev/shm или что-то еще. Я полагаю, что я мог бы использовать сокет домена unix и написать простой прослушиватель, но это кажется немного ненужным.

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

Обновить

Как отмечает mikemaccana, журнал systemd теперь является стандартным устройством регистрации для большинства дистрибутивов. Для просмотра stdout и stderr в journalctl блоке используйте команду journalctl .

 sudo journalctl -u [unit] 

Оригинальный ответ

По умолчанию stdout и stderr блока systemd отправляются в syslog.

Если вы используете полный systemd, это будет доступно через journalctl . В Fedora это должно быть /var/log/messages но syslog поместит его там, где ваши правила скажут.

Из-за даты публикации и предполагая, что большинство людей, которые подвергаются воздействию systemd, через Fedora, вы, вероятно, пострадали от описанной здесь ошибки: https://bugzilla.redhat.com/show_bug.cgi?id=754938 хорошее объяснение того, как все это работает тоже =) (Это была ошибка в политике selinux, из-за которой сообщения об ошибках не регистрировались и были исправлены в selinux-policy-3.10.0-58.fc16 )

Более короткий, более простой, не устаревший ответ:

 sudo journalctl -u [unitfile] 

Где [unitfile] – имя systemd .service . Например, чтобы видеть сообщения из myapp.service ,

 sudo journalctl --unit=myapp 

Чтобы следить за журналами в режиме реального времени:

 sudo journalctl -f -u myapp