Unexpected scripted service behavior (at least from my perspective)

I am having a problem with a fairly straight forward procd service that runs a daemon from a binary which in turn creates a virtual adapter to access an onion network. Works perfectly fine on reboot and works perfectly fine starting and stopping the daemon from the GUI or through console. Doesn't work when initially powering up on an Orange Pi R1 Plus unless I manually restart the service.

I've tried to delay the start to 99 and monitored the system process to ensure it's running but when powering up it seems there's possibly a race condition. The daemon "runs" in all instances but fails to connect. Reboot will fix it and manual service restarting does as well. What's really odd is attempting to delay it or restart using rc.local with the exact same commands to troubleshoot the problem hasn't the same effect. I've even added long sleep states between these scripted service restarts to see what was going on and still it doesn't connect the same way manually entering the exact same commands do even though I can see it being carried out in the system process in real time.

Any input on what additionally may or may be happening between rc.local and me personally entering the exact same commands would be helpful.

Try to add a script to the wan up event... and add there a sleep or a while until successfull ping or something like that.

So a hotplug event based on WAN being up? Like restarting the service? I'm not sure what is so considerably different between reboot and power that power up has an issue. I'd expect both cases to experience the same issue.

probably it is failing because interfaces are not available at the time, or its receives a timeout trying to connect.
the convenient way to do what you want is a hotplug event wan up and double check against using a ping to known ip like or something like that.

It's actually connection to the virtual adapter that's the problem but I was thinking if it could start coinciding with a later event, much longer than simply Start=99 provides. I suspect it could be that WAN isn't up when required or it may even be a hardware kernel panic during system boot. I really don't know from logs. The daemon itself doesn't fail or procd would restart it automatically and sort the problem out the same way manual restart or a reboot does. What's even more odd is the same package build for an x86_64 system doesn't experience the problem so I suspect it's problems in the hardware itself initializing during initial power up.

yes it could be, please try to post your steps on configuration to get a better glance of what could be the problem.

I believe that Jo said a while ago that START values above 90 are meaningless.

Regarding your specific issue, you may want to add the boot() function to the init script which will wait until all network connections are established before attempting to start the binary.

You can check adblock, simple-adblock and vpn-policy-routing init scripts for examples of boot() with the former two being probably closer to what you need to do.

Thanks I will look for those examples to appreciate how that's being applied.

boot() { ubus -t 30 wait_for network.interface && rc_procd start_service || output 'ERROR: Failed to settle network interface!\n'; }

If understand this is to wait 30 seconds for network.interface then call the start_service on boot.