Your message dated Wed, 4 Feb 2009 15:16:52 +0100
with message-id <[email protected]>
and subject line Re: Bug#484526: nfdump: 0 (zero) is a valid shm id
has caused the Debian Bug report #484526,
regarding nfdump: 0 (zero) is a valid shm id
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
484526: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484526
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: nfdump
Version: 1.5.7-2
Severity: normal
Hi,
I noticed nfcapd did not restart after a config change. After a long
search the reason was found at bookkeeper.c:160:
158 shm_id = shmget(shm_key, sizeof(bookkeeper_t), 0600);
159
160 if ( shm_id > 0 ) {
161 // the segment already exists. Either a running process
is active
162 // or an unclean shutdown happened
As described in the shmget manpage, a value of -1 indicates an error
situation, therefore 0 should be treated as a valid id. This actually
happened on system but don't ask me how I did this:
# ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x082e0009 0 root 600 64 0
(...)
The current code not only prevented nfcapd from running but also gave a
completely misleading error message later since errno was not changed by
the successful (from glibc's point of view) shmget call.
The easy fix
160 if ( shm_id >= 0 ) {
works for me.
Christoph
--- End Message ---
--- Begin Message ---
Am 19.12.2008 um 11:11 schrieb Jorik Jonker:
Hi all,
It appears to me that 0 indeed is a valid shm key, but it is only
returned when the daemon tries to reconnect to an existing segment,
for instance if the daemon did not close properly. The daemon
started perfectly every "first time" I ran it, but every subsequent
launch it failed. ipcs learned that the daemon left its segment
after getting a 9 from start-stop-daemon.
My "fix" was the following patch to debian/init.d:
DAEMON=/usr/bin/$NAME
DATA_BASE_DIR="/var/cache/nfdump"
-DAEMON_ARGS="-D -l $DATA_BASE_DIR"
PIDFILE=/var/run/$NAME.pid
+DAEMON_ARGS="-D -l $DATA_BASE_DIR -P ${PIDFILE}"
SCRIPTNAME=/etc/init.d/$NAME
Start-stop-daemon is now able to give a 15 on 'stop', which results
in nfcapd to release its segments and properly launch each
subsequent time.
added pidfile option to daemon args
Thanks: Jorik Jonker <[email protected]> Remco Post <[email protected]
>
Erik Wenzel
[email protected]
--- End Message ---
