5

I've just got a Raspberry Pi and it is working very well, but I realized that at some point it restarted without any apparent cause. I was thinking about a possible power cut off, but it is currently attached to a UPS (that would have started beeping in case of power loss).

Is there any way to examine the logs to discover what caused the restart?

Steve Robillard
  • 34,687
  • 17
  • 103
  • 109
Derek Wildstar
  • 163
  • 1
  • 6
  • Uptime report pi@raspberrypi:/var/log $ uptime -s 2016-02-27 23:23:27

    but looking at old syslog I see nothing strange just my cron job and then the restart

    Feb 27 23:17:01 raspberrypi CRON[23010]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Feb 27 23:17:04 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="429" x-info="http://www.rsyslog.com"] start Feb 27 23:17:04 raspberrypi systemd-modules-load[82]: Inserted module 'fuse' Feb 27 23:17:04 raspberrypi systemd-modules-load[82]: Inserted module 'i2c_dev'

     – Derek Wildstar Mar 02 '16 at 11:33
  • Sorry again Derek but I've rolled your edit back because as originally written this makes a good generic question that might be useful to other people, which is what we aim for here -- please see the tour. It seems like you have a problem which is harder to solve than just looking at the very last log messages and there may, in fact, be no clue at all available -- i.e., unless you can come up with an experiment to reproduce the problem, you are stuck. – goldilocks Mar 02 '16 at 11:51
  • Understood... I thought that there could be an additional step of checking that could be done but apparently I'm out of luck today :( Will accept your answer as, as you said, is a very good starting point for the investigation. – Derek Wildstar Mar 02 '16 at 13:45

2 Answers2

1

There's any way looking into some logs to discover what caused the restart?

Currently Raspbian still puts a copy of everything into /var/log/syslog. You need privileges to access this file, i.e., either su root or use sudo less .... or sudo cat ... or sudo grep .....

You are looking for the messages that indicate the beginning of the last boot; these will begin something like:

Feb  6 21:27:19 localhost rsyslogd: [origin software="rsyslogd" swVersion="8.10.0" x-pid="7932" x-info="http://www.rsyslog.com"] start
Feb  6 21:27:19 localhost kernel: [    0.000000] Initializing cgroup subsys cpuset

Beware your hostname is not necessarily localhost.

There may be some difference in the content of the second message, but this is the point at which the system logger (rsyslog1) copies in the stuff you can see with dmesg, which is the kernel speaking. Kernel timestamps (e.g. [ 0.000000]) are in seconds (so have microsecond granularity); the date/clock timestamp is added by the rsyslog itself so will always be present whereas the kernel ones will only be for messages from the kernel itself (hence rsyslog's "start" message doesn't have one).

Since that indicates the last boot, you are looking for the messages immediately before these two lines. For a normal shutdown, the last one should be something like:

Feb  9 22:32:32 localhost rsyslogd: [origin software="rsyslogd" swVersion="8.10.0" x-pid="11188" x-info="http://www.rsyslog.com"] exiting on signal 15.

One problem with failures is that if they are sudden or involve some kind of crippling due to resource issues (out of RAM, hogged processor) the system may not have synced to disk and error messages will not have made it into the file.

1. Actually, there's another system logger integrated into systemd, the init system, called journald. However, since it's files are not human readable text it is not of much use particularly if you are, e.g., examining a card from a failed system in another computer.

goldilocks
  • 58,849
  • 17
  • 112
  • 227
  • I've added a little more details about syslog... surely it did not shutdown properly. About resource issue... I do not think is the case as so far I'm just running a cron script to check internet connection nothing more. – Derek Wildstar Mar 02 '16 at 11:40
  • I.e., you got an answer to your question and now have a clue as to what to investigate about what might have to do with the problem (something run from cron.hourly). Could be a dead end. Note this is not a discussion forum, so we don't do endless/indeterminate sequences of "Okay, so then..." -- you have to break things down into separate questions. The reason for this is otherwise many people who might otherwise be helpful simply will not participate because they do not have time to get dragged into indeterminate problem solving discussions. That includes me -- sorry, but good luck. – goldilocks Mar 02 '16 at 11:45
  • With no doubt, this kind of issues are not reported on a log. Most of the time after a fatal error, the kernel goes into restart mode without writing anything back to disk: tables may be corrupted and may create more damage. Start stopping services and applications and keep trying... On another note, RPi is quite sensitive to power, even with UPS, if you power supply voltage is not steady you will run into issues. – fcm Mar 02 '16 at 13:44
  • "With no doubt, this kind of issues...." -> Is, to be frank, the deranged product of anecdotal reflections by a confused individual backed up by high falutin' sounding mumbo-jumbo. E.g., there is no such thing as "kernel restart mode" (and if you doubt this, search online linux "kernel restart mode"). The starting and stopping of init services generally will be logged. However, power failure events will leave pretty much no sign. Other problems, such as OOM events and (other) misbehaving processes (which are probably the most common killers) will leave a copious trail. @Fcm – goldilocks Mar 02 '16 at 18:41
  • OK @goldilocks is 'panic' mode or other (self defense) states where there is no other option than restart or, if your prefer, reboot. A user level process detecting abnormalities will probably log something and very unlikely, force a reboot, however, kernel level invalid instructions on a device driver, will. – fcm Mar 02 '16 at 19:24
  • Kernel panics are usually logged, unless they are hardware problems involving the root filesystem. Note that this kind of discussion is NOT going to assist the OP except to create confusion, and is a perfect example of why SE is NOT a discussion forum. If you have an answer, spend time composing it, back it up with references, qualify it WRT circumstances etc. – goldilocks Mar 02 '16 at 19:33
1

There was an issue where Raspberry Pi 2 would reset itself when a specific part was exposed to a Xenon flash:

http://www.ibtimes.co.uk/camera-shy-raspberry-pi-2-resets-when-exposed-xenon-flash-1487238

High intensity lights such as flashes or laser pointers could cause voltage drops and reset the device.

mike glenndale
  • 111
  • 1