RPi Zero W still supported?

I notice that my R-Shake STATION: AM.R79D5.00.EHZ running on “Machine model: Raspberry Pi Zero W Rev 1.1” will no longer display a web page on my LAN, although I can still ssh into it. This is using a USB-Ethernet adaptor, not the wifi link. It doesn’t look like the normal data acquisition process is running. It had been working OK for about a year or so, but I haven’t been monitoring it actively in recent months.

I’m wondering if there was some auto-update in recent months that may not work properly on a Pi Zero, as that is probably uncommon hardware for most? Below is /opt/log/myshake.out

System Report: Wed Mar 18 00:00:02 UTC 2020

Versioning

  OS Version : Raspbian GNU/Linux 8 (jessie)

Kernel version : Linux raspberryshake 4.14.61+ #1132 Tue Aug 7 15:07:20 BST 2018 armv6l GNU/Linux
Software Version : v0.2
Firmware Version : RS1D-6-4.5
ODF Version : 2020.045

Computer Info

RPi revision : 9000c1 (Zero W)
ODF Serial Port : /dev/ttyS0
MAC Address : 00:0e:c6:b4:79:d5
UpTime : 00:00:03 up 1 min, 0 users, load average: 0.94, 0.38, 0.14
System time : Wed Mar 18 00:00:03 UTC 2020:
Disc usage : /dev/root 7.2G 2.3G 4.7G 33% /
CPU Temp : 38 C

System Info

heli_ewII : NOT Running
OWS : NOT Running
SeedLink : NOT Running
ODF : NOT Running
slarchive : NOT Running
SL info:
NONE Available

crontab Info:

@daily /usr/local/bin/myShake
@hourly /usr/local/bin/clean-logs
7 14 * * 6 /usr/local/bin/rsh-sw-fetcher C >/dev/null 2>&1

Station Info

Data-Sharing Mode : ON
Data Server Conn : OFF
Save Data Days : 7
Heli Scale : 0.1
Station Name : AM.R79D5.00.EHZ
Geophone : OSOP

Clock Info

  • ntpdate.service - Network Time Service
    Loaded: loaded (/lib/systemd/system/ntpdate.service; enabled)
    Active: active (exited) since Tue 2020-03-17 23:58:54 UTC; 1min 12s ago
    Process: 579 ExecStart=/usr/sbin/ntpd -u ntp:ntp -q -g -x -t 5 (code=exited, status=0/SUCCESS)

Mar 17 23:17:20 raspberryshake ntpd[579]: ntpd 4.2.6p5@1.2349-o Mon Jul 25 22:35:28 UTC 2016 (1)
Mar 17 23:17:20 raspberryshake ntpd[579]: proto: precision = 1.000 usec
Mar 17 23:17:20 raspberryshake ntpd[579]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Mar 17 23:17:20 raspberryshake ntpd[579]: Listen and drop on 1 v6wildcard :: UDP 123
Mar 17 23:17:20 raspberryshake ntpd[579]: Listen normally on 2 lo 127.0.0.1 UDP 123
Mar 17 23:17:20 raspberryshake ntpd[579]: Listen normally on 3 eth0 192.168.1.130 UDP 123
Mar 17 23:17:20 raspberryshake ntpd[579]: peers refreshed
Mar 17 23:17:20 raspberryshake ntpd[579]: Listening on routing socket on fd #20 for interface updates
Mar 17 23:58:54 raspberryshake systemd[1]: Started Network Time Service.
Mar 17 23:58:54 raspberryshake ntpd[579]: ntpd: time set +2487.070333s

  • ntpd.service - Network Time Service
    Loaded: loaded (/lib/systemd/system/ntpd.service; enabled)
    Active: active (running) since Tue 2020-03-17 23:58:54 UTC; 1min 12s ago
    Process: 719 ExecStart=/usr/sbin/ntpd -u ntp:ntp -f /etc/ntp.conf -p /run/ntpd.pid (code=exited, status=0/SUCCESS)
    Main PID: 720 (ntpd)
    CGroup: /system.slice/ntpd.service
    `-720 /usr/sbin/ntpd -u ntp:ntp -f /etc/ntp.conf -p /run/ntpd.pid

Mar 17 23:58:54 raspberryshake ntpd[720]: proto: precision = 1.000 usec
Mar 17 23:58:54 raspberryshake ntpd[720]: format error frequency file /etc/ntp.conf
Mar 17 23:58:54 raspberryshake ntpd[720]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Mar 17 23:58:54 raspberryshake systemd[1]: Started Network Time Service.
Mar 17 23:58:55 raspberryshake ntpd[720]: Listen and drop on 1 v6wildcard :: UDP 123
Mar 17 23:58:55 raspberryshake ntpd[720]: Listen normally on 2 lo 127.0.0.1 UDP 123
Mar 17 23:58:55 raspberryshake ntpd[720]: Listen normally on 3 eth0 192.168.1.130 UDP 123
Mar 17 23:58:55 raspberryshake ntpd[720]: Listen normally on 4 docker0 172.17.0.2 UDP 123
Mar 17 23:58:55 raspberryshake ntpd[720]: peers refreshed
Mar 17 23:58:55 raspberryshake ntpd[720]: Listening on routing socket on fd #21 for interface updates

 remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================
*backup04.cblue. 193.190.230.66 2 u 2 64 3 173.170 0.820 2.920
216.126.233.109 128.227.205.3 2 u 4 64 3 92.874 8.731 0.190
hazmester-vlan1 .INIT. 16 u - 64 0 0.000 0.000 0.000

Network Info

Stand-Alone Mode : OFF
Ethernet UP : YES
WiFi UP : NO
DNS Available : YES
Network Accessible : YES
Nameservers : 192.168.1.1

=== ifconfig =======
docker0 Link encap:Ethernet HWaddr 02:42:ba:2b:44:64
inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth0 Link encap:Ethernet HWaddr 00:0e:c6:b4:79:d5
inet addr:192.168.1.130 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1106 errors:0 dropped:0 overruns:0 frame:0
TX packets:553 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:193211 (188.6 KiB) TX bytes:64876 (63.3 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:11 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2152 (2.1 KiB) TX bytes:2152 (2.1 KiB)

===== END ========

=== /etc/network/interfaces FILE ==========

interfaces(5) file used by ifup(8) and ifdown(8)

Please note that this file is written to be used with dhcpcd

For static IP, consult /etc/dhcpcd.conf and ‘man dhcpcd.conf’

Include files from /etc/network/interfaces.d:

source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

Start wlan0 definition

allow-hotplug wlan0
iface wlan0 inet dhcp

wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
===== END ========

WiFi Info

Kernel modules loaded : NO
Enablement : OFF

Docker Info

Docker version 1.11.1, build 5604cbe

IMAGE ID CREATED AT SIZE REPOSITORY
2b5af180f111 2020-02-14 13:30:13 +0000 UTC 83.41 MB registry.gitlab.com/rshake-public/rsh-fe-config
7b20e90e6a6a 2020-02-14 13:25:56 +0000 UTC 159.5 MB registry.gitlab.com/rshake-public/rsh-data-producer
79f3943a55c6 2019-01-30 19:16:42 +0000 UTC 140.8 MB registry.gitlab.com/rshake-public/rsh-fe-config
992d3d7c940f 2017-06-10 16:40:10 +0000 UTC 144.8 MB registry.gitlab.com/rshake-public/rsh-data-consumer

CONTAINER STATUS CREATED AT

…interestingly, I notice that this station R79D5 is still visible and streaming live data visible at https://shakenet.raspberryshake.org/my-shake
and the data is similar to, yet different from my other station RF7DC which is physically sitting right next to it.

So I guess R79D5 is actually working, and yet for some reason the local web server is not enabled or not working properly (?)

hi john,

what is strange in the myshake.out log is that it is reporting to be on v0.2. this is 16 versions behind. yet, your docker images have been properly updating.

can you send along some additional log files:

  1. postboot.log
  2. postboot.log.old
  3. upgrade.log

which might tell me what could be going on.

thanks in advance,

richard

I will try to attach the requested logs as a zip file here.
logs.zip (15.8 KB)

Also, if it means anything:

myshake@raspberryshake:/opt/log $ systemctl status rsh-fe-config.service
● rsh-fe-config.service - FE Config Service
Loaded: loaded (/lib/systemd/system/rsh-fe-config.service; disabled)
Active: failed (Result: exit-code) since Wed 2020-03-18 00:10:14 UTC; 17h ago
Process: 761 ExecStart=/usr/local/bin/./rsh-fe-config.start.sh (code=exited, status=203/EXEC)
Main PID: 761 (code=exited, status=203/EXEC)

Great to hear from you again @jbeale!

branden

hi john,

thanks for the log files, they were illuminating. it seems there’s a syntax error in the update script that is failing for your unit that i will need to look into further.

i will get back to you.

in the meantime, i wonder if it would be too much trouble for you to re-burn your SD card with the latest image and see if that doesn’t fix this problem. it’s entirely possible that the syntax error is caused by a file that has become corrupt, where the new image will fix this. instructions to burn the image can be found here.

richard

Thanks Richard. If there is any possibility for me to fix this remotely via ssh, that would be preferred. It would take some effort for me to physically reach the device at this point.

hi john,

would there be any way i could get access to this myself. it’s not entirely clear to me what could be going on from the logs, but if were able to get on, i could probably get the situation fixed.

zerotier works well, we have found.

thanks in advance,

richard