NIS demon fails during startup if the roaming mode is turned off

[Ludwik Trammer]

Binary package hint: nis

This is a new bug that affects Ubuntu 8.04 LTS, previous versions doesn't share this problem.

The symptoms:
As long as the network roaming mode is turn on everything works great. But after somebody turn it off in the network card's properties (in my case to set a static ip address) NIS client daemon always fail during startup and network users can't log in until the demon gets manually restarted.

[David Munro (dhmunro)]

I had this problem as well. By experimenting with the order in which the scripts in /etc/rc2.d/ are run, I discovered that if the /etc/init.d/nis script runs after the /etc/init.d/hal script, then NIS starts correctly, while if nis runs before hal, then it does not. This is apparently why the nis script runs successfully from the command line after booting. Thus, as a workaround, I did this as root:

cd /etc/rc2.d
mv S24hal S17hal

This puts hal before S18nis, and NIS starts correctly. I haven't noticed any side effects of moving hal, although I am not expert enough at what it might depend on to not be worried that my workaround might cause problems with other packages. I decided to move hal earlier rather than nis later, because S19autofs depends on S18nis, so I would have to move at least two scripts instead of one.

Just to reiterate the details of my setup: I unchecked "Enable roaming mode" and entered my static IP address; I added a line
  domain my-nis-domain server my.nis.server
to /etc/yp.conf. During boot, the nis script cannot bind to the nis server; it goes through the do_wait() loop. After booting, ypwhich continues to fail, despite the fact that ypbind is running:

lmunro@perish:~$ ypwhich
ypwhich: Can't communicate with ypbind
lmunro@perish:~$ ps -elfw|grep ypbind
5 S root 5203 1 0 80 0 - 7050 - 07:22 ? 00:00:00 /usr/sbin/ypbind
0 R lmunro 6292 6273 0 80 0 - 751 - 07:23 pts/0 00:00:00 grep ypbind
lmunro@perish:~$ cat /var/run/ypbind.pid
5203

At least in my case, I have no evidence that the network is not up at the time S18nis runs, whether or not hal goes first -- in fact, it obviously is up enough that ypbind can connect as long as hal has run first.

[Ludwik Trammer (ludwik)]

Changing "S24ha" to "S17hal" worked for me, and doesn't seem to bring any new problems.

[Stefan Reichör (stefan-xsteve)]

I can confirm the bug described above for the machines in our network also.

The users were shocked that they could not login after the upgrade!
This is a very serious bug in my opinion.

Our workaround is the following:

* login as local user
* wajig restart nis
* login via nis

[asohangh (asohangh)]

David Munro's solution worked for me with a similar setup.

[Russel Winder (russel)]

I am finding that NIS client startup always fails during boot (is there a way of capturing the output for display in bug reports?) of all my machines that are NIS clients, but that it gets started prior to users being able to login, i.e. sometime before GDM offers the login page. The only problem this gives is that some machines take an inordinately long time to boot. Is there any word on whether this renumbering is accepted as an official fix?

[BlueCamel (ubuntu-bluecamel)]

I ran in to this same issue on a fresh Hardy install. I fixed this by adding the -no-dbus flag to the /etc/default/nis config:

# Additional options to be given to ypbind when it is started.
YPBINDARGS=-no-dbus

With the above change you can disable roaming mode and use a static IP without changing the order of init scripts.

[David (david-kahn)]

I just tried BlueCamel's suggested fix (adding YPBINDARGS=-no-dbus in /etc/default/nis), and it worked perfectly. This pretty much proves that NIS has a bug in its use of D-Bus, and should allow the developers to find and fix the bug.

Thanks!

[Mark Brown (broonie)]

David: You're jumping ahead of yourself with that diagnosis. It shows that either NIS has a problem in the DBus code or that the information provided via DBus by Network Manager is buggy. When this has been diagnosed previously (using nm-tool to display the network connection status while NIS is starting) we've always seen Network Manager reporting that the network is connected before it has obtained an IP address for the system (so the network is not yet usable for IPv4).

[Andrew Melo (andrew-melo)]

@Mark-

>>we've always seen Network Manager reporting that the network is connected before it has obtained an IP address for the system (so the network is not yet usable for IPv4)

I get the same error described above even when setting the IP address as static. By 'obtained an IP address', does that mean DHCP?

[David (david-kahn)]

I just installed a new kernel:

    Linux CERTIBY-DEV1 2.6.24-21-generic #1 SMP Mon Aug 25 16:57:51 UTC 2008 x86_64 GNU/Linux

and the latest DBus, and this is still failing.

[Stefan Reichör (stefan-xsteve)]

The problem is still present in Ubuntu 9.10

The fix from David Munro (2008-05-02) does no longer work:

There is no file named /etc/rc2.d/S24hal

What are other people doing to work around this problem?