OpenWrt 18.06.4 empties rc.local ? possible broken interaction with snmpd?

For Developers
1

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.

2

I restarted the snmpd on 18.06.4 on Carambola2 and rc.local remained the same.
Have you tried to reinstall snmpd?

3

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.

4

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.

5

issue resolution, did not find its way into 18.06.04?

1 Like
6

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.

7

Exactly, there is by default a remark line and then the exit 0.

It vanish when you restart snmpd!

8

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 ...

9

As Luci issue #2760 states, this happened / happens with other buttons on the startup page, too. so this seems not to be related to snmpd.

1 Like
10

So I guess I need to move to snapshot ...

11

Understood is not snmpd, is any restart ... I only restarted that one, so that was the cause in my case!

12

At least I got lucky, the backups had the older valid version.
Thanks for catching this and saving me a ton of head scratching :slight_smile:

13

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" ...

1 Like
14
  • Do you have the erasing issue if you run /etc/init.d/snmpd restart on the command line?
  • Is there a reason that you interfaces go down all the time? It's not really clear in the thread.

I ask the second question because of a bootup issue I'm intermittently having with snmpd on [some] snapshots.

15

Just tested /etc/init.d/snmpd restart, no problem in this case, rc.local file keeps the contents

1 Like
16

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.

17

Hi there,

Also suffering from the same issue.
I'm wondering if OpenWRT's cron supports the @reboot directive?
It could be a workaround...

Any idea?

18

nevermind.... just tested and it doesn't work... unless there is the chance of using a different crontab binary