RPi3 not coming back after random reboot

[apachy]

Hi ladies,

A Linux newbie here. I'm running a RPi3 with DietPi and Pi-hole and Nextcloud on it. I noticed that I regularly get "500 - Internal Server Error" on the Pi-hole admin page and when trying to access Nextcloud. I can't access the RPi via SSH afterwards and only thing I can do is to unplug the power. After that is is starting and running without problems.

I enabled persistent logs and noticed that it is always around the 17 minute mark, so I guess it's somehow related with the 17 minute cronjobs. I don't see any errors within the syslog. As far as I understand the logs it's cleaning up some things and reboots the system. Last thing it was showing is:

Code: Select all

Oct 29 23:17:03 DietPi DietPi-Boot[295]: [ INFO ] DietPi-Run_NTPD | Waiting for completion of systemd-timesyncd (1/60)

Does that mean it was stuck at syncing the time and not booting up properly because of that? If so I don't know why there is a problem doing that within the cronjob but not within regularly boots. I'm using pool.ntp.org and can ping it from within the RPi.

[Joulinar]

Hi,

many thanks for your message. Usually there is no restart scheduled on any DietPi own maintenance job's. If your system is rebooting, than something else is not correct.

The 17th minute point is coming from the fact that every hour a time stamp is saved down to disk. This time stamp is used as initial system time during boot process until time sync process completed successful. Mean, your system is not restarted at the 17th minute, it's the time stamp used at this moment.

You would need to find out why your system is crashing / rebooting. Maybe check power supply and/or cable.

[apachy]

Well I thought it might be related to the cronjobs as crontab is showing this entry:

Code: Select all

# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly

Power supply is the original RPi one, but as I have another RPi at my TV I could swap them and check if that is doing anything. And no matter why it was rebooting, why wouldn't it boot up normally but do that, after I pull the plug and put it back in?

Edit: Guess the 17 minute is caused be the fake-hw-clock which saves the current time within this 17 minute cronjob.

[Joulinar]

Hi,

there is a misunderstanding. The hourly cron job is saving the time stamp down to disk. And your system is using this time stamp during boot up process until real time sync succeeded. The time stamp is not saved during boot but it is restored That's why the log always looks like it starts at the 17th minutes if you pull the plug.

One example from my test system. I let it run for the last couple of hours and removed power at 16 CET. Once powered up again, I can see my log starting at 15:17:02. This is the point where the hourly corn job saved the time stamp. But it has nothing to do with the current time or the time I removed power:

Code: Select all

root@DietPi3:~# journalctl
-- Logs begin at Fri 2020-10-30 15:17:02 CET, end at Fri 2020-10-30 16:10:43 CET. --
Oct 30 15:17:02 DietPi3 kernel: Booting Linux on physical CPU 0x0

During boot process, you can see fake-hwclock restoring system time as it was saved by the hourly cron job

Code: Select all

Oct 30 15:17:02 DietPi3 fake-hwclock[107]: Fri Oct 30 14:17:02 UTC 2020

and as soon as time is synced with my NTP server, clock is jumping to actual time. 15:17 > 16:09

Code: Select all

Oct 30 15:17:07 DietPi3 DietPi-Boot[323]: [ .... ] DietPi-Run_NTPD | systemctl restart systemd-timesyncd
Oct 30 15:17:08 DietPi3 systemd[1]: Starting Network Time Synchronization...
Oct 30 15:17:08 DietPi3 systemd[1]: Started Network Time Synchronization.
Oct 30 15:17:08 DietPi3 DietPi-Boot[323]: [  OK  ] DietPi-Run_NTPD | systemctl restart systemd-timesyncd
Oct 30 15:17:08 DietPi3 systemd[1]: Reached target System Time Synchronized.
Oct 30 16:09:45 DietPi3 systemd-timesyncd[406]: Synchronized to time server for the first time 192.168.0.1:123 (fritz.box).
Oct 30 16:09:45 DietPi3 DietPi-Boot[323]: [ INFO ] DietPi-Run_NTPD | Waiting for completion of systemd-timesyncd (1/60)
Oct 30 16:09:45 DietPi3 systemd[1]: Starting Clean php session files...
Oct 30 16:09:46 DietPi3 DietPi-Boot[323]: [  OK  ] DietPi-Run_NTPD | systemd-timesyncd synced
Oct 30 16:09:46 DietPi3 systemd[1]: Stopping Network Time Synchronization...
Oct 30 16:09:46 DietPi3 systemd[1]: systemd-timesyncd.service: Succeeded.
Oct 30 16:09:46 DietPi3 systemd[1]: Stopped Network Time Synchronization.
Oct 30 16:09:47 DietPi3 DietPi-Boot[323]: [  OK  ] Network time sync | Completed

You see, the time stamp inside the log has nothing to do with the actual start time. It doesn't state at which time your system crash. It just give you an indication that it crashed somewhere after last time stamp successfully saved to disk

I hope it clarifies it a little bit why you see the 17th minutes inside your log.

[apachy]

Tried my other power supply as well as a new one. Didn't change a thing. Same for reinstalling everything on a new SD Card. I'm still curious why this reboot, no matter why it happens, doesn't lead to a proper startup, while I can unplug the cable 50 times and get a successful boot every time.

[Joulinar]

probably your system is going into some kind of stuck mode or crash? That's might be the difference as a reboot is working. Did you activate FULL LOG mode already? This might give some indication on log files what's going on.

[WarHawk]

Did you check the cable? Sometimes not only the powersupply but those thin anemic cables can't handle the current flow...5.25vdc at the charger plug on the USB, but 4.8 (or lower) at the connector to plug into the RPi. It may be enough to boot it up..but if/when heavy CPU usage occurs the power dips down and browns out the processor locking everything up

99% of random reboots and stuff are caused by bad power issues

With that said...sometimes the power issues can corrupt the SD card...I usually take my card and put into a SDCard -> USB adapter then use a Linux distro on another computer and use GParted to scan the partitions on the SD for errors...usually it will come back up that way.