The query result is inconsistent in SNMP

[kaiyu22]

Description
There is a phenomenon that query result is inconsistent between snmpd process first start (after booting) and service restart. We can input command 'ps aux' under docker snmp and check snmpd process and its parameters.

In first start:
Debian-+ 29 0.0 0.1 52156 8644 ? S Nov08 0:07 /usr/sbin/snmpd -f -LS4d -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf ifTable ifXTable inetCidrRouteTable ipCidrRouteTa

Service restart:
Debian-+ 52 0.0 0.0 52016 5544 ? S 03:41 0:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid

In first start, we can query some OIDs and get the response as below.
(take ifTable for example)

root@sonic:/# snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.2.2
iso.3.6.1.2.1.2.2 = No Such Object available on this agent at this OID

These OIDs are ifTable, ifxTable, ipCidrRouteTa, disk_hw, etc.

After doing the service restart, the above OIDs all can be queried and get the value return.
(take ifTable for example)

root@sonic:/# snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.2.2
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.1.2 = INTEGER: 2
... (skip)

Is this what MSFT expected?

Steps to reproduce the issue:

1. docker exec -it snmp bash
2. snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.2.2
3. service snmpd restart
4. snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.2.2

Describe the results you received:

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

SONiC Software Version: SONiC.SONiC-Ingrasys-v1.3.0-437419c
Distribution: Debian 8.9
Kernel: 3.16.0-4-amd64
Build commit: 437419c
Build date: Fri Oct 27 09:02:25 UTC 2017
Built by: sonic@sonic

Docker images:
REPOSITORY                TAG                             IMAGE ID            SIZE
docker-syncd-brcm         SONiC-Ingrasys-v1.3.0-437419c   cdcee25d83a4        318.3 MB
docker-syncd-brcm         latest                          cdcee25d83a4        318.3 MB
docker-orchagent-brcm     SONiC-Ingrasys-v1.3.0-437419c   fcb06af1a06d        259.1 MB
docker-orchagent-brcm     latest                          fcb06af1a06d        259.1 MB
docker-lldp-sv2           SONiC-Ingrasys-v1.3.0-437419c   71c44d8b4d46        256.5 MB
docker-lldp-sv2           latest                          71c44d8b4d46        256.5 MB
docker-dhcp-relay         SONiC-Ingrasys-v1.3.0-437419c   c5ea6ae37ceb        253.5 MB
docker-dhcp-relay         latest                          c5ea6ae37ceb        253.5 MB
docker-database           SONiC-Ingrasys-v1.3.0-437419c   e38cab48359e        251.7 MB
docker-database           latest                          e38cab48359e        251.7 MB
docker-snmp-sv2           SONiC-Ingrasys-v1.3.0-437419c   97e0ae330326        291.3 MB
docker-snmp-sv2           latest                          97e0ae330326        291.3 MB
docker-teamd              SONiC-Ingrasys-v1.3.0-437419c   44ef14751dc7        256.1 MB
docker-teamd              latest                          44ef14751dc7        256.1 MB
docker-platform-monitor   SONiC-Ingrasys-v1.3.0-437419c   af75bbc58bf1        271 MB
docker-platform-monitor   latest                          af75bbc58bf1        271 MB
docker-fpm-quagga         SONiC-Ingrasys-v1.3.0-437419c   3b724be6ed5f        262.7 MB
docker-fpm-quagga         latest                          3b724be6ed5f        262.7 MB

[svc-acs]

we are using supervisord to manage the snmpd process inside snmp docker. Need to use supervisorctl restart snmpd to restart the snmpd process inside the docker.

[kaiyu22]

I got it, thanks for your reply.