Ver stdout / stderr del servicio systemd

He creado un archivo de servicio systemd simple para una aplicación personalizada. La aplicación funciona bien cuando la ejecuto manualmente, pero mi CPU se maximiza cuando la ejecuto con systemd.

Estoy tratando de rastrear dónde está mi problema, pero no sé dónde encontrar la salida (o cómo configurar systemd para colocar la salida en algún lugar).

Aquí está mi archivo de servicio:

[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

A lo largo de la aplicación, salgo a stdout y stderr.

¿Cómo puedo leer la salida de mi demonio?

Editar:

Encontré man systemd.exec, que mencionaba la StandardOutput=opción, pero no estoy seguro de cómo usarla. Desde la página del manual :

StandardOutput=

Controla dónde está conectado el descriptor de archivo 1 (STDOUT) de los procesos ejecutados. Toma uno de herencia , nulo , tty , syslog , kmsg , kmsg + consola , syslog + consola o socket .

Si se establece para heredar, el descriptor de archivo de entrada estándar se duplica para la salida estándar. Si se establece en nulo , se conectará la salida estándar /dev/null, es decir, todo lo escrito en él se perderá. Si se establece en tty , la salida estándar se conectará a un tty (como se configuró a través de TTYPath=, ver a continuación). Si el TTY se usa para la salida, solo el proceso ejecutado no se convertirá en el proceso de control del terminal y no fallará ni esperará a que otros procesos liberen el terminal. syslog conecta la salida estándar al registrador del sistema syslog (3). kmsg lo conecta con el búfer de registro del kernel al que se puede acceder a través de dmesg (1). syslog + console y kmsg + consolefunciona de manera similar, pero copia la salida a la consola del sistema también. socket conecta la salida estándar a un socket desde la activación del socket, la semántica es similar a la opción respectiva de StandardInput=. Esta configuración predeterminada es heredar.

¿Esto significa que estas son mis únicas opciones? Me gustaría, por ejemplo, poner salida /dev/shmo algo así. Supongo que podría usar un socket de dominio Unix y escribir un oyente simple, pero esto parece un poco innecesario.

Solo necesito esto para la depuración, y probablemente termine eliminando la mayoría de los registros y cambie la salida a syslog.

Actualizar

Como señala mikemaccana, el diario systemd es ahora el dispositivo de registro estándar para la mayoría de las distribuciones. Para ver el stdouty stderrde una unidad systemd, use el journalctlcomando

sudo journalctl -u [unit]

Respuesta original

Por defecto stdouty stderrde una unidad systemd se envían a syslog.

Si está utilizando el systemd completo, será accesible a través de journalctl. En Fedora, debería ser, /var/log/messagespero syslog lo colocará donde sus reglas lo dicen.

Debido a la fecha de la publicación, y suponiendo que la mayoría de las personas que están expuestas a systemd son a través de fedora, probablemente fue golpeado por el error descrito aquí: https://bugzilla.redhat.com/show_bug.cgi?id=754938 Tiene una buena explicación de cómo funciona todo =) (Esto fue un error en la política de selinux que causó que los mensajes de error no se registraran y se solucionó selinux-policy-3.10.0-58.fc16)

Respuesta más breve, simple y no heredada:

sudo journalctl -u [unitfile]

Donde [unitfile] es el .servicenombre del sistema. Por ejemplo, para ver mensajes de myapp.service,

sudo journalctl --unit=myapp

Para seguir registros en tiempo real:

sudo journalctl -f -u myapp