I have created a simple systemd service file for a custom application. The application works well when I run it manually, but my CPU gets maxed out when I run it with systemd.
I’m trying do track down where my problem is, but I don’t know where to find the output (or how to configure systemd to put the output somewhere).
Here is my service file:
[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
Throughout the application, I output to stdout and stderr.
How can I read the output of my daemon?
man systemd.exec, which mentioned the
StandardOutput= option, but I’m not sure how to use it. From the man page:
Controls where file descriptor 1 (STDOUT) of the executed processes is connected to. Takes one of inherit, null, tty, syslog, kmsg, kmsg+console, syslog+console or socket.
If set to inherit the file descriptor of standard input is duplicated for standard output. If set to null standard output will be connected to
/dev/null, i.e. everything written to it will be lost. If set to tty standard output will be connected to a tty (as configured via
TTYPath=, see below). If the TTY is used for output only the executed process will not become the controlling process of the terminal, and will not fail or wait for other processes to release the terminal. syslog connects standard output to the syslog(3) system logger. kmsg connects it with the kernel log buffer which is accessible via dmesg(1). syslog+console and kmsg+console work similarly but copy the output to the system console as well. socket connects standard output to a socket from socket activation, semantics are similar to the respective option of
StandardInput=. This setting defaults to inherit.
Does this mean that these are my only options? I would like, for example, to put output in
/dev/shm or something. I suppose I could use a Unix domain socket and write a simple listener, but this seems a little unnecessary.
I just need this for debugging, and I’ll probably end up removing most of the logs and change the output to syslog.
Here is Solutions:
We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.
sudo journalctl -u [unit]
stderr of a systemd unit are sent to syslog.
If you’re using the full systemd, this will be accesible via
On Fedora, it should be
/var/log/messages but syslog will put it where your rules say.
Due to the date of the post, and assuming most people that are exposed to systemd are via fedora, you were probably hit by the bug described here:
It has a good explanation of how it all works too =) (This was a bug in selinux-policy that caused error messages to not be logged, and was fixed in
Shorter, simpler, non-legacy answer:
sudo journalctl -u [unitfile]
Where [unitfile] is the systemd
.service name. Eg, to see messages from
sudo journalctl --unit=myapp
To follow logs in real time:
sudo journalctl -f -u myapp
Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂