I've got an rpi3 (Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux) that intermittently hangs on reboot. I'm a bit vague on how to track down the cause since the log files seem more focused on stuff happening during startup than on reboot. When it gets stuck the monitor shows;

[ OK } Started Show Plymouth Reboot Screen
[ OK ] Stopped target Network
Stopping dhcpcd on all interfaces...
[ OK ] Stopped target Remote target File Systems
[ OK ] Stopped target Remote target File Systems (Pre).
[ OK ] Stopped dhcpcd on all interfaces.

the next line would normally be;
stopped target Basic System

so I assume that is where things go awry? The log files, which are normally in chronological order, look like this;

Nov 9 11:59:02 raspberrypi kernel: [ 408.805131] sierra ttyUSB3: Sierra USB modem converter now disconnected from ttyUSB3
Nov 9 11:59:02 raspberrypi kernel: [ 408.805204] sierNov 9 11:52:00 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="420" x-info="http://www.rsyslog.com"] start
Nov 9 11:52:00 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0x0

I can see where I unplugged the cell modem at 11:59:02 on the first line and the beginnings of some new message 'sier' on the second line before I recycled the power. I'm 99% sure the pi did not hang when I unplugged the modem so that means there is nothing in the log to do with the failed reboot. And what am I to make of the fact that the final successful reboot is supposedly 7 mins before the failed one?

I'd be very grateful for clues on how to track down a failed reboot that leaves no trace of itself in the logs since the watchdog (my last line of defense) also fails to detect the lockup.

1 Answer 1


I do not use Raspbian Jessie because its outdated (means old stable) so I cannot help you in particular to this version. But jessie already comes with systemd and in general one main problem to find the error seems to be your thinking in sequential start and stop of the services. This was true with the old style SysV init system but not with systemd, the successor of SysV. Systemd starts and stops services in parallel with dependencies between the services. Look at System bootup process how it works. So your statement "the next line would normally be; stopped target Basic System" makes no sense in this context. It could be any other service depending on it shutdown time and it explains why the shutdown sometimes work.

Of course this behavior makes it difficult to find the error. I suggest to enable persistent logging in the journal, the native logging of systemd, so analyzing may be easier. Enable it with:

rpi ~$ sudo mkdir -p /var/log/journal
rpi ~$ sudo systemd-tmpfiles --create --prefix /var/log/journal

You will get one or two confusing warnings "...Cannot set file attribute..." This are not errors and doesn't matter in this case.

Now you can look at the latest logging with:

rpi ~$ journalctl --boot --pager-end

But more important you can look at your previous bootup and shutdown messages with:

rpi ~$ journalctl --boot -1   # or -2 and so on

As you will see shutting down a service mostly starts with a message like Stopping My Service and the shutdown process ends with Stopped My Service. There are also other messages showing when targets are reached. This may help to locate the error.

You can look at services that have a Stopping My Service but no Stopped My Service entry.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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