Hi,
We use OpenWrt to power our monitoring devices which are derived from the TP-Link MR3020 line (ar71xx, 64MB RAM, 16MB Flash). Our firmware is built using OpenWrt 18.06 as the base, to which we add a few of our own programs.
All recent firmware built up to the end of February (27-Feb-2020) has worked fine.
In the last few days, while working on the next release of our software, I noticed some odd behaviour and realised it was affecting our firmware built since the beginning of March. I tracked it down to a startup script not starting a required process which runs one of our programs. The script is /etc/init.d/smlanstatus
and it's very simple:
#!/bin/sh /etc/rc.common
# Copyright (C) 2019 Suntrix Monitoring Pty Ltd
#
# smlanstatus tracks and coordinates changes to the myWatt network configuration
#
################################################################################
START=70
USE_PROCD=1
start_service () {
procd_open_instance
procd_set_param respawn 0 5 0
procd_set_param command "/usr/bin/smlanstatus"
procd_append_param command -n 5
procd_close_instance
}
Firmware built this month (March 2020) seems to fail to start the smlanstatus
process on boot.
If I log into the device and run the command
root@OpenWrt:~# /etc/init.d/smlanstatus start
the command completes without error or output of any kind, but the smlanstatus
process is not started.
SOMETIMES I have seen this error in logread
after running the command above:
procd: not starting instance smlanstatus::instance1, command not set
which makes no sense. It also makes no sense that this is the only one of our program startup scripts which is showing this problem.
Running the command smlanstatus -n 5
manually on the OpenWrt shell command line works fine.
Running smlanstatus -n5 &
also works, and the process runs in the background and does what it needs to do.
I had wondered if somewhere our OpenWrt download had become corrupted so I built new firmware from a fresh install, and got the same result.
So, is anyone aware of a change in OpenWrt which might impact the way procd
operates when starting a process? Perhaps a process quota/resource problem of some kind?
Thanks,
Jeremy Begg