Troubleshooting help - how to identify "Random" reboots and/or non-responsive device

Having issues with your DietPi installation, or, found a bug? Post it here.
User avatar
MichaIng
Site Admin
Posts: 1728
Joined: Sat Nov 18, 2017 5:21 pm

Re: Troubleshooting help - how to identify "Random" reboots and/or non-responsive device

Post by MichaIng » Sun Jun 30, 2019 5:54 pm

@1activegeek
As mentioned above, another way is to disable RAMlog and enable persistent journald log, so you can check last entries before the reboot.

Does it hang on MOTD indeed, so when accessing internet to retrieve the current MOTD (although this should only occur once a day)? This has a timeout of 2 seconds (to not delay the banner too much), so if it didn't get everything until then, you end up with an empty MOTD until it gets reset on daily cron.

But if it hangs longer on network access there might be some other issue. Not sure if PoE and network access itself can conflict/interfere by times, definitely something to check journalctl/dmesg and persistent logs about in case.

One last other idea, as this caused several different issues, is that the device ran out of entropy. Should not lead to a reboot but to hanging boot/network/services, at least for a while after boot. As we anyway install this on all DietPi systems with v6.25 you might want to give it a shot already: G_AGI haveged
Ah to check if indeed entropy is an issue: dmesg | grep 'crng init' should have a few seconds timestamp. If this is lets say 20 seconds or more, then the above entropy daemon can indeed speed up boot and resolve issues of several different kinds: https://github.com/MichaIng/DietPi/issues/2806

1activegeek
Posts: 6
Joined: Sat Jun 15, 2019 7:30 pm

Re: Troubleshooting help - how to identify "Random" reboots and/or non-responsive device

Post by 1activegeek » Thu Jul 04, 2019 8:18 pm

Ok so I managed to switch over to persistent logging. In doing so I'm really confused about some of what I'm seeing - though I surmise one is because I wasn't intended to view the raw log entries in the files in /var/log/journal folders. I tried to, but they're all gibberish as far as I can see with bits/pieces of journal entries.

What is more confusing though is that I'm not seeing the journal entries relative to the most recent restart. Right now logging in I can see that the device has been up 15 minutes as it reports. When checking the journalctl output, the last log line I'm seeing is 11:59:17 EDT, but current time is 15:13, and yet the device is reporting current date output as 7/4/19 11:52:05.

So there are logs future from current date/time. And additionally in the log output I can see some random lines intermingled that are from Jul 2 right in between lines from Jul 4.

Also I snagged a screenshot of what I mean with the MOD - doesn't show you much other than where the hangup is - and I've not let it sit long enough to see how long it will last, but its definitely more than like 30 seconds that I've waited before.

So a bunch of oddities and the date problem leads me to believe there is potentially an on-board problem since it can't seem to keep time anymore.

Code: Select all

[email protected]:/mnt/dietpi_userdata# date
Thu  4 Jul 11:52:05 EDT 2019
[email protected]:/mnt/dietpi_userdata# journalctl
-- Logs begin at Thu 2019-07-04 11:17:01 EDT, end at Thu 2019-07-04 11:59:17 EDT. --
Attachments
Screen Shot 2019-07-04 at 3.00.53 PM.png

User avatar
MichaIng
Site Admin
Posts: 1728
Joined: Sat Nov 18, 2017 5:21 pm

Re: Troubleshooting help - how to identify "Random" reboots and/or non-responsive device

Post by MichaIng » Sun Aug 11, 2019 4:46 pm

@1activegeek
Sorry for the late reply.

Most probably some time sync update that caused the future timestamps. However anther reboot should solve, or simply ignore ;).

What you describe with the hanging MOTD pretty much sounds like an entropy issue or one with IPv6.

So I would try to disable IPv6 (dietpi-config > Network Options: Adapters) and install an entropy daemon as mentioned above. Btw better than haveged on RPi is:
apt install rng-tools
This is an alternative that consumes less RAM but does not work on all machines. But on RPi it works and is default on fresh Raspbian as well.

Post Reply