3

I've recently set up a fedora 17 server for our network, and I've been having trouble getting the NIS service to work on startup. Here's some logs from the system:

Aug 21 12:57:12 cairnwell ypbind-pre-setdomain[718]: Setting NIS domain: 'indigo-nis' (environment variable)
Aug 21 12:57:13 cairnwell ypbind: Binding NIS service
Aug 21 12:57:13 cairnwell rpc.statd[730]: Unable to prune capability 0 from bounding set: Operation not permitted
Aug 21 12:57:13 cairnwell systemd[1]: nfs-lock.service: control process exited, code=exited status=1
Aug 21 12:57:13 cairnwell systemd[1]: Unit nfs-lock.service entered failed state.
Aug 21 12:57:14 cairnwell setroubleshoot: SELinux is preventing /usr/sbin/rpc.statd from using the setpcap capability. For complete SELinux messages. run sealert -l 024bba8a-b0ef-43dc-b195-5c9a2d4c4d41
Aug 21 12:57:15 cairnwell kernel: [   18.822282] bnx2 0000:02:00.0: em1: NIC Copper Link is Up, 1000 Mbps full duplex
Aug 21 12:57:15 cairnwell kernel: [   18.822925] ADDRCONF(NETDEV_CHANGE): em1: link becomes ready
Aug 21 12:57:15 cairnwell NetworkManager[621]: <info> (em1): carrier now ON (device state 20)
Aug 21 12:57:15 cairnwell NetworkManager[621]: <info> (em1): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Aug 21 12:57:15 cairnwell NetworkManager[621]: <info> Auto-activating connection 'System em1'.
Aug 21 12:57:15 cairnwell NetworkManager[621]: <info> Activation (em1) starting connection 'System em1'
Aug 21 12:57:15 cairnwell NetworkManager[621]: <info> (em1): device state change: disconnected -> prepare (reason 'none') [30 40 0]
.......
Aug 21 12:57:19 cairnwell sendmail[790]: YPBINDPROC_DOMAIN: Domain not bound
Aug 21 12:57:26 cairnwell sendmail[790]: YPBINDPROC_DOMAIN: Domain not bound
Aug 21 12:57:31 cairnwell sendmail[790]: YPBINDPROC_DOMAIN: Domain not bound
Aug 21 12:57:35 cairnwell sendmail[790]: YPBINDPROC_DOMAIN: Domain not bound
Aug 21 12:58:00 cairnwell ypbind: Binding took 47 seconds
Aug 21 12:58:00 cairnwell ypbind: NIS server for domain indigo-nis is not responding.
Aug 21 12:58:01 cairnwell ypbind: Killing ypbind with PID 733.
Aug 21 12:58:01 cairnwell ypbind-post-waitbind[734]: /usr/lib/ypbind/ypbind-post-waitbind: line 51: kill: SIGTERM: invalid signal specification
Aug 21 12:58:01 cairnwell systemd[1]: ypbind.service: control process exited, code=exited status=1
Aug 21 12:58:01 cairnwell systemd[1]: Unit ypbind.service entered failed state.

By the looks of these logs the ypbind service is starting up at 12:57:12 but the network interface isn't coming up till 12:57:15. My guess is that this is causing ypbind to time out when trying to connect.

As a knock-on effect the NIS failure is causing problems with NFS which is no longer able to map UIDs properly. This problem doesn't seem to be fixed by actually starting ypbind etc. so I've had to set all my NFS shares to noauto.

I have tried manually adding NETWORKDELAY and NETWORKWAIT in /etc/sysconfig/network and also running systemctl enable NetworkManager-wait-online.service as I've seen suggested in some places, but neither of these have had any effect.

It is relatively easy to fix manually by restarting ypbind & mounting NFS shares after the network has started up, but it's less than ideal to have to do this every time the server has been rebooted.

Does anyone know of an easy (and preferably hack-free) way of delaying the ypbind startup till after the network interface is fully ready?

obmarg
  • 131
  • 1
  • 4

1 Answers1

2

I post an answer because >50 reputation is needed to comment.

I'm going to point you to this very good article in case you haven't stumbled upon it.

Also, there's this very interesting line:

Alternatively, you can change your service that needs the network to be up, to include After=network-online.target and Wants=network-online.target

Please note the "Alternatively".

So, you probably have to create this file: /etc/systemd/system/ypbind.service.d/waitfornetwork.conf

[Service]
After=network-online.target
Wants=network-online.target

This answer is a possible solution. Not a guaranteed solution.

moebius_eye
  • 1,092
  • 7
  • 21