snmpd stop on host stops snmpd on LXD containers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
net-snmp (Ubuntu) |
Fix Released
|
Medium
|
Arno van Huyssteen | ||
Xenial |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[Impact]
* Stopping snmpd in Xenial can stop container processes of the same
binary
* Fix by matching to the PIDFILE that is already tracked by snmpd
[Test Case]
* Set up a host (e.g. a VM being Xenial)
* Set up at least one (or more) containers in it
* Install and start snmpd in the Host
* Install and start snmpd in the containers
* you'll now see like:
root@
29382 ? S 0:00 \_ /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp
29308 ? S 0:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp
# One of these is from the container
* now on the host stop your service, chances are you stop your guests instead
root@
root@
29426 pts/0 S+ 0:00 \_ grep --color=auto snmp
# 29382 was from a lxd container in this case
[Regression Potential]
* In case the pidfile stored by the snmpd daemon would be incorrect then
the stop/restart actions would not match the process and fail to
stop/restart. We didn't see that in our tests, but that is the
regression I could think of.
[Other Info]
* n/a
----
If you have ubuntu 16.04 containers running snmpd and you stop the snmpd on the LXD host system, it will also shut down all the snmpd instances on the containers (but will not restart them if you restart them on the LXD host) .. in fact, you even need to go back into the container, stop the snmpd before you can start it again.
See log below, viepovzat17 is the LXD host, viezmaaat10 is the ubuntu container:
driver: lxc
driver_version: 2.0.8
kernel: Linux
kernel_
kernel_version: 4.4.0-87-generic
server: lxd
server_pid: 4426
server_version: "2.16"
storage: zfs
storage_version: 0.6.5.6-0ubuntu16
root@viezmaaat10:~# /etc/init.d/snmpd start
[ ok ] Starting snmpd (via systemctl): snmpd.service.
root@viezmaaat10:~# ps -eaf | grep snmp
snmp 1271 1 0 10:50 ? 00:00:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid
root 1291 757 0 10:50 ? 00:00:00 grep --color=auto snmp
root@viezmaaat10:~#
root@viezmaaat10:~# ps -eaf | grep snmp
snmp 1271 1 0 10:50 ? 00:00:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid
root 1293 757 0 10:50 ? 00:00:00 grep --color=auto snmp
root@viezmaaat10:~# exit
root@viepovzat17:~# ps -eaf | grep snmp
snmp 22757 1 0 10:45 ? 00:00:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid
100116 24118 5222 0 10:50 ? 00:00:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -g snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid
root 24153 21842 0 10:50 pts/1 00:00:00 grep --color=auto snmp
root@viepovzat17:~# /etc/init.d/snmpd stop
[ ok ] Stopping snmpd (via systemctl): snmpd.service.
root@viepovzat17:~# ps -eaf | grep snmp
root 24286 21842 0 10:50 pts/1 00:00:00 grep --color=auto snmp
root@viepovzat17:~#
description: | updated |
tags: | added: cpe-onsite |
Changed in net-snmp (Ubuntu): | |
assignee: | nobody → Ante Karamatić (ivoks) |
Changed in net-snmp (Ubuntu): | |
assignee: | Ante Karamatić (ivoks) → Arno van Huyssteen (avanhuys) |
importance: | Undecided → Medium |
status: | New → Confirmed |
This is a bug in the snmpd init script, moving bug over there.