Is there a problem with NIS in Hardy Heron?

Asked by David on 2008-05-05

Upgraded from Gutsy to Hardy last week. Rebooted my computer today after installing a bunch of upgrades through the Upgrade Manager.

Automounting started failing to mount my home directory. So I tried restarting autofs (automount) and saw that was failing because it couldn't get the mount points from NIS, where they are stored.

"ypcat -k auto.home" gave a message that it could not locate my NIS domain. So I restarted nis on the master server, then restarted nis on my computer, which is a secondary nis server, and ypcat started working again. This allowed autofs to start and everything works fine.

Since I don't want to have to restart services manually every time the computers are rebooted, it would be great to solve this. Is it a Hardy Heron bug?



Question information

English Edit question
Ubuntu nis Edit question
No assignee Edit question
Solved by:
Art Cancro
Last query:
Last reply:
David (david-kahn) said : #1

uname -a
Linux CERTIBY-DEV1 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux

David (david-kahn) said : #2

I noticed that I am not the only person to have this problem:

xcorex (xcorex) said : #3

I too can confirm the problem.

Hardy 64

David (david-kahn) said : #4

My problem still exists.

Arne (arne-c-mueller) said : #5

similar problem here.

First of all NFS doesn't work with nis, because nfs is mounted before nis is started (that's like that for some weeks now). Didn't bother me really.

But today I discovered, that nis doesn't start up correctly, like you mentioned.

Because I had this NFS problem previously, I have a program running, that creates a bootflow diagram every time I boot. From these diagrams I was able to see, that soemhow hald moved in the execution order from S12 to S24. Nis starts here at S18. So I gather, that HAL is somehow required for nis, or something, that is started together with hald.

Previous boot-order:

current boot-order:

David (david-kahn) said : #6

The dependency of the automounter/autofs (not nfs) is because my mount points are stored in the yellow pages.

My /etc/auto.master contains a single line: +auto.master
which tells the automounter to get the mount information from YP.
    $ ypcat -k auto.master
    /home yp:auto.home --ghost
    /backup yp:auto.backup --ghost

The YP entries for the home directories look like:
    $ ypcat -k auto.home
    ftp certiby1:/localmasters/home/&
    jkahn certiby1:/localmasters/home/&
    gkahn certiby1:/localmasters/home/&
    david certiby-dev1:/localmasters/home/&
    administrator certiby1:/localmasters/home/&

In other words, each person's home directory gets mounted from whichever server is holding it.

The problem I am having is that when NIS fails to start, it also causes autofs, again not nfs, to fail. Fortunately, after rebooting I can use Webmin to remotely start NIS then autofs, and everything works okay. However, it's still a hassle.

Best Art Cancro (artcancro) said : #7

Confirmed here on my Hardy desktop as well. Renaming /etc/rc2.d/S18nis to /etc/rc2.d/S30nis in order to change the startup order, fixed the problem. It's rather stupid that this is broken out of the box.

David (david-kahn) said : #8

Thanks Art. That works great.

Gary Swofford (gary-olsen) said : #9

My office uses NIS (and autofs) on all our Ubuntu desktops, so NIS problems are a big deal for me. I found this same NIS problem with Hardy, although luckily I am just testing Hardy on two computers at the moment. The result is a bit strange, one Hardy desktop has the problem and the other does not. Both have the same order of services in /etc/rc2.d. Both were upgrades from Gutsy.

Can anyone confirm this is a problem when doing a new Hardy install?

The fix Art mentioned above worked fine for the "broken" desktop. Thanks Art :-)

randallw (rwayth) said : #10

I have this problem with a fresh Hardy 64bit install. I'm using NIS & autofs to connect to a server for accounts and home directories. Thanks for the workaround.

I think this should be upgraded to a bug. It is clearly broken out of the box.

David (david-kahn) said : #11

This has become Bug #233807 in Ubuntu.

Gary Swofford (gary-olsen) said : #12

Thanks David.

Dan Woodard (dan-e-woodard) said : #13

Same problem here on hardy:
uname -a
Linux bari 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux

I too am in an office that uses autofs to mount home directories and until now I have had to login and restart nis to restore home directories.

David (david-kahn) said : #14

The identical problem was reported as several bugs, and I cannot tell you if it has actually been solved. However, it is known that the problem is caused by NIS' use of D-Bus, and a workaround that worked for me was proposed by BlueCamel at Here it is:

"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.

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

Good luck.

Mark Brown (broonie) said : #15

As discussed in the linked bugs the use of -no-dbus sidesteps the bugs in network manager. This workaround is employed in Debian releases but unfortunately Hardy (and Intrepid) synced when this was disabled for test purposes.

The Ubuntu guys seem keen to resolve this in Network Manger (which would be nice) so are reluctant to apply the workaround.