I tried to decode this that you provided:
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=30032, si_uid=1000} ---
unlink("/home/licehunter/.mozilla/firefox/5kioifxe.default/lock") = 0
close(18) = 0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fcc5f857900}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [TERM], NULL, 8) = 0
gettid() = 29376
getpid() = 29376
tgkill(29376, 29376, SIGTERM) = 0
--- SIGTERM {si_signo=SIGTERM, si_code=SI_TKILL, si_pid=29376, si_uid=1000} ---
Exiting due to channel error.
In particular:
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=30032, si_uid=1000} ---
SIGTERM
I read that is a standard software termination signal.
I also read:
si_code=SI_USER
This means the termination signal came from another user-space process, not the kernel nor a hardware fault.
Then:
si_pid=30032
I read this is the process that sent the termination signal.
Then
si_uid=1000
I read this is the user account (yours) that sent the signal (ie not root/system).
At least, that is how I interpret that.
I read:
Exiting due to channel error.
+++ killed by SIGTERM +++
That confirms Firefox was terminated … obviously … But perhaps that is what indicates why the termination did not occur in a manner to provide a Crash Report, which is supporting your observation.
So that SIGTERM indicates another process, running as the same user (uid=1000) which I believe is you, is killing Firefox with SIGTERM.
The above simply proves what you already have noted for sometime.
Except, perhaps, the process associated with the termination has PID 30032.
I do not know how to be able to identify that process long after the crash.
Possibly with ‘strace’ running … if you see that SIGTERM, and if you can immediately identify the PID (in my example 30032) that is killing firefox, you could run:
ps -fp 30032
That gives more detail to attempt to figure out what 30032 (in this example) is.
… or maybe it might be in the journal ? (wild speculation by me) :
sudo journalctl _PID=30032
or
sudo journalctl --user -b | grep 30032
of course each crash could have a different PID … so “30032” likely on each firefox termination it won’t be the same PID after a reboot.
I am still interested in the journal outputs, and I take it from your silence on this, with no replies to my suggestions there, that there was nothing interesting?
I could give more filters for journalctl but frankly, as noted, I suspect you are not interested in that line of journal in researching the problem, and you could be right. Possibly I am wrong about there being anything of value there in the journal. ( … but for myself, I have always found it of value).
An alternative approach to ‘strace’, to try to find the PID of a process that might be associated with killing firefox, you could try this audit rule (that monitors events), sending this BEFORE running firefox:
sudo auditctl -a exit,always -F arch=b64 -S kill
Then let firefox run. After firefox crashes, send this:
sudo ausearch -sc kill
The idea is that this may show all the kill-related syscalls that occurred, including any signals sent to terminate Firefox. If the crash is caused by another process , you’ll be able to see which process sent the signal.
Again, if only a PID # (such as 30032 in my example), then use
ps -fp 30032
or
sudo journalctl _PID=30032
or
sudo journalctl --user -b | grep 30032
Good luck!