--- Begin Message ---
The following issue has been CLOSED
======================================================================
http://bugs.bacula.org/view.php?id=991
======================================================================
Reported By: jgoerzen
Assigned To:
======================================================================
Project: bacula
Issue ID: 991
Category: File Daemon
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 10-18-2007 12:29 EDT
Last Modified: 10-19-2007 07:51 EDT
======================================================================
Summary: bacula-fd does not release STDOUT/STDERR on
daemonization
Description:
This bug report was received at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441621
From: Sven Hartge <[EMAIL PROTECTED]>
Package: bacula-fd
Version: 2.2.0-1
Severity: normal
After an upgrade to 2.2.0 I was not able to log out of my ssh connetion.
As lsof reveals, bacula-fd still uses the FDs from STDOUT and STDERR
causing the ssh connection to stall on logout.
ds9:/root # lsof -p 27563
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
bacula-fd 27563 root cwd DIR 9,0 4096 2 /
bacula-fd 27563 root rtd DIR 9,0 4096 2 /
bacula-fd 27563 root txt REG 253,0 316396 65681
/usr/sbin/bacula-fd
bacula-fd 27563 root mem REG 9,0 23564 94201
/lib/libacl.so.1.1.0
bacula-fd 27563 root mem REG 9,0 109655
/lib/i686/cmov/libnss_files-2.6.1.so (path inode=110353)
bacula-fd 27563 root mem REG 9,0 109639
/lib/i686/cmov/libnsl-2.6.1.so (path inode=109686)
bacula-fd 27563 root mem REG 9,0 12628 93902
/lib/libattr.so.1.1.0
bacula-fd 27563 root mem REG 9,0 109612
/lib/i686/cmov/libc-2.6.1.so (path inode=109633)
bacula-fd 27563 root mem REG 9,0 94001
/lib/libgcc_s.so.1 (path inode=94064)
bacula-fd 27563 root mem REG 9,0 109632
/lib/i686/cmov/libm-2.6.1.so (path inode=109670)
bacula-fd 27563 root mem REG 253,0 98388
/usr/lib/libstdc++.so.6.0.9 (path inode=98621)
bacula-fd 27563 root mem REG 9,0 31224 94006
/lib/libwrap.so.0.7.6
bacula-fd 27563 root mem REG 9,0 109631
/lib/i686/cmov/libdl-2.6.1.so (path inode=109669)
bacula-fd 27563 root mem REG 9,0 109846
/lib/i686/cmov/libpthread-2.6.1.so (path inode=110364)
bacula-fd 27563 root mem REG 9,0 109851
/lib/i686/cmov/librt-2.6.1.so (path inode=110367)
bacula-fd 27563 root mem REG 9,0 109854
/lib/i686/cmov/libutil-2.6.1.so (path inode=110370)
bacula-fd 27563 root mem REG 253,0 1092248 98623
/usr/lib/libpython2.4.so.1.0
bacula-fd 27563 root mem REG 253,0 80340 98394
/usr/lib/libz.so.1.2.3.3
bacula-fd 27563 root mem REG 9,0 93966 /lib/ld-2.6.1.so
(path inode=94141)
bacula-fd 27563 root 0r FIFO 0,5 4537832 pipe
bacula-fd 27563 root 1u CHR 136,5 7 /dev/pts/5
(deleted)
bacula-fd 27563 root 2u CHR 136,5 7 /dev/pts/5
(deleted)
bacula-fd 27563 root 3u IPv4 4537868 TCP
ds9.feds.ath.cx:bacula-fd (LISTEN)
bacula-fd 27563 root 4u IPv4 4537869 TCP
localhost:bacula-fd (LISTEN)
(both devices show as "deleted" because I already killed my ssh
connection with ~. before I used lsof to investigate the matter)
Here is the output of the bacula-fd_2.0.3-2 (from a backported version,
but the original version from Lenny/Sid behaved correctly as well):
[EMAIL PROTECTED]:~# lsof -p 3028
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
bacula-fd 3028 root cwd DIR 9,0 1024 2 /
bacula-fd 3028 root rtd DIR 9,0 1024 2 /
bacula-fd 3028 root txt REG 253,0 330072 81950 /usr/sbin/bacula-fd
bacula-fd 3028 root mem REG 0,0 0 [heap] (stat: No
such file or directory)
bacula-fd 3028 root mem REG 9,0 147308
/lib/libnss_files-2.3.6.so (path inode=147174)
bacula-fd 3028 root mem REG 9,0 147322
/lib/libnss_dns-2.3.6.so (path inode=147209)
bacula-fd 3028 root mem REG 9,0 147323
/lib/libresolv-2.3.6.so (path inode=147251)
bacula-fd 3028 root mem REG 9,0 147315 /lib/ld-2.3.6.so
(path inode=147201)
bacula-fd 3028 root mem REG 9,0 26088 147170
/lib/libacl.so.1.1.0
bacula-fd 3028 root mem REG 253,0 90024 131150
/usr/lib/libz.so.1.2.3
bacula-fd 3028 root mem REG 253,0 1272736 131153
/usr/lib/libpython2.4.so.1.0
bacula-fd 3028 root mem REG 9,0 147319
/lib/libutil-2.3.6.so (path inode=147199)
bacula-fd 3028 root mem REG 9,0 147312 /lib/librt-2.3.6.so
(path inode=147185)
bacula-fd 3028 root mem REG 9,0 147324
/lib/libpthread-2.3.6.so (path inode=147183)
bacula-fd 3028 root mem REG 9,0 147302 /lib/libdl-2.3.6.so
(path inode=147236)
bacula-fd 3028 root mem REG 9,0 34504 147234
/lib/libwrap.so.0.7.6
bacula-fd 3028 root mem REG 253,0 291816 131294
/usr/lib/libssl.so.0.9.8
bacula-fd 3028 root mem REG 253,0 1510344 131292
/usr/lib/libcrypto.so.0.9.8
bacula-fd 3028 root mem REG 253,0 965344 131089
/usr/lib/libstdc++.so.6.0.8
bacula-fd 3028 root mem REG 9,0 147303 /lib/libm-2.3.6.so
(path inode=147193)
bacula-fd 3028 root mem REG 9,0 52384 147188 /lib/libgcc_s.so.1
bacula-fd 3028 root mem REG 9,0 147300 /lib/libc-2.3.6.so
(path inode=147229)
bacula-fd 3028 root mem REG 9,0 15568 147184
/lib/libattr.so.1.1.0
bacula-fd 3028 root mem REG 9,0 147320 /lib/libnsl-2.3.6.so
(path inode=147272)
bacula-fd 3028 root 0r CHR 1,3 1958 /dev/null
bacula-fd 3028 root 1r CHR 1,3 1958 /dev/null
bacula-fd 3028 root 2r CHR 1,3 1958 /dev/null
bacula-fd 3028 root 3u IPv4 8622 TCP *:bacula-fd
(LISTEN)
As you can clearly see, all STD* FDs are correctly set to /dev/null.
======================================================================
----------------------------------------------------------------------
jgoerzen - 10-18-07 12:30
----------------------------------------------------------------------
From: Sven Hartge <[EMAIL PROTECTED]>
Um 01:14 Uhr am 11.09.07 schrieb Sven Hartge:
> After a quick test and upgrade to a freshly build 2.2.3, I can see this
> problem/bug is in all daemons from bacula (director, storage and file).
Hmm.
The code for daemonization in bacula is found in src/lib/daemon.c in
daemon_start().
In line 77 debug_level is checked and low_fd set accordingly. Somehow this
seems to be always > 0, causing the lower FDs to remain connected to the
terminal.
"Brutally" disabling the if clause (and thus disabling any debug facility)
restores the old pre-2.2.x behavior, but this is by any means no fix, just
a very very crude work-around.
Right now I am trying to find out, why debug_level is set, even if the
daemons are not started with any debug option.
I first suspected DEVELOPER to be set, but this turned out not to be the
case.
Grüße,
Sven.
----------------------------------------------------------------------
jgoerzen - 10-18-07 12:30
----------------------------------------------------------------------
From: Sven Hartge <[EMAIL PROTECTED]>
Um 17:02 Uhr am 11.09.07 schrieb Sven Hartge:
> Right now I am trying to find out, why debug_level is set, even if the
> daemons are not started with any debug option.
Another indication of debug_level being > 0 is the invocation of
print_memory_pool_stats() at the termination of a daemon (line 243 in
filed.c for example).
But I am still at loss _why_ debug_level gets set.
Grüße,
Sven.
From: Sven Hartge <[EMAIL PROTECTED]>
Hi.
After an update to the recently released 2.2.4 of bacula the problem still
persists.
----------------------------------------------------------------------
kern - 10-19-07 07:51
----------------------------------------------------------------------
The default value of debug_level was set to 1, probably during debugging.
I've attached a patch to this bug report that corrects this problem. The
patch also contains a fix in the same file that keeps bat from seg faulting
when it cannot connect to the Director (i.e. Director not running).
The instructions for applying the patch are at the top of the patch file.
Issue History
Date Modified Username Field Change
======================================================================
10-18-07 12:29 jgoerzen New Issue
10-18-07 12:30 jgoerzen Note Added: 0002879
10-18-07 12:30 jgoerzen Note Added: 0002880
10-19-07 07:49 kern File Added: 2.2.5-deamon.patch
10-19-07 07:51 kern Note Added: 0002884
10-19-07 07:51 kern Status new => closed
10-19-07 07:51 kern Resolution open => fixed
======================================================================
--- End Message ---
