Analyzing journald logs?

[ab1jx]

I wonder if there's a program or script for this? I'm on a Pinebook Pro, original mrfixit image on the original eMMC. I have backed it up and I have a nvme SSD which is only manually mounted so far. Anyway I see random shutdowns which look quite orderly in that I don't need to fsck afterwards. So back on November 19 I turned on persistent logging. and let the logs accumulate (now turned back off).

I have 33 logs of these shutdowns, I've exported the last 20 and looked at them some but I'm not seeing a common cause of them. In one I found the string "system will reboot soon", looks like maybe it's from a watchdog. But grepping, it's only in 5 of the 20 log exports. Those could have been planned shutdowns.

I can imagine a program that might try to analyze logs to look for such things, but is there one already?

[Head_on_a_Stick]

Have you read the journalctl man page? Many filtering options are available.

[ab1jx]

Well, I sort of skimmed it. I'm looking for a common cause of these reboots, which I wouldn't expect to find from looking at a single log. And I'm also not sure the answer is in them.. They come from the kernel mostly, it may be more of a userland problem. These are very tidy reboots, not crashes. Maybe it's rebooting on kernel panics, I think the action to take is settable.

I was thinking more of something to load them all into an SQL database really. I'm used to figuring out problems from Xorg logs, but then they tell you what's an error.

I wonder if I could send /dev/kmsg to a file, then look at the file after it reboots? dmsg mostly is readable. From a search, sort of related: https://askubuntu.com/questions/104771/ ... panic-logs

Trying this to start
tail -f /dev/kmsg > mylog.txt
From a one-line script, left running in a terminal emulator that's out of the way.

[ab1jx]

Well, that got me nowhere. I thought it would work because if you plug in a USB device (for example) dmesg will show a few lines about it. I expected to see a few lines about why it reboots but there's nothing.

[CwF]

You may be able to rig something up

Code: Select all

man dbus-monitor

consider some may reboot on heat issues too.

[ab1jx]

I'll try running this for a while:

Code: Select all

#!/bin/bash

# set up dates as file names
adate=`date +"%Y-%m-%d_%H-%M"`
outname=log_$adate.dat

dbus-monitor  --session &> $outname

# can't do --system and --session at the same time


-------------edit -------------
You can't monitor both system and session in the same script, but you can make a script for each and run them at the same time.

[ab1jx]

Well, I did a firmware update on the touchpad and keyboard, went 3 days without a reboot. Then the problem came back and it's rebooting a few times a day. Looking in the logs I've been making what seems to jump out is upower so I did a search: https://duckduckgo.com/?q=upower+reboot ... cal&ia=web

And it seems to have caused reboots, maybe, maybe wishful thinking. I can live without it at least temporarily. This thing has close to 8 hours battery life, which I dragged down a little with an nvme SSD and I was running a USB sound card for doing some recording, but I was still getting 6 hours out of it. It was handy to have a working battery gauge.

[ab1jx]

The firmware update didn't solve anything and I never found anything useful in logs. What I'm doing is ignoring the original mrfixit Stretch on the eMMC and booting from a Daniel Thompson Bullseye installation running on an sd. I've just gotten to a week of uptime so I think it's cured. It was probably the eMMC wearing out, it's about a year old now. I have an nvme SSD in there I mount manually, that's where I keep most of my stuff.