Red Hat Bugzilla – Bug 199596
avahi - update kills daemon
Last modified: 2007-11-30 17:11:38 EST
Description of problem: After an update to avahi-0.6.11-2.fc6 # service avahi-daemon start has a prolonged timeout and eventually comes with the following: Starting Avahi daemon: Timeout reached while wating for return value Could not receive return value from daemon process. [FAILED] Status check has the following effect: # service avahi-daemon status Process 2473 died: No such process; removing PID file. (/var/run/avahi-daemon//pid) Avahi daemon is not running Tail of strace looks like follows: clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaab3709f0) = 2546 --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigreturn(0x11) = 2546 close(6) = 0 wait4(2546, NULL, WSTOPPED, NULL) = 2546 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigaction(SIGCHLD, {SIG_DFL}, NULL, 8) = 0 read(5, "\363\t\0\0", 4) = 4 close(5) = 0 select(1024, [3], NULL, NULL, {20, 0}) = 0 (Timeout) write(2, "Timeout reached while wating for"..., 45Timeout reached while wating for return value) = 45 write(2, "\n", 1 ) = 1 write(2, "Could not receive return value f"..., 51Could not receive return value from daemon process.) = 51 write(2, "\n", 1 ) = 1 close(3) = 0 close(4) = 0 exit_group(255) = ? Process 2545 detached I do not know if this happens only on x86_64. Version-Release number of selected component (if applicable): avahi-0.6.11-2.fc6 How reproducible: always
Have you updated to all the latest updates of rawhide-20060720 ? I cannot reproduce this on the i386 with today's rawhide. I'll look around for an x86_64 on rawhide to test this ...
> Have you updated to all the latest updates of rawhide-20060720 ? Yes, that is the problem. 'yum check-update' show only 'system-config-soundcard.noarch' outstanding because this, at the moment, has broken dependencies. rawhide-20060720 killed for me avahi-daemon, hald and everything on a desktop. > I cannot reproduce this on the i386 with today's rawhide. I also could not until I applied updates.
After I loaded few 'debuginfo' packages I see the following when I break a wait in gdb: (gdb) bt #0 0x0000003c48ac9243 in __select_nocancel () from /lib64/libc.so.6 #1 0x0000003c47e01ba0 in daemon_retval_wait (timeout=<value optimized out>) at dfork.c:314 #2 0x0000000000406f75 in main (argc=6404320, argv=<value optimized out>) at main.c:1133 #3 0x0000003c48a20aa4 in __libc_start_main () from /lib64/libc.so.6 #4 0x0000000000405489 in _start () (gdb) list main.c:1133 1128 goto finish; 1129 else if (pid != 0) { 1130 int ret; 1131 /** Parent **/ 1132 1133 if ((ret = daemon_retval_wait(20)) < 0) { 1134 avahi_log_error("Could not receive return value from daemon process."); 1135 goto finish; 1136 } 1137 and after a break on line 1134 a value of 'ret' is -1. The problem is that things like 'libdaemon' were installed some time ago and everything worked before today updates which pulled in, among other things, dbus-0.90-6 and avahi-0.6.11-2.fc6.
Well, trying to run that without '-D' gives the following in gdb: Program received signal SIGABRT, Aborted. [Switching to Thread 46912505317728 (LWP 15379)] 0x0000003c48a33145 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0000003c48a33145 in raise () from /lib64/libc.so.6 #1 0x0000003c48a34a90 in abort () from /lib64/libc.so.6 #2 0x00002aaaab14fcc5 in _dbus_abort () at dbus-sysdeps.c:89 #3 0x00002aaaab13d377 in _dbus_real_assert (condition=<value optimized out>, condition_text=0x2aaaab152f38 "!(connection)->have_connection_lock", file=0x2aaaab1529de "dbus-connection.c", line=1727, func=0x2aaaab154c30 "dbus_connection_ref") at dbus-internals.c:477 #4 0x00002aaaab111b9a in dbus_connection_ref (connection=0x61ddb0) at dbus-connection.c:1727 #5 0x00002aaaab12f51c in _dbus_pending_call_new (connection=0x61ddb0, timeout_milliseconds=<value optimized out>, timeout_handler=0x2aaaab1191c0 <reply_handler_timeout>) at dbus-pending-call.c:122 #6 0x00002aaaab118bd8 in dbus_connection_send_with_reply ( connection=0x61ddb0, message=0x61e090, pending_return=0x7fffc214c330, timeout_milliseconds=-1) at dbus-connection.c:2396 #7 0x00002aaaab119068 in dbus_connection_send_with_reply_and_block ( connection=0x61ddb0, message=0x61e090, timeout_milliseconds=-1, error=0x7fffc214c3e0) at dbus-connection.c:2772 #8 0x00002aaaab110b61 in dbus_bus_register (connection=0x61ddb0, error=0x7fffc214c3e0) at dbus-bus.c:510 #9 0x00002aaaab110f8c in internal_bus_get (type=DBUS_BUS_SYSTEM, error=0x7fffc214c3e0, private=0) at dbus-bus.c:394 #10 0x000000000040b56d in dbus_connect () at dbus-protocol.c:1056 #11 0x000000000040bcb6 in dbus_protocol_setup (poll_api=0x61d1f0, _disable_user_service_publishing=<value optimized out>, force=0) at dbus-protocol.c:1146 #12 0x0000000000405f3d in run_server (c=0x61ab60) at main.c:748 #13 0x000000000040691b in main (argc=6404320, argv=<value optimized out>) at main.c:1193 #14 0x0000003c48a20aa4 in __libc_start_main () from /lib64/libc.so.6 #15 0x0000000000405489 in _start () Better?
Ok, I see a somewhat similar backtrace from hald running with '--daemon=no'. It looks like a new dbus problem.
This is indeeed another manifestation of bug #199617. Fixed by updating dbus packages. *** This bug has been marked as a duplicate of 199617 ***