Procd fails to start process for firmware built this month

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

I would imagine that you've checked the obvious: that there's still a symlink in /etc/rc.d pointing to ../init.d/smlanstatus, right?

Yes I have. And that manually invoking the startup script produces the same result i.e. no process is started.

FYI, this has been fixed by doing our firmware build with OpenWrt 18.06.7.
I don't know what changed in OpenWrt 18.06 after that release to cause our problem, but I'm happy to leave it on 18.06.7 for now.