Daemon service doesn't autostart after upgrading firmware via OpenWISP

I made custom package with daemon service:

#!/bin/sh /etc/rc.common
exec >> /root/log 2>&1
echo "STARTED non-lora-aggregator"
set -x


start_service() {
    procd_set_param command $PROG
    procd_set_param stdout 1
    procd_set_param stderr 1

and included it in final firmware.

After command sysupgrade -v my-firmware.bin my daemon service non-lora-aggregator autostarts and works OK.

But when I upgrade my OpenWRT device with the same my-firmware.bin via OpenWISP my daemon service non-lora-aggregator doesn't start. By the way, after sending command reboot to my device via the same OpenWISP-controller my daemon starts after rebooting the device.

My expectations: all daemon services should autostart despite how I do firmware upgrading via sysupgrade -v my-firmware.bin or OpenWISP-controller

Why it happens? Please, help me to fix it :slight_smile:

Hi @sergorl,

what happens if you flash the firmware manually with: sysupgrade -c -v <path>?

That's what the Firmware Upgrade module of OpenWISP does:

@nemesis, very strange: after sysupgrade -c -v <path-to-firmware> deamon service doesn't autostart, but after sysupgrade -v <path-to-firmware> daemon autostarts.

@sergorl -c attempts at preserving the configurations in /etc/, so there may be something in this matter that doesn't play well with your package.
How do you install your package on OpenWrt?

Is it precompiled in your image or you compile it separately, upload it on the system and install it with opkg?

@nemesis , my friend, thanks for assistance. I built my firmware from zero with included custom packages (packages were building during firmware building) and their init scripts for daemon services. Then I upload final firmware with included custom packages on my device and do sysupgrade. Sources of OpenWRT I took from here: https://gitlab.com/fmlr/picogwcard/openwrt

@nemesis , here is my Makefile for custom package:

include $(TOPDIR)/rules.mk

# Name, version and release number
# The name and version of your package are used to define the variable to point to the build directory of your package: $(PKG_BUILD_DIR)

# Source settings (i.e. where to find the source codes)
# This is a custom variable, used below

include $(INCLUDE_DIR)/package.mk

# Package definition; instructs on how and where our package will appear in the overall configuration menu ('make menuconfig')
define Package/non-lora-aggregator
	TITLE:=non-lora-aggregator for BT, WiFi, ZigBee!

# Package description; a more verbose description on what our package does
define Package/non-lora-aggregator/description
	A simple "non-lora-aggregator for BT, WiFi, ZigBee" -application.

# Package preparation instructions; create the build directory and copy the source code. 
# The last command is necessary to ensure our preparation instructions remain compatible with the patching system.
define Build/Prepare
	mkdir -p $(PKG_BUILD_DIR)

# Package build instructions; invoke the target-specific compiler to first compile the source file, and then to link the file into the final executable
define Build/Compile
	#CC=/home/repositories/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-8.4.0_musl/bin/mipsel-openwrt-linux-musl-gcc \
	cargo build --target=mipsel-unknown-linux-musl --verbose --release --manifest-path $(PKG_BUILD_DIR)/Cargo.toml

# Package install instructions; create a directory inside the package to hold our executable, and then copy the executable we built previously into the folder
define Package/non-lora-aggregator/install
	$(INSTALL_DIR) $(1)/usr/bin
	$(INSTALL_DIR) $(1)/etc/init.d
	$(INSTALL_BIN) ./files/non_lora_aggregator $(1)/etc/init.d/non_lora_aggregator
	$(INSTALL_BIN) ./files/non_lora_aggregator2 $(1)/etc/init.d/non_lora_aggregator2
	$(INSTALL_BIN) $(PKG_BUILD_DIR)/target/mipsel-unknown-linux-musl/release/non-lora-aggregator $(1)/usr/bin

# This command is always the last, it uses the definitions and variables we give above in order to get the job done
$(eval $(call BuildPackage,non-lora-aggregator))

I have no idea what's going on there, but in case you can't find the reason for this weird behavior you could use, as a last resort, a custom firmware upgrader class in openwisp which uses sysupgrade -v instead of sysupgrade -c.