revise snmpd service & missing pid / lock - start/stop when upgrading

[maverick3005]

i noted one missing thing:

when snmpd is running and checking:

/tmp/var/lock # ls -l

-rw-rw-rw-    1 root     root             4 Jan  1 01:00 action
-rw-------    1 root     root             0 Jan  1 01:00 cron.lock
-rw-------    1 root     root             0 Jan  1 01:00 firewall.lock
-rw-------    1 root     root             0 Jan  1 01:00 restrictions.lock
-rw-r--r--    1 root     root             0 Jan  1 01:00 usb.lock

There is no lock file for the running snmpd daemon.

when checking this:

/tmp/var/run # ls -l

-rw-r--r--    1 root     root             4 Jan  1 01:00 crond.pid
-rw-r--r--    1 nobody   nobody           4 Jan  1 01:00 dnsmasq.pid
-rw-r--r--    1 root     root             4 Jan  1 01:00 dropbear.pid
-rw-r--r--    1 root     root             3 Jan  1 01:00 httpd.pid
-rw-r--r--    1 root     root             4 Jan  1 01:17 ntpd.pid

The same here, with no exiting .pid file - which can be used to kill the running daemon.

Because of the previous existing reboot/spi-flash problems, i checked the services.c and upgrade.c code, which was suggested
by pedro0311 and when all processes are stopped before flashing, i have not found an snmpd stop. Or i have overseen something ?

It would be nice to still use lock/pid file for this daemon, too. As it is used in the regulary full linuxes.

• This way the snmpd can be easier killed by exact pid/and running via lock-file checking is anyway an option.
  So actualy it looks like snmpd is closed by an "killall" equivalent. The snmpd make-process so basicly just needs
  two fixed file-locations for .pid and .lock where exactly this should be located.

TODO:

when check this:

-rwxr-xr-x 1 root root 573608 Nov 6 2025 snmpd

and the actual build config (and included other libs for the daemon...) there is a little more room to optimize/compress
more. (eventually UPX compressed compared with the LZMA Filesystem-compression?)

There are many 4 MB devices, which actualy miss 100KB near the 3,8MB max. filesize to have the chance to include IPV6 and SNMP
by excluding many other things, which the smaller devices are often not needed. (special minimal image option).

I will take a look, what we really don´t need to be included as "mib-options" - which anyway are don´t give useful answers.
snmp v3 is generally not supported actually and need a bigger working crypto-support included. ipv6 Options are only usefull, when
finaly snmp v6 usage is implemented.

Hint:
There is an old "light" alternative for a minimal snmpd: "minisnmp" from OpenWRT (outdated), it is not really active maintained
any longer and need some later patches: https://dev.archive.openwrt.org/ticket/13597
So it´s still useful with the 64Bit-interface counter patch.

It only support the basic options. Deviceinfo, Interface walk and the stats counter from all interfaces.
The negative side here is only when it comes to reconfigurations and on-the fly-reloads (WAN up/down, as example) that
the interface order got changed. I can remember that the order is only "stable" after an cold boot and "wan-up".
When pppoe and others comes in the game, i know from the past that a "newly created" interface (i.e. a fresh PPPoe Session")
is added to the end of the list and the original order moves down - so it´s not longer useful, unless a specific known interface
is directly called with the exact MIB-location - and not by interface number. The binary is extremly small and can be an option
for 4 MB devices to still have snmp bare basic features ?

Yes, it still make sense to use some 4MB devices as Repeaters with only L2-Support, by having a "management-Interface",
a default gateway for DNS/NTP, etc. but a standard monitoring Option should be a "must have", to centralize monitoring when
there are a lot of such devices located in a bigger object ;-)