Visualizza stdout / stderr del servizio systemd


175

Ho creato un semplice file di servizio systemd per un'applicazione personalizzata. L'applicazione funziona bene quando la eseguo manualmente, ma la mia CPU viene massimizzata quando la eseguo con systemd.

Sto cercando di rintracciare il mio problema, ma non so dove trovare l'output (o come configurare systemd per posizionare l'output da qualche parte).

Ecco il mio file di servizio:

[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

Durante l'applicazione, ho eseguito l'output su stdout e stderr.

Come posso leggere l'output del mio demone?

Modificare:

Ho trovato man systemd.exec, che ha menzionato l' StandardOutput=opzione, ma non sono sicuro di come usarlo. Dalla pagina man :

StandardOutput=

Controlla dove è collegato il descrittore di file 1 (STDOUT) dei processi eseguiti. Prende uno di eredita , null , tty , syslog , kmsg , kmsg + console , syslog + console o socket .

Se impostato per ereditare, il descrittore di file dell'input standard viene duplicato per l'output standard. Se impostato su null , verrà collegato l'output standard /dev/null, vale a dire che tutto ciò che è scritto su di esso andrà perso. Se impostato su tty , l'uscita standard sarà collegata a un tty (come configurato tramite TTYPath=, vedere di seguito). Se TTY viene utilizzato per l'output, solo il processo eseguito non diventerà il processo di controllo del terminale e non fallirà né attenderà che altri processi rilascino il terminale. syslog collega l'output standard al logger di sistema syslog (3). kmsg lo collega al buffer del log del kernel, accessibile tramite dmesg (1). syslog + console e kmsg + consolefunziona in modo simile ma copia anche l'output sulla console di sistema. socket collega l'output standard a un socket dall'attivazione del socket, la semantica è simile alla rispettiva opzione di StandardInput=. L'impostazione predefinita è eredita.

Questo significa che queste sono le mie uniche opzioni? Vorrei, ad esempio, inserire l'output /dev/shmo qualcosa del genere. Suppongo che potrei usare un socket di dominio Unix e scrivere un semplice ascoltatore, ma questo sembra un po 'inutile.

Ho solo bisogno di questo per il debug e probabilmente finirò per rimuovere la maggior parte dei registri e cambiare l'output in syslog.


Hai provato a controllare l' /var/log/syslogoutput? La maggior parte dei sistemi accederà alle cose, /var/log/quindi inizierei controllando lì. Puoi usare la grepricerca di testo se conosci l'output: grep "my output" /var/logdovresti fare il trucco.
sbtkd85,

@ sbtkd85 - Beh, non ho /var/log/syslog, ma /var/log/messagesfa il trucco. Il problema è che, secondo i registri, il mio demone si arresta in modo anomalo all'avvio, ma posso dire che è ancora in esecuzione perché ha un server HTTP e posso interrogarlo. Sembra che il resto dei registri si stiano perdendo ...
beatgammit,

Perché non provare le impostazioni in StandardOutput=ttymodo da poter vedere cosa sta succedendo quando avvii il tuo demone. Dovrebbe essere emesso il terminale (potrebbe essere necessario utilizzare ttyS0o simile per ottenere l'output sullo schermo).
sbtkd85,

3
Gli operatori di reindirizzamento IO standard non dovrebbero funzionare in questo contesto. Qualcosa del genereExecStart=/usr/local/bin/filesync-client --port 2500 2>/tmp/filesync.log
Deepak Mittal

Cosa sta realmente abusando della tua CPU? È systemd, il tuo servizio o sistema (ad esempio generando nuove copie del servizio perché systemd è impazzito)?
peterph

Risposte:


184

Aggiornare

Come osserva mikemaccana, il journal di systemd è ora il dispositivo di registrazione standard per la maggior parte delle distro. Per visualizzare l'unità stdoute stderrdi un'unità systemd, utilizzare il journalctlcomando

sudo journalctl -u [unit]

Risposta originale

Di default stdoute stderrdi un'unità systemd vengono inviati a syslog.

Se stai utilizzando il sistema completo, questo sarà accessibile tramite journalctl. Su Fedora, dovrebbe essere, /var/log/messagesma syslog lo metterà dove dicono le tue regole.

A causa della data del post, e supponendo che la maggior parte delle persone esposte a systemd siano tramite fedora, probabilmente sei stato colpito dal bug descritto qui: https://bugzilla.redhat.com/show_bug.cgi?id=754938 Ha una buona spiegazione di come tutto funziona troppo =) (Questo era un bug nella politica di selinux che faceva sì che i messaggi di errore non venissero registrati e che fosse corretto selinux-policy-3.10.0-58.fc16)


5
Si noti che l'utilizzo del meccanismo di registrazione standard come questo non creerà registri persistenti per impostazione predefinita. Per fare ciò, dovrai creare / var / log / journal e quindi eseguiresudo systemctl restart systemd-journald
mlissner

1
quale funzione e priorità syslog?
jrwren,

2
Questo ha funzionato per me: StandardOutput=syslog+consolee in StandardError=syslog+consoleseguito tutto l'output della mia unità è apparso su journalctl. L'impostazione predefinita apparentemente era errata. (Come DefaultStandardOutput in /etc/systemd/system.conf)
gregn3

2
-fè stato utile per me. Seguito il registro quando si verificano modifiche (il caso d'uso seguiva il server Minecraft che era in esecuzione come demone)
blaughw,

2
Questo mi sta facendo impazzire ... In un journalctl standard di Debian non mi verrà mostrato alcun output standard. Uso anche /usr/bin/stdbuf -oL <cmd>un esplicito StandardOutput=journal. Ancora niente.
jlh

81

Risposta più breve, più semplice e non legacy:

sudo journalctl -u [unitfile]

Dove [unitfile] è il .servicenome systemd . Ad esempio, per vedere i messaggi da myapp.service,

sudo journalctl --unit=myapp

Per seguire i registri in tempo reale:

sudo journalctl -f -u myapp

4
Si noti che potrebbe essere necessario sudose si riceve un No journal files founderrore.
bigjosh,

5
syslog non è eredità ...
Miles Rout il

2
È nelle attuali distribuzioni Linux. Potrebbe piacerti davvero syslog ma questo non cambia ciò con cui vengono spediti.
Mikemaccana,

1
Sicuro. E usa anche syslog. Il mio punto non era che systemd non fosse usato, ma che syslog non fosse legacy.
labirinto

6
@JECompton se tutta la registrazione nelle attuali distribuzioni Linux utilizza journald e syslog non è necessario e utilizzato solo per la compatibilità, ne consegue logicamente che syslog è legacy.
mikemaccana,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.