Просмотр 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.

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

Edit:

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

  

StandardOutput =

     

Элементы управления, в которых подключен файловый дескриптор 1 (STDOUT) запущенных процессов. Принимает одну из команд inherit, null, tty, syslog, kmsg, kmsg +, 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.

132 голоса | спросил tjameson 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 09 Sep 2011 22:24:34 +0400 2011, 22:24:34

2 ответа


145

Update

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

sudo journalctl -u [unit]

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

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

Если вы используете полный 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

ответил Matt 30 52012vEurope/Moscow11bEurope/MoscowFri, 30 Nov 2012 19:20:03 +0400 2012, 19:20:03
60

Более короткий, простой, нелогичный ответ:

sudo journalctl -u [unitfile]

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

sudo journalctl --unit=myapp

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

sudo journalctl -f -u myapp
ответил mikemaccana 17 FebruaryEurope/MoscowbMon, 17 Feb 2014 15:53:55 +0400000000pmMon, 17 Feb 2014 15:53:55 +040014 2014, 15:53:55

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132