NIS demon fails during startup if the roaming mode is turned off
Bug #224828 reported by
Ludwik Trammer
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
hal (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
nis (Ubuntu) |
Confirmed
|
Low
|
Unassigned |
Bug Description
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.
Changed in nis (Ubuntu): | |
importance: | Undecided → Low |
status: | New → Confirmed |
Changed in hal (Ubuntu): | |
status: | New → Invalid |
To post a comment you must log in.
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.