I have several devices of identical type, running same custom image.
This image runs rc.local to modify quite a few system settings.
And I have the effect, that rc.local sometimes is executed twice, on different devices.
Any idea for the reason ?
A (watchdog-) timer in the "Black Magic" of procd, may be, as I also
wait for web connection up within this cript, which might take some time ?
Any doubleposting around?
Hard to say anything as you have not provided any details.
What are you doing with rc.local?
Rc.local is more meant for launching things than modifying settings.
One-time changes might be better done with uci-defaults scripts.
Rc.local runs at every boot, so it is not ideal for modifying settings.
So it is hard to say, whether any watchdog timer in procd or not, which might watch execution time of rc.local. That is my knowledge about procd, too. Thank you very much for confirmation.
No watchdog timer in procd observes the execution time of rc.local, in fact procd does not even know about /etc/rc.local. That file is usually executed by /etc/init.d/done which runs after the JFFS2 formatting / mounting has been completed.
As /etc/init.d/boot is neither procd-enabled nor launches any daemon, there are no execution time constraints imposed and no respawn handling is done.
To rule out any obvious errors (e.g. init script duplication), can you run grep -lr rc.local /etc/init.d/ ? It should only display /etc/init.d/done. Also can you elaborate a bit more on the changes you did in your custom image?
To be more specific, do you ship any custom init scripts, do you restore files during boot, do you delete files or otherwise alter the start sequence? Is any background starting (... & or start-stop-daemon) of files involved?
Do the duplicate rc.local invocations happen with every boot or only initially? Could you maybe modify the rc.local file to write the output of ps ww into the syslog or a temporary file?
Yes. The effect of running rc.local twice happens sometimes in following scenario:
#system is up and running
tar -cz -f /tmp/keep.tar.gz /etc/auto_fw_upgrade
sysupgrade -v -n -f /tmp/keep.tar.gz /tmp/mycustomfw.bin
#system reboots
#within rc.local:
....
if [ -e /etc/auto_fw_upgrade ]; then
....
#I.e. sometimes this is done twice (besides other settings)
echo "*/5 * * * * /etc/script.sh" >> /etc/crontabs/root
rm /etc/auto_fw_upgrade
sync
reboot
Theoretically, in case after reboot, the file /etc/auto_fw_upgrade is created after running/starting rc.local, I could have the effect of its execution twice.
But this seems very unlikely to me.
My original suspicion was, that some timer hits in procd, because in rc.local I also wait for network fully functioning, incl. DNS. But according to your info, this can not be the reason.
You might try sleeping a few seconds before that programmatic reboot. Just to make sure that your changes (including the rm) have got to the flash. (Not quite sure if sync is 100% reliable)
Thanx, I will try. Frankly speaking, in case it works, I call it "Mother of all Bugs":
Asynchroneous "sync" would be pathetic.