Перегляд stdout / stderr системної служби

Я створив простий файл системного обслуговування для спеціальної програми. Додаток працює добре, коли я запускаю його вручну, але мій процесор отримує maxed, коли я запускаю його з 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) виконуваних процесів. Приймає один з успадковувати , нуль , телетайп , системний журнал , kmsg , kmsg + консолі , системний журнал + консолі або розеткою .

Якщо встановлено для успадкування дескриптор файлу стандартного вводу, дублюється для стандартного виводу. Якщо встановлений на нуль стандартний вихід, буде підключено до нього /dev/null, тобто все написане на нього буде втрачено. Якщо встановлено значення tty, стандартний вихід буде підключений до tty (як налаштовано через TTYPath=, див. Нижче). Якщо TTY використовується для виведення, тільки виконаний процес не стане контрольним процесом терміналу, і не вийде з ладу або чекати, поки інші процеси звільнять термінал. syslog підключає стандартний вихід до системного реєстратора syslog (3). kmsg з'єднує його з буфером журналу ядра, який доступний через dmesg (1). syslog + консоль і kmsg + консольпрацюйте аналогічно, але також скопіюйте вихід на системну консоль. socket підключає стандартний вихід до сокета від активації сокета, семантика аналогічна відповідній опції StandardInput=. Цей параметр за замовчуванням успадковується.

Чи означає це, що це єдині мої варіанти? Я хотів би, наприклад, поставити результат /dev/shmчи щось таке. Я припускаю, що я міг би використовувати сокет домену Unix і писати простий слухач, але це здається трохи зайвим.

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

Оновлення

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

sudo journalctl -u [unit]

Оригінальний відповідь

За замовчуванням stdoutі stderrсистемний блок відправляються в syslog.

Якщо ви використовуєте повний systemd, це стане доступним через journalctl. У Fedora це повинно бути, /var/log/messagesале syslog поставить його там, де говорять ваші правила.

У зв'язку з датою поста, і припускаючи , що більшість людей, які піддаються впливу Systemd які з допомогою фетровому капелюхом, ви, ймовірно , постраждали від помилки , описаної тут: https://bugzilla.redhat.com/show_bug.cgi?id=754938 має гарне пояснення того, як все це теж працює =) (Це помилка в selinux-політиці, яка спричинила не реєстрацію повідомлень про помилки та її виправлення selinux-policy-3.10.0-58.fc16)

Коротша, простіша, не застаріла відповідь:

sudo journalctl -u [unitfile]

Де [unitfile] - .serviceім'я системи. Наприклад, щоб побачити повідомлення myapp.service,

sudo journalctl --unit=myapp

Щоб стежити за журналами в режимі реального часу:

sudo journalctl -f -u myapp