FS#32258 - [net-snmp] problem with systemd unit file

Attached to Project: Arch Linux
Opened by Chieh Yu (Jack_Yu) - Sunday, 28 October 2012, 04:31 GMT
Last edited by Eric Belanger (Snowman) - Sunday, 14 April 2013, 04:22 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

I install net-snmp 5.7.2-1 by pacman, and I find out snmpd can't be started using systemctl.

both these command are OK
#systemctl enable snmpd
#systemctl start snmpd

but the status is inactive (dead)
#systemctl status snmpd
snmpd.service - Simple Network Management Protocol (SNMP) Daemon
Loaded: loaded (/usr/lib/systemd/system/snmpd.service; enabled)
Active: inactive (dead) since Sun, 28 Oct 2012 11:54:40 +0800; 5min ago
Process: 842 ExecStart=/usr/sbin/snmpd (code=exited, status=0/SUCCESS)
Main PID: 843 (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/snmpd.service

After manually run /usr/sbin/snmpd, it run as daemon and return immediately and works fine.
I think this is caused by snmpd.service file, so I change it as below, and this problem is solved.

[Service]
Type=forking
PIDFile=/var/run/snmpd.pid
ExecStart=/usr/sbin/snmpd -p /var/run/snmpd.pid
ExecReload=/bin/kill -HUP $MAINPID

#systemctl status snmpd
snmpd.service - Simple Network Management Protocol (SNMP) Daemon
Loaded: loaded (/usr/lib/systemd/system/snmpd.service; enabled)
Active: active (running) since Sun, 28 Oct 2012 11:46:43 +0800; 19min ago
Process: 1365 ExecStart=/usr/sbin/snmpd -p /var/run/snmpd.pid (code=exited, status=0/SUCCESS)
Main PID: 1367 (snmpd)
CGroup: name=systemd:/system/snmpd.service
└ 1367 /usr/sbin/snmpd -p /var/run/snmpd.pid

Not sure this solution is right or not, but I hope this will help you guys to solve it.

thanks.



This task depends upon

Closed by  Eric Belanger (Snowman)
Sunday, 14 April 2013, 04:22 GMT
Reason for closing:  Fixed
Additional comments about closing:  in net-snmp-5.7.2-4
Set PIDFile in snmpd.service
Comment by Eric Belanger (Snowman) - Sunday, 28 October 2012, 21:24 GMT
I can't reproduce the problem. Works fine here:

$ sudo systemctl start snmpd
$ sudo systemctl status snmpd
snmpd.service - Simple Network Management Protocol (SNMP) Daemon
Loaded: loaded (/usr/lib/systemd/system/snmpd.service; disabled)
Active: active (running) since Sun, 2012-10-28 16:55:33 EDT; 7s ago
Process: 1684 ExecStart=/usr/sbin/snmpd (code=exited, status=0/SUCCESS)
Main PID: 1686 (snmpd)
CGroup: name=systemd:/system/snmpd.service
└ 1686 /usr/sbin/snmpd

Oct 28 16:55:32 ovide systemd[1]: Starting Simple Network Management Protocol (SNMP) Daemon...
Oct 28 16:55:33 ovide systemd[1]: Started Simple Network Management Protocol (SNMP) Daemon.
Comment by Michael Brown (mwbrown) - Wednesday, 21 November 2012, 04:14 GMT
I can confirm that this problem occurs on the i686 architecture as well. Systemd reports that the service is running, but running "pgrep snmpd" shows there are no running instances of the daemon.

Additionally, implementing the two lines in the unit file:

PIDFile=/var/run/snmpd.pid
ExecStart=/usr/sbin/snmpd -p /var/run/snmpd.pid

This fixes the issue.
Comment by ... (spider007) - Wednesday, 05 December 2012, 14:54 GMT
I can confirm this problem. I have a very simple /etc/snmp/snmpd.conf:

rocommunity public

sysLocation Stuff
sysContact stuff@example.com

disk / 10%
load 4 3 2

Manually starting works, but starting with systemd it just won't work. The fix by mwbrown works for me too
Comment by George Borrmann (ghborrmann) - Saturday, 12 January 2013, 17:53 GMT
I too have encountered this problem. The fix suggested by mwbrown (adding the line PIDFile=/var/run/snmpd.pid and adding the -p option to the ExecStart line) did not work for me. systemctl status snmpd reported failure of the start command. (Without the fix, the reported status was inactive and it showed the snmpd command as exited with exit code 0.) However, I found that these changes plus adding the -U option (don't remove pid file on exit) did the trick.

I don't know how important it is to track down the cause of this bug, but I'm giving some further information in the hope that it will be useful.

The computer I'm using is an older one with a Pentium III 800MHz processor. (I also installed ArchLinux on my laptop with a core i7 processor, but had no problems there.) The problem for me was intermittent. Most of the time the start command ( or enable followed by a reboot) would generate no errors but systemctl status snmpd would report inactive. Occasionally the start command would work: the status was reported as running and the daemon would function normally. This most often happened after a reboot following an overnight shutdown. If the daemon was running, the systemctl stop command would stop it successfully, but then the start command would be invariably be ineffective at least until the next reboot. The only way I found to reliably start the daemon was to remove the net-snmpd package using pacman, reboot, and install that package again.
Comment by ... (spider007) - Tuesday, 19 March 2013, 13:32 GMT
After the latest package-update I need to update ~ 50 service files since that resets the fix. This problem might be related to systemd-ask-password; because this is in my `strace systemctl start snmp`:

[pid 24224] 0.000227 stat("/run/systemd/ask-password-block", {st_mode=S_IFDIR|0700, st_size=80, ...}) = 0
[pid 24224] 0.000137 mknod("/run/systemd/ask-password-block/136:1", S_IFIFO|0600) = -1 EEXIST (File exists)
[pid 24224] 0.000178 open("/run/systemd/ask-password-block/136:1", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_CLOEXEC) = 3
[pid 24224] 0.000130 stat("/run/systemd", {st_mode=S_IFDIR|0755, st_size=280, ...}) = 0
[pid 24224] 0.000109 mkdir("/run/systemd/ask-password", 0755) = -1 EEXIST (File exists)
[pid 24224] 0.000128 stat("/run/systemd/ask-password", {st_mode=S_IFDIR|0755, st_size=40, ...}) = 0
[pid 24224] 0.000147 inotify_init1(IN_CLOEXEC) = 4
[pid 24224] 0.000097 inotify_add_watch(4, "/run/systemd/ask-password", IN_CLOSE_WRITE|IN_MOVED_TO) = 1
[pid 24224] 0.000126 rt_sigprocmask(SIG_SETMASK, [INT TERM], NULL, 8) = 0
[pid 24224] 0.000120 signalfd4(-1, [INT TERM], 8, O_NONBLOCK|O_CLOEXEC) = 5
[pid 24224] 0.000187 openat(AT_FDCWD, "/run/systemd/ask-password", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
[pid 24224] 0.000148 getdents(6, /* 2 entries */, 32768) = 48
[pid 24224] 0.000140 getdents(6, /* 0 entries */, 32768) = 0
[pid 24224] 0.000125 close(6) = 0
[pid 24224] 0.000133 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}], 2, 4294967295 <unfinished ...>
[pid 24223] 0.000810 <... poll resumed> ) = 1 ([{fd=3, revents=POLLIN}])
[pid 24223] 0.000108 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\4\1\1>\0\0\0\2\0\0\0\213\0\0\0\1\1o\0\31\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 305
[pid 24223] 0.000232 recvmsg(3, 0x7fff8e64ac70, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
[pid 24223] 0.000244 sendmsg(3, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\0019\0\0\0\3\0\0\0\240\0\0\0\1\1o\0.\0\0\0/org/fre"..., 176}, {"\35\0\0\0org.freedesktop.systemd1.Uni"..., 57}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 233
[pid 24223] 0.000326 clock_gettime(CLOCK_MONOTONIC, {80142, 164522164}) = 0
[pid 24223] 0.000176 poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])
[pid 24223] 0.000184 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\10\0\0\0\4\0\0\0\17\0\0\0\5\1u\0\3\0\0\0\10\1g\0\1v\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 40
[pid 24223] 0.000218 recvmsg(3, 0x7fff8e64ac70, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
[pid 24223] 0.000237 poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])
[pid 24223] 0.046569 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\4\1\1I\0\0\0\5\0\0\0\223\0\0\0\1\1o\0\31\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 241
[pid 24223] 0.000224 recvmsg(3, 0x7fff8e64b010, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
[pid 24223] 0.000241 close(3) = 0
[pid 24223] 0.000264 kill(24224, SIGTERM <unfinished ...>
[pid 24224] 0.000122 <... poll resumed> ) = 1 ([{fd=5, revents=POLLIN}])
[pid 24224] 0.000119 close(4) = 0
[pid 24224] 0.000145 close(5) = 0
[pid 24224] 0.000144 close(3) = 0
[pid 24224] 0.000161 exit_group(0) = ?
[pid 24224] 0.000334 +++ exited with 0 +++

systemctl status says:
snmpd.service - Simple Network Management Protocol (SNMP) Daemon
Loaded: loaded (/usr/lib/systemd/system/snmpd.service; enabled)
Active: inactive (dead) since Tue 2013-03-19 14:19:58 CET; 3min 8s ago
Process: 24225 ExecStart=/usr/sbin/snmpd (code=exited, status=0/SUCCESS)
Main PID: 24226 (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/snmpd.service

After removing 2 files from /run/systemd/ask-password-block/ snmpd actually starts! How can I debug this further?
Comment by Eric Webb (webmonarch) - Sunday, 07 April 2013, 06:44 GMT
FYI, after some investigating, updating /etc/conf.d/snmpd as follows fixed it for me:

cat /etc/conf.d/snmpd
#
# Parameters to be passed to snmpd
#
SNMPD_ARGS="-p /var/run/snmpd.pid"

My take is systemd cannot determine the PID of the forked snmpd so it kills it.
Comment by ... (spider007) - Sunday, 07 April 2013, 10:53 GMT
@webmonarch; unfortunately the fix you found is nothing new and already described in this issue. However, it is still unknown why some people are experiencing this problem; and other aren't. It seems like a possible bug in systemd to me
Comment by Eric Belanger (Snowman) - Saturday, 13 April 2013, 08:58 GMT
if you use these changes, does it work?


[Service]
Type=notify
ExecStart=/usr/sbin/snmpd -f
ExecReload=/bin/kill -HUP $MAINPID
Comment by Eric Belanger (Snowman) - Saturday, 13 April 2013, 22:35 GMT
Nevermind my last suggestion. It doesn't work. It just hangs.

Loading...