1. Home
  2. Raspberry Pi Group
  3. Pi rebooting for some reason - syslog looks rather strange

Pi rebooting for some reason - syslog looks rather strange

My RaspberryPi has rebooted itself a couple of times recently and ended up in a non-working state. In particular it has no ethernet connection which is rather unfortunate as it's headless.

Power down/power up fixes it but having run for months without problems previously it would seem there is something wrong.

It's pretty much up to date as regards software:-

Linux dns 4.14.79+ #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l GNU/Linux

Syslog has the following:-

Jan 20 06:25:06 dns liblogging-stdlog: [origin software="rsyslogd" swVersion="8.24.0" x-pid="221" x-info="

formatting link
"] rsyslogd was HUPed Jan 20 06:25:07 dns liblogging-stdlog: [origin software="rsyslogd" swVersion="8.24.0" x-pid="221" x-info="
formatting link
"] rsyslogd was HUPed Jan 20 06:47:01 dns CRON[12852]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )) Jan 20 06:49:25 dns dnsmasq-dhcp[383]: DHCPREQUEST(eth0) 192.168.1.96 2c:08:8c:cc:9a:9e Jan 20 06:49:25 dns dnsmasq-dhcp[383]: DHCPACK(eth0) 192.168.1.96 2c:08:8c:cc:9a:9e humaxYouview Jan 20 06:17:10 dns systemd-modules-load[67]: Inserted module 'snd_bcm2835' Jan 20 06:17:10 dns systemd-modules-load[67]: Inserted module 'i2c_bcm2708' Jan 20 06:17:10 dns systemd-modules-load[67]: Inserted module 'i2c_dev' Jan 20 06:17:10 dns fake-hwclock[81]: Sun 20 Jan 06:17:02 UTC 2019 Jan 20 06:17:10 dns systemd-fsck[97]: /dev/mmcblk0p2: clean, 52463/483328 files, 518329/1925120 blocks Jan 20 06:17:10 dns blkmapd[107]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory Jan 20 06:17:10 dns systemd[1]: Started File System Check on Root Device. Jan 20 06:17:10 dns systemd[1]: Started Create Static Device Nodes in /dev. Jan 20 06:17:10 dns systemd[1]: Started Apply Kernel Variables. Jan 20 06:17:10 dns systemd[1]: Started pNFS block layout mapping daemon. Jan 20 06:17:10 dns systemd[1]: Started File System Check Daemon to report status. Jan 20 06:17:10 dns systemd[1]: Starting udev Kernel Device Manager... Jan 20 06:17:10 dns systemd[1]: Starting Remount Root and Kernel File Systems... Jan 20 06:17:10 dns systemd[1]: Started Remount Root and Kernel File Systems. Jan 20 06:17:10 dns systemd[1]: Starting Load/Save Random Seed... Jan 20 06:17:10 dns systemd[1]: Starting udev Coldplug all Devices... Jan 20 06:17:10 dns systemd[1]: Starting Flush Journal to Persistent Storage... Jan 20 06:17:10 dns systemd[1]: Started udev Kernel Device Manager. Jan 20 06:17:10 dns systemd[1]: Started Load/Save Random Seed. Jan 20 06:17:10 dns systemd[1]: Started Flush Journal to Persistent Storage. Jan 20 06:17:10 dns systemd[1]: Started Set the console keyboard layout. Jan 20 06:17:10 dns systemd[1]: Reached target Local File Systems (Pre). Jan 20 06:17:10 dns systemd[1]: Started udev Coldplug all Devices. Jan 20 06:17:10 dns systemd[1]: Found device /dev/ttyAMA0. Jan 20 06:17:10 dns ifplugd: Invoking ifplugd for eth0 Jan 20 06:17:10 dns systemd[1]: Found device /dev/mmcblk0p1. Jan 20 06:17:10 dns systemd[1]: Mounting /boot... Jan 20 06:17:10 dns systemd[1]: Mounted /boot. Jan 20 06:17:10 dns systemd[1]: Reached target Local File Systems. Jan 20 06:17:10 dns systemd[1]: Starting Preprocess NFS configuration... Jan 20 06:17:10 dns systemd[1]: Starting Create Volatile Files and Directories... Jan 20 06:17:10 dns systemd[1]: Starting Raise network interfaces... Jan 20 06:17:10 dns systemd[1]: Starting Set console font and keymap... Jan 20 06:17:10 dns systemd[1]: Started Preprocess NFS configuration. Jan 20 06:17:10 dns ifplugd(eth0)[171]: ifplugd 0.28 initializing. Jan 20 06:17:10 dns systemd[1]: Reached target NFS client services. Jan 20 06:17:10 dns systemd[1]: Starting NFSv4 ID-name mapping service... Jan 20 06:17:10 dns systemd[1]: Started Set console font and keymap. Jan 20 06:17:10 dns ifplugd(eth0)[171]: Using interface eth0/B8:27:EB:22:D7:92 with driver (version: 22-Aug-2005) Jan 20 06:17:10 dns ifplugd(eth0)[171]: Using detection mode: SIOCETHTOOL Jan 20 06:17:10 dns ifplugd(eth0)[171]: Initialization complete, link beat not detected. Jan 20 06:17:10 dns systemd[1]: Started Create Volatile Files and Directories. Jan 20 06:17:10 dns kernel: [ 0.000000] Booting Linux on physical CPU 0x0 Jan 20 06:17:10 dns kernel: [ 0.000000] Linux version 4.14.79+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1159 Sun Nov 4 17:28:08 G> Jan 20 06:17:10 dns kernel: [ 0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d Jan 20 06:17:10 dns kernel: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Jan 20 06:17:10 dns kernel: [ 0.000000] OF: fdt: Machine model: Raspberry Pi Model B Rev 1 Jan 20 06:17:10 dns kernel: [ 0.000000] Memory policy: Data cache writeback Jan 20 06:17:10 dns kernel: [ 0.000000] cma: Reserved 8 MiB at 0x0b400000 Jan 20 06:17:10 dns kernel: [ 0.000000] On node 0 totalpages: 49152 Jan 20 06:17:10 dns kernel: [ 0.000000] free_area_init_node: node 0, pgdat c09c6650, node_mem_map cbe3a300 Jan 20 06:17:10 dns kernel: [ 0.000000] Normal zone: 432 pages used for memmap Jan 20 06:17:10 dns kernel: [ 0.000000] Normal zone: 0 pages reserved

So, up to 06:49 (where it serves a DNS request, it's running dnsmasq on my LAN) all seems well, then the time jumps backwards and after some systemd messages it reboots itself (into a not fully working state).

Does anyone have any idea what might be going wrong?

--
Chris Green
Reply to
Chris Green
Loading thread data ...

overheating? have you tried a CPU heat sink?

might also be something simple, like power spikes. a Big Fat Capacitor across the 5V input (with a 0.47uF ceramic in parallel with it) might help. Rapid power sags, caused by lots of possible things, is a likely cause for unplanned reboots.

see above

--
(aka 'Bombastic Bob' in case you wondered) 

'Feeling with my fingers, and thinking with my brain' - me 

'your story is so touching, but it sounds just like a lie' 
"Straighten up and fly right"
Reply to
Big Bad Bob

Hello Chris!

23 Jan 19 14:28, you wrote to Helmut Harnisch:

CG> Yes, absolutely, but when it was working OK (i.e. upto 06:49) it would CG> have the correct time, so that's probably the correct time. I quite CG> agree that when booting the time is basically random until it gets a CG> LAN connection up and can ask someone the time.

When the system shuts down, the time is saved. When booting that time is used as a start value. Many jobs in the system do not like jumping back in time. Look for e.g. fake-hwclock in /etc/init.d/ for how it is done.

Kees

Reply to
Kees van Eeten

That seems unlikely given that it's winter now and it's definitely colder in the room where it is.

Possible I suppose, I guess I could simply try a different supply to run it from, I have quite a few different ones which I can try.

Thanks for the ideas.

--
Chris Green
Reply to
Chris Green

I'm also running headless, an early (512MB) Pi B, that fails to start correctly often enough to be a nuisance. This is always a cold start after it hasn't run for a while. Occasionally it fails to accept an SSH connection immediately after starting. More commonly it apparently comes up correctly but refuses an SSH connection some time (0.5 - 2 hrs) later.

Mine is seldom more than a week behind on updates.

The only difference between yours and mine is that mine has not yet been knocked offline by power supply issues.

Nope. I've posted this in the hope that somebody may see a connection.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

And make sure the cable between the PSU and the Pi has a low enough resistance - short and fat is good, in this instance :-)

Dave

Reply to
David Higton

Am 20.01.2019 um 10:33 schrieb Chris Green:

When the Pi starts, it has no network. So it does not know the right time and date. As soon as the network is up, the os fetches the actual time and date from a time server. Thats propably why the time glitches...

Reply to
Helmut Harnisch

On a sunny day (Wed, 23 Jan 2019 09:01:58 +0000) it happened Chris Green wrote in :

I think a bad wallwart is sure a possibility, the electrolytic capacitors in those often go bad. OTOH I have a Pi like yours now running about 12 hours a day since 2013 on the same old wallwart:

formatting link
stopped every evening with 'poweroff' and has not failed to boot once, same old card... Sometimes I accidently unplug it.. it still reboots OK every time. But I NEVER upgrade things that work (never repair something that works!!!) Fixed IP address (could that explain something?). One thing: your card does not happen to be full? I had that once and it caused all sort of strange problems. The pi above also gets its time from the LAN via the internet when it starts up.

Reply to
Jan Panteltje

Mine is on permananently because it's the DNS and DHCP server for the home LAN.

:-)

Since it is the DNS/DHCP server it has to be fixed IP really.

No, I've checked that, it's one of the first things I always look at when there are strange things happening.

Yes, that's why the times at boot jump about a bit.

--
Chris Green
Reply to
Chris Green

Yes, absolutely, but when it was working OK (i.e. upto 06:49) it would have the correct time, so that's probably the correct time. I quite agree that when booting the time is basically random until it gets a LAN connection up and can ask someone the time.

--
Chris Green
Reply to
Chris Green

It's not random, it has a fake hardware clock module which periodically saves the current time, then uses it on a reboot before ntp kicks in.

e.g. Times in Syslog may look something like

2115 Save Clock 2118 Crash 2115 Restarting 2120 Got NTP

---druck

Reply to
druck

That's configurable and not the default though if I remember right.

--
Chris Green
Reply to
Chris Green

I didn't mean random in the sense of like a random number, I just meant not the actual time.

I believe *some* systems do what you're describing but I don't think it's by any means universal in all distributions. In particular I know that Beaglebone systems don't reboot to 'nearly the right time' by default. I was thinking that Pi works the same but maybe not.

--
Chris Green
Reply to
Chris Green

Yes it is.

Reply to
A. Dumas

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.