+++ This bug was initially created to detach the dbus-related issue from Bug #693873 +++ Description of problem: A dbus connection message is printed on the console when rebooting/halting the system. Version-Release number of selected component (if applicable): ypbind-1.32-8.fc15 How reproducible: sometimes Steps to Reproduce: see the comments bellow Actual results: ypbind[...]: Connection to D-BUS system message bus failed: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused Expected results: No messages. Additional info: Conversation log from Bug #693873 related to this one: Severin Gehwolf 2011-04-08 10:50:43 EDT Remember that I'm using NIS + /home on NFS + NetworkManager now. Another (minor?) problem I have been seeing is that in some cases when I reboot/halt the machine, I get on the console: ypbind[...]: Connection to D-BUS system message bus failed: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused. Unfortunately, I cannot always reproduce. I'll follow up should I be able to. However, when it occurrs, I get the above message over and over again. The shutdown process stalls for 2 minutes or so, only printing this message until it finally continues. I cannot interrupt this (ctrl+c). ---------------------------------------- Comment 23 Jan Horak 2011-04-12 04:03:35 EDT (In reply to comment #21) > ypbind[...]: Connection to D-BUS system message bus failed: Failed to connect > to socket /var/run/dbus/system_bus_socket: Connection refused. > > Unfortunately, I cannot always reproduce. I'll follow up should I be able to. > However, when it occurrs, I get the above message over and over again. The > shutdown process stalls for 2 minutes or so, only printing this message until > it finally continues. I cannot interrupt this (ctrl+c). Does it happen even in ypbind-1.32-7.fc15? There is no correct LSB header in previous versions, so this could have been caused by massive parallelism of tasks during boot up. However, the LSB header is defined now, so it should be OK in this new update. ---------------------------------------- Comment 24 Severin Gehwolf 2011-04-13 18:18:08 EDT (In reply to comment #23) > (In reply to comment #21) > > ypbind[...]: Connection to D-BUS system message bus failed: Failed to connect > > to socket /var/run/dbus/system_bus_socket: Connection refused. > > > > Unfortunately, I cannot always reproduce. I'll follow up should I be able to. > > However, when it occurrs, I get the above message over and over again. The > > shutdown process stalls for 2 minutes or so, only printing this message until > > it finally continues. I cannot interrupt this (ctrl+c). > > Does it happen even in ypbind-1.32-7.fc15? There is no correct LSB header in > previous versions, so this could have been caused by massive parallelism of > tasks during boot up. However, the LSB header is defined now, so it should be > OK in this new update. To be honest, I'm not sure. I can't remember when I switched to ypbind with LSB headers in init scripts, so it's hard to tell. So far it didn't happen again and I don't consider this an issue anymore. Should it happen again, I'll report it here. Thanks! ---------------------------------------- Comment 26 Severin Gehwolf 2011-04-14 09:35:15 EDT (In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #21) > > > ypbind[...]: Connection to D-BUS system message bus failed: Failed to connect > > > to socket /var/run/dbus/system_bus_socket: Connection refused. > > > > > > Unfortunately, I cannot always reproduce. I'll follow up should I be able to. > > > However, when it occurrs, I get the above message over and over again. The > > > shutdown process stalls for 2 minutes or so, only printing this message until > > > it finally continues. I cannot interrupt this (ctrl+c). > > > > Does it happen even in ypbind-1.32-7.fc15? There is no correct LSB header in > > previous versions, so this could have been caused by massive parallelism of > > tasks during boot up. However, the LSB header is defined now, so it should be > > OK in this new update. $ rpm -q ypbind ypbind-1.32-7.fc16.x86_64 I am using this for a while now, and yesterday I was able to reproduce the system_bus_socket: Connection refused problem. It doesn't seem to be entirely fixed yet. This is just a FYI. I'm not overly concerned about this and I'm still foggy about how to reliably reproduce. Thanks! ---------------------------------------- Comment 27 Jan Horak 2011-04-14 09:46:51 EDT (In reply to comment #26) > $ rpm -q ypbind > ypbind-1.32-7.fc16.x86_64 > > I am using this for a while now, and yesterday I was able to reproduce the > system_bus_socket: Connection refused problem. It doesn't seem to be entirely > fixed yet. This is just a FYI. I'm not overly concerned about this and I'm > still foggy about how to reliably reproduce. Thanks! I realized that ypbind-1.32-7-fc15 misses $rpcbind in its LSB header, which hypothetically can cause problems such that. I've prepared a new package ypbind-1.32-8.fc15 (see comment #25), which has a correct LSB header, so you can give it a try and see, if something changes. ---------------------------------------- Comment 28 Severin Gehwolf 2011-04-15 10:47:50 EDT (In reply to comment #23) > (In reply to comment #21) > > ypbind[...]: Connection to D-BUS system message bus failed: Failed to connect > > to socket /var/run/dbus/system_bus_socket: Connection refused. Elaborating a bit more about this problem. I've noticed that _IF_ I see this problem, the immediately preceeding message printed to the console is something along the lines of: pam_systemd(...): Failed to get user data <NIS-UID> pam_su(...) ---> not sure about this I'm not sure if this is related. Maybe this is only happening after I've su'ed to root from a NIS user, but that doesn't seem to be the entire story since I can't reliably reproduce using just those two steps. Hmmm. Let me know when you've got a build with the $rpcbind in the LSB header ready. Thanks! ---------------------------------------- Comment 30 Severin Gehwolf 2011-04-26 09:22:29 EDT (In reply to comment #27) > (In reply to comment #26) > > $ rpm -q ypbind > > ypbind-1.32-7.fc16.x86_64 > > > > I am using this for a while now, and yesterday I was able to reproduce the > > system_bus_socket: Connection refused problem. It doesn't seem to be entirely > > fixed yet. This is just a FYI. I'm not overly concerned about this and I'm > > still foggy about how to reliably reproduce. Thanks! > > I realized that ypbind-1.32-7-fc15 misses $rpcbind in its LSB header, which > hypothetically can cause problems such that. I've prepared a new package > ypbind-1.32-8.fc15 (see comment #25), which has a correct LSB header, so you > can give it a try and see, if something changes. FWIW: I have ypbind-1.32-8.fc15 here and still have seen the system_bus_socket: Connection refused problem :( ---------------------------------------- Comment 31 Jan Horak 2011-04-27 10:05:01 EDT You can try to add also messagebus to LSB header and see if it helps: -# Required-Start: $local_fs $remote_fs $network $rpcbind -# Required-Stop: $local_fs $remote_fs $network $rpcbind +# Required-Start: $local_fs $remote_fs $network $rpcbind messagebus +# Required-Stop: $local_fs $remote_fs $network $rpcbind messagebus What version of NetworkManager do you use?
BTW. I think I can reliably reproduce. 1. Login (using NIS) and get a Gnome 3 session 1.1. Maybe requires some /home ressources to be used (I have /home on NFS) which is automounted (autofs) via systemd. 2. Use Gnome 3's logout dialog in the top-right corner, keep <Alt> pressed for the "Suspend" option to switch to "Power Off". 3. Click Power off > What version of NetworkManager do you use? $ rpm -q NetworkManager NetworkManager-0.8.998-2.git20110406.fc15.x86_64 > You can try to add also messagebus to LSB header and see if it helps: > > -# Required-Start: $local_fs $remote_fs $network $rpcbind > -# Required-Stop: $local_fs $remote_fs $network $rpcbind > +# Required-Start: $local_fs $remote_fs $network $rpcbind messagebus > +# Required-Stop: $local_fs $remote_fs $network $rpcbind messagebus If I do this I don't get the connection refused messages. Instead it sits there, after NetworkManager is shut down for 2 mins and continues to regularly halt the system. It's ok, but not great.
$ rpm -q ypbind ypbind-1.32-8.fc15.1.x86_64 With this version it looks like this issue is fixed for me. When I try to halt the system, it does this as expected. Not sure what fixed it, there have been a few updates lately. Thanks, Jan!
(In reply to comment #2) > $ rpm -q ypbind > ypbind-1.32-8.fc15.1.x86_64 > > With this version it looks like this issue is fixed for me. When I try to halt > the system, it does this as expected. Not sure what fixed it, there have been a > few updates lately. Thanks, Jan! Great, but it's hard to say if it's been solved by this ypbind update or by some other package. So I'm closing this as solved in current release and hope that it never comes back.
Sorry, I have to reopen this. It just happened again :(
I'm not sure if this issue can be caused by ypbind, re-assigning to systemd. Please, re-assign it back if ypbind can do something better.
Are you using the read-only root stuff (i.e /etc/rwtab)?
(In reply to comment #6) > Are you using the read-only root stuff (i.e /etc/rwtab)? I'm still not able to reproduce this, changing needinfo to Severin.
(In reply to comment #6) > Are you using the read-only root stuff (i.e /etc/rwtab)? Good question. How would I check? I haven't changed anything from stock F15 to deliberately enable it. If stock F15 is using it, I'm likely using it. FWIW, /etc/rwtab exists.
If you haven't configured it, you almost certainly aren't using it. (Unless you're running Sugar/OLPC.)
Is there anything in dmesg or syslog? Does /run/systemd exist? What's its contents?
Ok, I'm not using read-only root stuff, I suppose. # ls /run/systemd/ ask-password logger notify private readahead shutdownd system # dmesg | grep -i connection <nothing>
Hmm, so let me see if I understood this prob correctly: on shutdown you see a dbus disconnection messages on the console which you rather would prefer not to see? And ypbind is generating it? Note that systemd is parallelizing shutdown as much as possible. That means all connections will just go away as quickly as possible. Hence my suggested fix would be to make ypbind simple take dbus disconnection as a hint to terminate and that's it.
(In reply to comment #12) > Hmm, so let me see if I understood this prob correctly: on shutdown you see a > dbus disconnection messages on the console which you rather would prefer not to > see? I see ypbind[...]: Connection to D-BUS system message bus failed: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused. messages filling my screen for 2 minutes or longer. I cannot cancel it (CTRL+C). After >= 2 minutes, shutdown eventually finishes. I don't care about a few messages on the console, but connection refused messages were annoying. I haven't seen this in a while, though. > And ypbind is generating it? It appears so. > Note that systemd is parallelizing shutdown as much as possible. That means all > connections will just go away as quickly as possible. Hence my suggested fix > would be to make ypbind simple take dbus disconnection as a hint to terminate > and that's it. Jan?
(In reply to comment #13) > messages filling my screen for 2 minutes or longer. I cannot cancel it > (CTRL+C). After >= 2 minutes, shutdown eventually finishes. I don't care about > a few messages on the console, but connection refused messages were annoying. I > haven't seen this in a while, though. Is the delay of 2 min. occurred only if you have "messagebus" in LSB header of your /etc/init.d/ypbind (see comment #1) or is it occurred every-time? > > Note that systemd is parallelizing shutdown as much as possible. That means all > > connections will just go away as quickly as possible. Hence my suggested fix > > would be to make ypbind simple take dbus disconnection as a hint to terminate > > and that's it. ypbind tries to reconnect to dbus in one second after the dbus connection is lost. In this case it seems ypbind is trying to connect again while dbus is already stopped and never come alive, thus the message is printed. I think this is correct behavior of ypbind, while it shouldn't stop itself when dbus is restarted only (for any reason). I've prepared a scratch build where ypbind waits for 10 seconds instead of one to reconnect to dbus (it should be enough time to kill ypbind even if dbus is killed before). You can try it here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3076533 However, why dbus isn't killed after *all* depended services finish?
(In reply to comment #14) > However, why dbus isn't killed after *all* depended services finish? I've got answer for this question in comments in bug #696629: "...systemd interprets the LSB headers "Required-Start:" and "Should-Start:" merely as ordering dependencies (like After=... in native units)..." So I'm not sure if it is even possible to fix this bug inside ypbind.
Severin, do you still encounter this issue with a newer ypbind? Just FYI ypbind has included systemd native service files since F16, which could change booting behavior + there is a fresh update of ypbind in F16 [1]. Could you give it a try? [1] https://admin.fedoraproject.org/updates/FEDORA-2012-0897/ypbind-1.33-11.fc16
Sorry, I've stopped using NIS. Feel free to close this bug.
(In reply to comment #17) > Sorry, I've stopped using NIS. Feel free to close this bug. Closing the bug as per comment above.