Programs like Calls are allowed to crash silently without any journalctl error message
Until now, I have been assuming that if a program crashes (segmentation fault, assertion failure or similar), then there would always be some kind of error message in the journalctl
log saying that something crashed. Now, to my surprise, I found that it seems programs can crash without anything being logged about it.
The example below is about the Calls program gnome-calls
which handles phone calls, but I think there is a more general issue to consider here, the way programs are run, there should be ways of configuring things so that an error message is logged whenever there is a crash.
I think that when systemd-coredump
is installed, there will always be something logged for each crash, but that package is not installed by default.
Here is an example of what journalctl
shows when Calls crashed on a Librem 5 that did not have systemd-coredump
installed, so this is default behavior:
Jan 06 12:17:15 pureos pulseaudio[822]: Playback too far ahead (9959), drop source 1912
Jan 06 12:17:16 pureos pulseaudio[822]: Playback too far ahead (9986), drop source 1916
Jan 06 12:17:17 pureos pulseaudio[822]: Playback too far ahead (9892), drop source 1896
Jan 06 12:17:18 pureos pulseaudio[822]: Playback too far ahead (10183), drop source 1952
Jan 06 12:17:19 pureos ModemManager[768]: <info> [modem0/call3] call state changed: active -> terminated (unknown)
Jan 06 12:17:30 pureos dbus-daemon[826]: [session uid=1000 pid=826] Activating service name='org.gnome.Contacts' requested by ':1.207' (uid=1000 pid=4433 comm="gnome-calls ")
Jan 06 12:17:30 pureos dbus-daemon[826]: [session uid=1000 pid=826] Successfully activated service 'org.gnome.Contacts'
Jan 06 12:17:30 pureos gnome-session[963]: gnome-session-binary[963]: WARNING: App 'org.gnome.Calls-daemon.desktop' respawning too quickly
Jan 06 12:17:30 pureos gnome-session-binary[963]: WARNING: App 'org.gnome.Calls-daemon.desktop' respawning too quickly
Jan 06 12:17:30 pureos gnome-session[963]: gnome-session-binary[963]: WARNING: Error on restarting session managed app: Component 'org.gnome.Calls-daemon.desktop' crashing too quickly
Jan 06 12:17:30 pureos gnome-session-binary[963]: WARNING: Error on restarting session managed app: Component 'org.gnome.Calls-daemon.desktop' crashing too quickly
In that case there was an ongoing phonecall resulting in some pulseaudio log entries, then ModemManager notes that the call was terminated and dbus-daemon says something about Contacts. Nothing of that indicates any error. Then comes a line saying "respawning too quickly" which I think is because Calls has crashed, but there is nothing logged about the crash itself. Maybe Calls crashed several times in a short timespan, causing the "respawning too quickly" message. Then there is also a line saying Calls was "crashing too quickly".
It does not sound good that something is "crashing too quickly", I think there should be an error message each time something crashed, regardless of how quickly it was. Presumably there may have been many other crashes about which there is nothing at all logged, because those crashes did not happen in quick succession.
I suspect that a lot of issues with various kinds of weird behavior on the Librem 5 may be related to programs having crashed silently in this way. At least for me, troubleshooting when something strange happened involves looking at what journalctl
says at the time of the problem. If something has crashed then that is very important information, troubleshooting will be much easier if all crashes are logged.
So, it would seem like a good idea to change the way programs are run such that silent crashes are no longer allowed, so that something is seen in the log each time a program has crashed. In case of Calls I think the file /etc/xdg/autostart/org.gnome.Calls-daemon.desktop
may have something to do with this, but I'm not sure. That file has lines saying things like Exec=gnome-calls --daemon
and X-GNOME-AutoRestart=true
, perhaps it is possible to control error logging behavior from there?
Another suggestion is to have systemd-coredump
installed by default, or at least to recommend installing that as a standard troubleshooting step. Or maybe there are better ways to make crashes visible.