Description of problem: When the ypbind service is configured to be brought up on runlevel 3 and 5 it systemd should start the service. Version-Release number of selected component (if applicable): # rpm -q systemd systemd-22-1.fc15.x86_64 # rpm -q ypbind ypbind-1.32-5.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. chkconfig ypbind on (or systemctl enable ypbind.service) # chkconfig --list ypbind ypbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off Actual results: ypbind not started on runlevel 3 and 5 when system is rebooted. Expected results: ypbind started after reboot. Additional info: I'm just using NIS client tools to bind to a NIS domain. Let me know if you need more info :) Thanks for doing this great work on systemd!
I think this is a ypbind bug. Reassigning...
Apparently ypbind init scripts are missing proper LSB headers to specify dependencies explicitly. Maybe something like: ### BEGIN INIT INFO # Provides: ypbind # Required-Start: $local_fs $remote_fs $network # Required-Stop: $local_fs $remote_fs $network # Short-Description: Starts the ypbind daemon # Description: The ypbind daemon ### END INIT INFO would work? The alternative proposed solution was to migrate to systemd's native unit files. Thanks for taking care of this!
I'd like to see why exactly it is failing to start if the LSB header is not present. Could you please boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg" and attach here the output of "dmesg"? Thanks.
Thanks for reporting. However, the issue isn't as easy as it seems to be. ypbind works without LSB header for me, but only if I use network instead of NetworkManager. On the other hand, it doesn't work with NetworkManager, even with correct LSB header. ypbind seems to be started correctly (at least what systemctl says) and the process is running, but "rpcinfo -p localhost" doesn't print ypbind and the service broken. I will attach dmesg and message log with both - network and NetworkManager. It seems to be some dbus problem, but not sure yet.
Created attachment 490528 [details] dmesg using network.service
Created attachment 490529 [details] dmesg using NetworkManager.service
Created attachment 490530 [details] messages log using network.service
Created attachment 490531 [details] messages log using NetworkManager.service
Jan, note that the correct spelling for the log_target is "kmsg", not "kmesg". Why do you suspect a dbus problem? Is it because of messages like this one?: Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service failed to load: No such file or directory. The message is not very user-friendly, but in this case it really just means that bluetooth.service is disabled and therefore it could not be DBus-activated.
(In reply to comment #4) > Thanks for reporting. However, the issue isn't as easy as it seems to be. > > ypbind works without LSB header for me, but only if I use network instead of > NetworkManager. Hmm, I'm using network and it's not working (i.e. brought up on boot) with or without the LSB headers in the init scripts.
Created attachment 490546 [details] dmesg (using network) output as produced with kernel options as described in Michal's comment. Note that I've tried to add LSB headers to the ypbind init script, but this didn't change the situation. I'll attach what I currently have in /etc/init.d/ypbind as another attachment.
Created attachment 490547 [details] output of $ head -n50 /etc/init.d/ypbind With those headers in the script, ypbind is still not brought up on boot.
Created attachment 490570 [details] dmesg using NetworkManager.service (In reply to comment #9) > Jan, note that the correct spelling for the log_target is "kmsg", not "kmesg". So this is more verbose dmesg output for NetworkManager.
Created attachment 490571 [details] dmesg using network.service And this is more verbose dmesg output for network.service, that still works for me.
I've managed to fix this problem at least for me. The problem is that NetworkManager has changed D-Bus response codes, so ypbind doesn't understand its response correctly (ypbind uses its own enum definition when it is being built without NetworkManager-debug package installed). So the following build fixes this issue for me. Could you try it and give me a notice if it works for you, please? http://koji.fedoraproject.org/koji/buildinfo?buildID=238090
Jan, I'll give it a shot and let you know. FWIW: http://lists.fedoraproject.org/pipermail/devel/2011-April/150246.html
Since Jan reported it working, I switched back to NetworkManager (from network), installed the rpm from the above linked build and ypbind is properly brought up on boot. Thanks! Could you please also push this as an update for F15? There is only one remaining problem. When I try to log on GDM using my NIS account, GDM freezes. I need to kill GDM (ctrl+alt+backspace). Then, when GDM auto-restarts, it works properly. I'm not sure if this is a GDM, sytemd or NIS problem. I suspect it's GDM... Any more thoughts on this remaining problem?
ypbind-1.32-7.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ypbind-1.32-7.fc15
(In reply to comment #17) > There is only one remaining problem. When I try to log on GDM using my NIS > account, GDM freezes. I need to kill GDM (ctrl+alt+backspace). Then, when GDM > auto-restarts, it works properly. I'm not sure if this is a GDM, sytemd or NIS > problem. I suspect it's GDM... > > Any more thoughts on this remaining problem? I've noticed this too and found it has been already reported in bug #690873, so you can join that conversation, too.
(In reply to comment #19) > (In reply to comment #17) > > There is only one remaining problem. When I try to log on GDM using my NIS > > account, GDM freezes. I need to kill GDM (ctrl+alt+backspace). Then, when GDM > > auto-restarts, it works properly. I'm not sure if this is a GDM, sytemd or NIS > > problem. I suspect it's GDM... > > > > Any more thoughts on this remaining problem? > > I've noticed this too and found it has been already reported in bug #690873, so > you can join that conversation, too. Ok, thanks for the pointer!
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).
Package ypbind-1.32-7.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ypbind-1.32-7.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/ypbind-1.32-7.fc15 then log in and leave karma (feedback).
(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.
(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!
ypbind-1.32-8.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ypbind-1.32-8.fc15
(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!
(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.
(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!
ypbind-1.32-8.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
(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 :(
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?
(In reply to comment #31) > What version of NetworkManager do you use? $ rpm -q NetworkManager NetworkManager-0.8.998-2.git20110406.fc15.x86_64 I'll try your other suggestion later today. Thanks!
Since this bug originally addressed another issue, which is already solved, I've copied the dbus-connection related comments to bug #700429 to track the issue separately.
Ok. Thanks for moving things to the new bug.