38

I've created a program that intentionally has a divide by zero error.

If I run it in the command line it returns: "Floating point exception"

But if I run this as a systemd service I can not see this error message.

In my systemd script I have added:

StandardError=journal

But the error message is nowhere to be seen when using journalctl. How can this error message be added to the log seen with journalctl?

Matthias Braun
  • 8,239
Thomas
  • 483
  • It would be helpful if you updated your question to mention your systemd version in use as well as the systemd unit file in question. Also, clarify when you say "run as a system service", do you mean you are running it with sytemctl start, or that you are expecting it to run on boot and it isn't? – Mark Stosberg Dec 27 '16 at 15:43
  • Helpful - https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs. – slm Jul 21 '18 at 07:26
  • Also see https://unix.stackexchange.com/a/608736/46158 – laktak Sep 12 '20 at 18:10

3 Answers3

60

To get all errors for running services using journalctl:

$ journalctl -p 3 -xb

where -p 3 means priority err, -x provides extra message information, and -b means since last boot

blockloop
  • 105
phoenisx
  • 701
  • 2
    If you want to see emerg, alert, crit and error messages as well, run journalctl -p 0..3 -xb – Feriman Mar 11 '21 at 14:42
  • 1
    @Feriman: I think -p 3 and -p 0..3 are equivalent. From man journalctl: "If a single log level is specified, all messages with this log level or a lower (hence more important) log level are shown." – Matthias Braun Sep 09 '21 at 18:20
1

By default stdout and stderr of a systemd unit are sent to syslog. So you can access them in the file /var/log/messages or /var/log/dmesg.

To change that you can use this command:

sudo journalctl -u [yourunit]

Where [yourunit] is the systemd .service name. Eg, to see messages from yourapp.service,

sudo journalctl --unit=yourapp

then restart the journalctl using the command

sudo systemctl restart systemd-journald

if this doesn't work for you add StandardOutput=syslog+console and StandardError=syslog+console to your systemd script and restart systemctl. After that you can access the output from your unit using journalctl.

Dababi
  • 3,355
  • 24
  • 23
  • 2
    Psst! You're barking up the wrong tree. The message in question is not printed by the questioner's program in the first place. – JdeBP Dec 27 '16 at 08:09
  • the user can't view the message in question using journalctl because by default it's sent to syslog and not to systemd journal. I told him how to change that and add it to journald – Dababi Dec 27 '16 at 08:16
  • 1
    You still haven't considered what part of the system is the part printing "Floating point exception" when a process dies with a SIGFPE in an interactive login session. Did the fact that the questioner erroneously called a service unit file a "script" mislead you? It's not a script. – JdeBP Dec 27 '16 at 10:50
  • ok you are right, I made this response because he said that he added StandardError=journal in his script so i thought it was a script – Dababi Dec 27 '16 at 10:57
  • they had to use -u but not for user, --user is user, -u is something else lol – Alexander Mills Mar 26 '20 at 19:09
1

As JdeBP is trying to hint, when you run your program from a shell and it is killed by the signal SIGFPE, the specific message "Floating point exception" is printed by your shell. Technically your program could catch the signal and print an error if you wrote it that way - but that wouldn't work for SIGKILL.

You need some parent process which uses wait() or similar, to read the exit status of your program and log about it. The systemd service manager is such a parent. Its message will not look identical, but it should have something equivalent when you look at the service's logs in the journal. It might mention SIGFPE.

Additionally, if you have systemd-coredump enabled, it should hopefully log a crash message for SIGFPE, since the default action of this signal is to generate a core dump. These crash messages should be tagged such that they show up when querying your service's messages. I like systemd-coredump and make sure to enable it on my Debian systems, although currently installing it will remove Apport, the crash reporter on Ubuntu. When developing, some people might prefer to deal with core files directly and not use systemd-coredump, although it's sort of nice that the core dumps won't clutter your directory, plus they will be cleaned up after a while (freeing the disk space).

sourcejedi
  • 50,249