| Summary: | system_bus_socket: Connection refused problem on reboot/halt | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Honza Horak <hhorak> |
| Component: | ypbind | Assignee: | Honza Horak <hhorak> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | hhorak, johannbg, kklic, lpoetter, metherid, mschmidt, notting, plautrba, rdieter, sgehwolf |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-06 09:09:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Honza Horak
2011-04-28 11:46:44 UTC
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. |