3

I have a problem where my Pi hangs on reboot.

It only happens on some Pi's after about a month of running scripts. There's a script that resets the Pi every morning and it's on one of these resets that the Pi hanged.

After manually turning it off and back on it works fine.

I can't tell if it hangs during shutdown or booting up. This what the end of syslog looks like:

May 15 03:00:24 raspberrypi CRON[620]: (root) CMD (/usr/bin/python /home/pi/steora/cleanup.py > /dev/null 2>&1)
May 15 03:00:24 raspberrypi systemd[1]: Started Turns off Raspberry Pi display backlight on shutdown/reboot.
May 15 03:00:24 raspberrypi systemd[1]: Starting Synchronise Hardware Clock to System Clock...
May 15 03:00:24 raspberrypi systemd[1]: Stopping system-ifup.slice.
May 15 03:00:24 raspberrypi systemd[1]: Removed slice system-ifup.slice.
May 15 03:00:24 raspberrypi systemd[1]: Stopping system-systemd\x2dfsck.slice.
May 15 03:00:24 raspberrypi systemd[1]: Removed slice system-systemd\x2dfsck.slice.
May 15 03:00:24 raspberrypi systemd[1]: Stopped Update UTMP about System Runlevel Changes.
May 15 03:00:24 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="409" x-info="http://www.rsyslog.com"] exiting on signal 15.`

I can't replicate this problem it just happens sometimes on some Pi's.

UPDATE: I left one raspberry during the weekend to run normally except it resets every 5min, just to see what happens. The same problem occurred after 15 hours and 30 minutes (cca. 186 resets)

EDIT: What can cause such a problem and how to eliminate it? Is reseting RPI every day a bad idea? Could a watch dog timer help in this case?

  • I see what you are saying but don't see a question in there. So let me ask one of my own: Why in the world would you use software to reset a Pi every day? Mine run fine for days and weeks. If there is something that needs initialized every day then I would find a way to do it alone, without upsetting the whole system. – SDsolar Jun 2 '17 at 17:39
  • I thought an everyday reset would help RPI run safer and cleaner. That's why added it. Is this a wrong presumption? Why would a reboot upset the whole system? – Duje Jun 5 '17 at 6:41
  • 1
    You can do whatever works best for you, but my Pis run for days on end without any glitches. They are scattered all over the place (a solar power plant) measuring temperatures and voltages and tilt angles and such, all connected by WiFi. It is a fun system. Every Pi is mated to an Arduino Nano to do the measuring. Rebooting one would not be a major upset.. I only power them off to SD card backups once a month or so, and then only if I have made significant changes. Now that all the networking is working as designed and backed up it would be no big deal if an SD card failed. – SDsolar Jun 5 '17 at 10:00
  • 1
    By "whole system" I meant your Pi. i.e. if something in software or files needs reset periodically I would just have a cron job do it instead of restarting the whole Pi. It isn't that big of a deal. However, if your system is hanging then it may be a problem in the boot sector portion of the SD card. If that were mine I would just restore an .IMG to a new card and try it again. I use Win32DiskImager to keep backups of the cards. Making new ones to replace a failed one is easy. HOWEVER, most commonly when I have a system hang on boot it is because the card needs pushed in tighter. – SDsolar Jun 5 '17 at 10:04
  • Thanks for the comment, your system sounds interesting, I'd love to read more about it if you have a website or something. The thing is once my RPIs leave the lab there's no way to access them later, so they need to function perfectly all the time. Basically, if there's a glitch it's gonna stop working forever. This resets give me a sort of a safety net if something fails it's just gonna start tomorrow fresh. Also, I assume these resets clear memory thus avoiding any kind of memory leaks or corruptions... – Duje Jun 5 '17 at 12:00
1

Irrespective of why you are doing this, have you checked what the last command shows ?

Could there be a conditional bug in your reboot script ?

| improve this answer | |
  • Is software rebooting RPI every day a bad idea? I have custom logging of every action and everything seems to go fine. The reboot script has no conditions and its logs look fine just like every other day when RPI successful reboots. So I don't think that's the problem. – Duje Jun 5 '17 at 6:50
  • Now I see you meant I should check laslog file? There it doesn't say much, just this: root **Never logged in** daemon **Never logged in** ... pi pts/0 duje.dwr-922 Mon Jun 5 10:21:30 +0200 2017 ... But understand that I had to power off/on RPI to get access to it and extract logs... – Duje Jun 5 '17 at 8:27
1
  1. There is no need to reboot the device for the sake of "cleaning the system", its simply not necessary or recommended.
  2. You can use reboot -f to force a reboot without going through shutdown, this can cause data corruption issues, but will work closer to "power cycle" reset than shutdown -r
    • If the problem goes away with reboot -f then the problem is shutdown and not boot.
  3. It's impossible to tell at what point the reboot fails

    May 15 03:00:24 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="409" x-info="http://www.rsyslog.com"] exiting on signal 15.

    Is the log message indicating that logger (rsyslogd) is being shut down (Signal 15 = Quit). So anything that happens after this point is not logged.

  4. A watchdog is a device that forces a hardware reset through reset pin after a certain period of inactivity. They are somewhat tricky to use.
    • Watchdogs require a dedicate thread to "poke" continuously using GPIO, when a poke (or several) is missed, the reset is triggered.
    • When using a watchdog to mind soft reset, there is a risk of "double reboot" or having the watchdog conflict with an ongoing reset. You need to make sure that kernel disables watchdog device as soon as it is possible during boot.

Raspberry PI, unlike a desktop PC, doesn't have a true hardware power controller, so the reset is "soft", using only the CPU reset mode.

In principle, this shouldn't be very different, however, in practice, this type of reset is often "incomplete" because:

  1. You are still using software shutdown (which can crash) to turn your machine off.
  2. Since the power is never interrupted, any external peripherals will not be reset. Sometimes, this can cause problems, for example if an external device continues to issue hardware interrupts through the shutdown process

Debugging the source of the failure to reboot would be an endeavor, without a serial port monitor and an oscilloscope it would be difficult to find a root cause.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.