Helicorder Stops After Saving Settings

Technical Support
1

Helicorder stops after saving settings: two addresses written into ows.conf

Station: AM.R24AE — Raspberry Shake 3D
Firmware: RS3D-5-4.3 (ODF 2020.045), rsh-fe-config v21.2
Hardware / OS: Raspberry Pi 3 Model B Plus Rev 1.3, Raspbian 9 (stretch), kernel 4.14.79-v7+, Docker 1.11.1

Summary

After saving a change on the Shake’s settings page (a small edit to latitude and longitude), the helicorder stopped drawing plates and did not recover. The data stream was unaffected: seedlink on port 18000 kept serving, and downstream clients kept receiving data. Only the helicorder GIFs in /opt/data/gifs/ stopped.

The cause is that the configuration front end wrote two IP addresses into the wave server’s seedlink host setting, which the wave server then tries to resolve as a single hostname.

What happens

  1. Saving settings makes the front end re-run its configuration (“Configuring SEEDLINK… Configuring OWS… Configuring HELI… Starting R-SHAKE Data Containers” in rsh-fe-hst.log). On this unit that was at 2026-09-18 02:57:04 UTC.

  2. It writes the docker bridge address to /opt/settings/sys/d-ip.txt and substitutes it for %DOCKERIP% in /opt/settings/dataC/tpl/ows.conf.tpl.

  3. On this unit docker0 carries two IPv4 addresses, so d-ip.txt contains both on one line:

    172.17.0.2 169.254.156.50

    and the generated /opt/settings/dataC/ows.conf reads:

    sources = (
    {
        type = "seedlink";
        host = "172.17.0.2 169.254.156.50";
        port = 18000;
    },

  4. ows cannot resolve that string, so it receives no data. heli_ewII then segfaults, and the container’s watchdog in rsh-data-consumer.start.sh restarts both programs every two and a half minutes, indefinitely. From /opt/log/rsh-data-consumer.log:

    2026-09-18 13:53:20 S.T. [ERROR] libslinkmm: cannot resolve hostname 172.17.0.2 169.254.156.50
/opt/bin/rsh-data-consumer.start.sh: line 72:  6720 Segmentation fault      (core dumped) $HELIPGM /opt/settings/dataC/heli_ewII.d
2026 261 13:54:50: Program heli_ewII is not running, restarting programs...

    This ran for eleven hours before it was noticed. The plates for that period were never drawn.

Where the second address comes from

The second address is a link-local (169.254/16) address that dhcpcd assigned to docker0. It also assigned one to each veth interface:

docker0      172.17.0.2/16
docker0      169.254.156.50/16
veth85bcaab  169.254.1.243/16
veth8a458ee  169.254.143.131/16
veth6bf63fa  169.254.125.185/16

/etc/dhcpcd.conf as shipped has denyinterfaces wlan0 only, so dhcpcd manages the docker bridge and the veth interfaces and gives each an IPv4LL address when no DHCP server answers on them, which none ever will.

The fault is latent. The unit had been up 176 days with the extra address present, and nothing was wrong, because the containers had been configured before the address appeared. The front end’s log shows the configuration had been re-run only once before on this unit, in February 2022. Any settings save or reboot would have exposed it.

Expected behavior

Saving settings should leave the helicorder running. The seedlink host written into ows.conf should be a single address.

Workaround

Correct the one value by hand and let the watchdog restart the programs. No restart or reboot is needed, and /opt/settings/dataC/ows.conf is owned by myshake:

cd /opt/settings/dataC
cp -p ows.conf ows.conf.bak
sed -i 's|host = "172.17.0.2 169.254.156.50";|host = "172.17.0.2";|' ows.conf

ows and heli_ewII came up on the watchdog’s next pass and plotting resumed. The workaround does not survive the next settings save or reboot, since ows.conf is regenerated from the template.

Suggested fixes

Any one of these would prevent it; the first two together would be most robust.

  1. Take one address when writing d-ip.txt. Whatever collects docker0’s address should select the first global-scope address in docker’s own subnet, not every inet line on the interface.
  2. Ship /etc/dhcpcd.conf with denyinterfaces wlan0 docker0 veth*, so dhcpcd never manages docker’s interfaces and the link-local addresses are never assigned.
  3. Have ows and heli_ewII fail loudly. A seedlink host that cannot be resolved currently produces an error every 30 seconds in a log inside a container and a silent restart loop. Nothing on the Shake’s web interface showed that the helicorder had stopped.

Reproduction

I have not tried to reproduce this on a second unit. On this unit it should reproduce on any settings save, since docker0 still carries both addresses. The precondition to look for on another unit is ip -4 -o addr show docker0 listing more than one address.

1 Like
2

hello jkline,

thanks for the report. this is a known issue that was previously reported and has been fixed in the code base. version V22 will be released in the next couple of weeks and will contain the modification addressing this problem.

thanks again,
richard

1 Like