I've tested this with several models:
ZBT-WG3526 (16M)
TP-Link Archer C2600
GL.iNet GL-AR300M
TP-LINK Archer C7 v4
SamKnows Whitebox 8
It looks that from time to time, rc.local gets "emptied".
I'm using cacti to monitor several routers, and from time to time, if an interface is reset (link down, etc.), it looks like cacti gets confused, so I need to restart snmpd.
It looks that that creates the problem, because after that, rc.local is empty.
I've been trying to find the problem since I flashed all the routers with 18.06.4 (stable), because initially this was happening when rebooting, so I was not able to find why ... now, I'm almost sure that it is the snmpd restart which creates the problem.
I have lot of different openwrt- devices to supervise, various types of TP-Links, ZBTs etc. Never seen "emptied rc.local". However, I do not use snmpd, and only use my own custom built images, Trunk.
I'll have to check my backups to confirm but right now my rc.local is also empty... I thought I had some silly comment in there with an "exit 0" at the end, weird.
EDIT: indeed, I had customised rc.local and most likely restarted some services in the past, so now it's gone.
I'm using default firmware for all those devices, so once a new version comes, I need to reinstall all those packages anyway. So don't think that "reinstalling" will solve the problem.
The backups got rc.local empty, because snmpd was restarted somehow (even a reboot), before the backup. I had the same problem, so I needed to look into "older" backups to recover my previous rc.local ...
I've made an "rc.back" in all my routers, so I've at hand a copy of each rc.local, instead of looking for the backups, until I go for snapshots and have time to test them to ensure nothing gets broken. Not sure if I can call from any other config file (before the rc.local is called) to a "cp /etc/rc.back /etc/rc.local" so it is automatically copied after a reboot.
Alternatively I can make a crontab to do that every hour or so, but that will not ensure that it happens "across an unexpected reboot" ...
I have two devices that have the same problem after upgrading, But it has nothing to do with snmpd.
Now I have returned one of them to 18.06.2 version without any further problem.
update dynamics:
In the 18.06.2 system, the same problem occurred after the system was updated through the “opkg upgrade opkg list-upgradable|awk '{print $1}'|xargs” area.