Bug#484526: nfdump: 0 (zero) is a valid shm id
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.
Jorik
Bug#484526: nfdump: 0 (zero) is a valid shm id
Hi,
On Jun 04 18:55, Christoph Biedl wrote:
Package: nfdump
Version: 1.5.7-2
Severity: normal
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:
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.
i had the same problem and the suggested fix works for me as well.
I wonder if the severity isn't too low because the failing shmget
renders the package completely useless. Please consider this patch for
lenny, especially since it's so simple.
Regards,
Andreas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484526: nfdump: 0 (zero) is a valid shm id
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
keyshmid owner perms bytes nattch status
0x082e0009 0 root 60064 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
