Description of problem: I upgraded to latest rawhide and rebooted with selinux=0 to get around bz#645566. I then discovered that ypbind had not started, so my user account was not available and I couldn't log in. Running "service ypbind start" as root started ypbind so I could then log in. Version-Release number of selected component (if applicable): ypbind-1.32-1.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1.reboot 2.attempt to log in 3. Actual results: User account not available, so login fails. Expected results: user account exists, login succeeds. Additional info: This might be systemd's fault, but I don't know.
Could you provide the output of `systemctl status ypbind.service`, please? It would also help a lot to know what ypbind logs to /var/log/messages when it fails to start.
[root@fenlason-lab4 ~]# systemctl status ypbind.service ypbind.service - LSB: This is a daemon which runs on NIS/YP clients and binds them to a NIS domain. It must be running for systems based on glibc to work as NIS clients, but it should not be enabled on systems which are not using NIS. Loaded: loaded (/etc/rc.d/init.d/ypbind) Active: inactive (dead) CGroup: name=systemd:/system/ypbind.service [root@fenlason-lab4 ~]# [root@fenlason-lab4 ~]# egrep ypbind /var/log/messages Nov 14 09:46:28 fenlason-lab4 setsebool: The allow_ypbind policy boolean was changed to 1 by root Nov 14 09:46:31 fenlason-lab4 ypbind: NIS domain: redhat.com, NIS server: ns1.bos.redhat.com Nov 14 21:38:52 fenlason-lab4 setsebool: The allow_ypbind policy boolean was changed to 1 by root Nov 14 21:38:54 fenlason-lab4 ypbind: NIS domain: redhat.com, NIS server: ns1.bos.redhat.com Nov 15 08:50:02 fenlason-lab4 setsebool: The allow_ypbind policy boolean was changed to 1 by root Nov 15 08:50:05 fenlason-lab4 ypbind: NIS domain: redhat.com, NIS server: ns1.bos.redhat.com Nov 16 13:57:35 fenlason-lab4 setsebool: The allow_ypbind policy boolean was changed to 1 by root Nov 16 13:57:35 fenlason-lab4 ypbind: NIS domain: redhat.com, NIS server: ns1.bos.redhat.com Nov 16 23:52:21 fenlason-lab4 setsebool: The allow_ypbind policy boolean was changed to 1 by root Nov 16 23:52:23 fenlason-lab4 ypbind: NIS domain: redhat.com, NIS server: ns1.bos.redhat.com Nov 17 11:36:52 fenlason-lab4 setsebool: The allow_ypbind policy boolean was changed to 1 by root Nov 17 11:36:52 fenlason-lab4 ypbind: NIS domain: redhat.com, NIS server: ns1.bos.redhat.com [root@fenlason-lab4 ~]#
Thanks. It works on my Rawhide QEMU machine. I can login with a NIS account and kerberos password. I've seen some "Lost connection to D-Bus" messages, but ypbind handled that well. So we need more info. Could you edit /etc/init.d/ypbind and modify the OTHER_YPBIND_OPTS line so it reads: OTHER_YPBIND_OPTS="-verbose" /var/log/messages should then contain more messages from ypbind after a reboot, and we might be able to see where the problem is on your computer.
It doesn't say anything at all until I do a "service ypbind start". Then it says Nov 24 14:30:58 fenlason-lab4 yum[22936]: Updated: 3:ypbind-1.32-3.fc15.x86_64 Nov 29 15:27:29 fenlason-lab4 setsebool: The allow_ypbind policy boolean was changed to 1 by root Nov 29 15:27:29 fenlason-lab4 ypbind[1983]: NIS server is '10.16.255.2' for domain 'redhat.com' Nov 29 15:27:29 fenlason-lab4 ypbind: NIS domain: redhat.com, NIS server: ns1.bos.redhat.com Unfortunately, I'm in the kernel hardware group, so virt isn't an option for me. I can lend you fenlason-lab4 for you to investigate yourself if you'd like. Ping me on IRC or email if you'd like access information.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This failure seems to be similar to bug #696629, can you try a new build ypbind-1.32-8.fc15.1 (http://koji.fedoraproject.org/koji/buildinfo?buildID=241396)? Btw. what version of NetworkManager, do you use?
Jay, do you still see this problem?
I still see this on -lab3 and -lab4 with ypbind-1.33-11.fc17.x86_64
Could you attach output of dmesg to see ordering of services during boot? To do so, boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg".
Created attachment 558419 [details] dmesg from lab4
Sorry for delay. I see some AVC in your dmesg, what version of selinux-polices do you have?
selinux-policy-3.10.0-89.fc17.noarch as of today. But since this is a Rawhide box, it changes fairly frequently.
The following AVC denials seem to be the problem (prevents ypbind to be started correctly): [ 47.852142] systemd[1]: About to execute: /usr/lib/ypbind/ypbind-pre-setdomain [ 47.895378] systemd[1]: Forked /usr/lib/ypbind/ypbind-pre-setdomain as 1072 [ 47.902308] systemd[1]: ypbind.service changed dead -> start-pre [ 47.917520] systemd[1]: Got D-Bus request: org.freedesktop.DBus.Properties.Get() on /org/freedesktop/systemd1/unit/ypbind_2eservice [ 47.933102] type=1400 audit(1327945450.252:11): avc: denied { execute_no_trans } for pid=1072 comm="sd(EXEC)" path="/usr/lib/ypbind/ypbind-pre-setdomain" dev="sda2" ino=1795387 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file ... [ 48.422056] systemd[1]: About to execute: /usr/lib/ypbind/ypbind-post-waitbind [ 48.460572] systemd[1]: Forked /usr/lib/ypbind/ypbind-post-waitbind as 1078 [ 48.464248] type=1400 audit(1327945450.783:13): avc: denied { execute_no_trans } for pid=1078 comm="sd(EXEC)" path="/usr/lib/ypbind/ypbind-post-waitbind" dev="sda2" ino=1795240 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file But why they are there? It's working fine by me with the following builds with no AVC messages. I have the same selinux-policy and pre/post-exec scripts have the same SELinux context: selinux-policy-3.10.0-89.fc17.noarch ypbind-1.33-11.fc17.x86_64 glibc-2.15-23.fc17.x86_64 systemd-43-1.fc17.x86_64 -rwxr-xr-x. root root system_u:object_r:lib_t:s0 /usr/lib/ypbind/ypbind-post-waitbind -rwxr-xr-x. root root system_u:object_r:lib_t:s0 /usr/lib/ypbind/ypbind-pre-setdomain I also don't see a D-Bus message by me: Got D-Bus request: org.freedesktop.DBus.Properties.Get() on /org/freedesktop/systemd1/unit/ypbind_2eservice ...which I don't understand at all, so re-assign to systemd, maybe systemd guys will have a clue what's wrong.
The correct selinux parameter to use on the kernel command line is "enforcing=0" NOT "selinux=0" since you will have to relabel the whole thing again after using it. Try running "touch /.autorelabel && reboot" to see if it does not fix your issue...
Moving back against ypbind since this looks like a clear cut "I forgot to relable the filesystem after using selinux=0" issue. In the future make note of comment 14 then assign against selinux-policy all selinux issues you might encounter and Dan will then reassigned the report against systemd if relevant Thanks.
I relabeled the filesystem and rebooted, and ypbind still didn't start. Now what? Also note that "selinux=0" or "enforcing=0" do not let ypbind start, so I don't think this is a selinx issue.
(In reply to comment #16) > I relabeled the filesystem and rebooted, and ypbind still didn't start. Now > what? Do you still see AVC denials from comment #13?
(In reply to comment #16) > I relabeled the filesystem and rebooted, and ypbind still didn't start. Now > what? > > Also note that "selinux=0" or "enforcing=0" do not let ypbind start, so I don't > think this is a selinx issue. Now we have ruled out selinux issues then does enable the NetworkManager-wait-online.service fix your issue that is if it's not enabled already?
It wasn't previously enabled, but enabling it had no effect. Note that this machine is a server with a single wired ethernet port that is permanently connected to the dogfood network. As such, it uses the "network" subsystem rather than NetworkManager.
Going through dmesg output again I see wrong ordering of the services: [ 15.216061] systemd[1]: Installed new job rpcbind.socket/start as 66 [ 15.217123] systemd[1]: Installed new job ypbind.service/start as 88 [ 15.217169] systemd[1]: Installed new job rpcbind.service/start as 89 [ 31.583636] systemd[1]: rpcbind.socket changed dead -> listening [ 47.821276] systemd[1]: Trying to enqueue job ypbind.service/try-restart/replace [ 47.828602] systemd[1]: Installed new job ypbind.service/restart as 131 [ 47.852142] systemd[1]: About to execute: /usr/lib/ypbind/ypbind-pre-setdomain [ 48.414361] systemd[1]: Forked /usr/sbin/ypbind as 1077 [ 48.422056] systemd[1]: About to execute: /usr/lib/ypbind/ypbind-post-waitbind [ 48.659905] systemd[1]: Incoming traffic on rpcbind.socket [ 48.665211] systemd[1]: rpcbind.socket changed listening -> running [ 110.794628] systemd[1]: ypbind.service: control process exited, code=exited status=0 [ 110.866921] systemd[1]: Unit ypbind.service entered failed state. [ 112.871172] systemd[1]: About to execute: /sbin/rpcbind -w How rpcbind can be started 23s after ypbind, when ypbind.service contains: "After=syslog.target network.target rpcbind.service ypserv.service" ? As mentioned in comment #6, it seems to be a duplicate of bug #696629. Nevertheless, Jay, can you try to change rpcbind.service to rpcbind.target in ypbind's unit file?
I did, and it had no effect. I also added "Before=ypbind.service" to the rpcbind.service file, which also had no effect. Looking at systemctl show {rpcbind,ypbind}.service I see the appropriate Before and After lines, but it also shows that ypbind was started a minute before rpcbind. I think this is likely to be systemd's fault.
(In reply to comment #20) > Going through dmesg output again I see wrong ordering of the services: > > [ 15.217123] systemd[1]: Installed new job ypbind.service/start as 88 [...] > [ 47.821276] systemd[1]: Trying to enqueue job > ypbind.service/try-restart/replace > [ 47.828602] systemd[1]: Installed new job ypbind.service/restart as 131 > [ 47.852142] systemd[1]: About to execute: > /usr/lib/ypbind/ypbind-pre-setdomain This is a bug in systemd's handling of try-restart on a unit that is scheduled to be started but waiting for its dependencies. There is a minimal testcase in https://bugzilla.redhat.com/show_bug.cgi?id=753586#c12 *** This bug has been marked as a duplicate of bug 753586 ***