Afficher le stdout / stderr du service systemd

J'ai créé un fichier de service systemd simple pour une application personnalisée. L'application fonctionne bien lorsque je l'exécute manuellement, mais mon processeur est saturé lorsque je l'exécute avec systemd.

J'essaie de localiser mon problème, mais je ne sais pas où trouver la sortie (ni comment configurer systemd pour placer la sortie quelque part).

Voici mon fichier de service:

[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

Tout au long de l'application, j'ai sorti sur stdout et stderr.

Comment puis-je lire la sortie de mon démon?

Modifier:

J'ai trouvé man systemd.exec, qui a mentionné l' StandardOutput=option, mais je ne sais pas comment l'utiliser. De la page de manuel :

StandardOutput=

Contrôles auxquels le descripteur de fichier 1 (STDOUT) des processus exécutés est connecté. Prend un des éléments suivants: inherit , null , tty , syslog , kmsg , kmsg + console , syslog + console ou socket .

Si défini pour hériter, le descripteur de fichier d'entrée standard est dupliqué pour la sortie standard. Si défini sur null , la sortie standard sera connectée /dev/null, c'est- à -dire que tout ce qui y est écrit sera perdu. Si réglé sur tty , la sortie standard sera connectée à un tty (comme configuré via TTYPath=, voir ci-dessous). Si le TTY est utilisé pour la sortie, seul le processus exécuté ne deviendra pas le processus de contrôle du terminal et n'échouera pas ou n'attendra pas que d'autres processus libèrent le terminal. Syslog connecte la sortie standard à l'enregistreur système syslog (3). kmsg le connecte à la mémoire tampon du journal du noyau accessible via dmesg (1). syslog + console et kmsg + consolefonctionnent de la même manière, mais copiez également la sortie sur la console système. socket connecte la sortie standard à un socket après l’activation du socket, la sémantique est similaire à l’option correspondante de StandardInput=. Ce paramètre hérite par défaut.

Est-ce que cela signifie que ce sont mes seules options? Je voudrais, par exemple, mettre en sortie /dev/shmou quelque chose. Je suppose que je pourrais utiliser un socket de domaine Unix et écrire un auditeur simple, mais cela semble un peu inutile.

J'ai juste besoin de cela pour le débogage, et je vais probablement finir par supprimer la plupart des journaux et changer la sortie en syslog.

Mise à jour

Comme le note mikemaccana, le journal systemd est désormais le périphérique de journalisation standard pour la plupart des distributions. Pour afficher le stdoutet stderrd'une unité systemd, utilisez la journalctlcommande.

sudo journalctl -u [unit]

Réponse originale

Par défaut stdoutet stderrd'une unité systemd sont envoyés à syslog.

Si vous utilisez le système complet, cela sera accessible via journalctl. Sur Fedora, cela devrait être le cas, /var/log/messagesmais syslog le mettra à la place de vos règles.

En raison de la date de la poste, et en supposant que la plupart des gens qui sont exposés à systemd sont par fedora, vous avez probablement été frappé par le bogue décrit ici: https://bugzilla.redhat.com/show_bug.cgi?id=754938 Il a une bonne explication de la façon dont tout cela fonctionne aussi =) (C'était un bogue dans selinux-policy qui empêchait la journalisation des messages d'erreur et qui était corrigé selinux-policy-3.10.0-58.fc16)

Réponse plus courte, plus simple et non héritée:

sudo journalctl -u [unitfile]

Où [unitfile] est le .servicenom du système . Par exemple, pour voir les messages de myapp.service,

sudo journalctl --unit=myapp

Pour suivre les journaux en temps réel:

sudo journalctl -f -u myapp