nis daemon fails to attach to domain the first time it is run in Gutsy

[James R. Phillips]

Binary package hint: nis

In my Gutsy install (upgraded from beta server install to RC-1) the nis daemon fails to properly attach to the domain the first time it is run (at boot). The console prints [failed] instead of [ok], and network logins don't work (however local logins do). After restarting nis, it attaches properly.

I find error messages in the syslog like this:
========
Oct 14 19:24:46 rohan dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.nis_servers
========

However, this may be unrelated noise. Otherwise, I haven't located any related error messages in any file in /var/log.

Output of "uname -a":
=========
Linux rohan 2.6.22-14-generic #1 SMP Wed Oct 10 06:00:47 GMT 2007 i686 GNU/Linux
=========

Output of "apt-cache policy nis":
=========
nis:
  Installed: 3.17-10ubuntu1
  Candidate: 3.17-10ubuntu1
  Version table:
 *** 3.17-10ubuntu1 0
        500 http://us.archive.ubuntu.com gutsy/main Packages
        100 /var/lib/dpkg/status
=========

[Gary Mansell (garymansell)]

I find this a problem also

[Gary Mansell (garymansell)]

I think that this may be related to problems with network manager

[Mark Brown (broonie)]

Could you please edit /etc/init.d/nis to record the output of nm-tool after attempting to start ypbind? This should say what Network Manager thinks is happening which ought to show if it's a problem there or not.

After this block:

        if want_ypbind
        then
                log_progress_msg "ypbind"
                start-stop-daemon -b --start --quiet \
                        --exec ${NET}/ypbind -- $broadcast ${YPBINDARGS}
                bind_wait
        fi

add something like

       /usr/sbin/nm-tool > /tmp/nm-tool-output

which will create a file /tmp/nm-tool-output with information about what Network Manager thinks is happening. Please attach that file to the report once it's generated. Please do this for both when the system is starting up and when re-running the script later.

Thanks.

[James R. Phillips (james-r-phillips)]

OK. BTW, it is /usr/bin/nm-tool, not /usr/sbin/nm-tool.

Output of first run (during boot)
==================
NetworkManager Tool

State: connected

- Device: eth0 ----------------------------------------------------------------
  NM Path: /org/freedesktop/NetworkManager/Devices/eth0
  Type: Wired
  Driver: e100
  Active: yes
  HW Address: 00:02:55:1A:5D:7C

  Capabilities:
    Supported: yes
    Carrier Detect: yes
    Speed: 100 Mb/s

  Wired Settings
    Hardware Link: yes

  IP Settings:
    IP Address: 0.0.0.0
    Subnet Mask: 0.0.0.0
    Broadcast: 0.0.0.0
    Gateway: 0.0.0.0
    Primary DNS: 0.0.0.0
    Secondary DNS: 0.0.0.0
==================

Output of second run (after boot)
==================
NetworkManager Tool

State: connected

- Device: eth0 ----------------------------------------------------------------
  NM Path: /org/freedesktop/NetworkManager/Devices/eth0
  Type: Wired
  Driver: e100
  Active: yes
  HW Address: 00:02:55:1A:5D:7C

  Capabilities:
    Supported: yes
    Carrier Detect: yes
    Speed: 100 Mb/s

  Wired Settings
    Hardware Link: yes

  IP Settings:
    IP Address: 192.168.1.11
    Subnet Mask: 255.255.255.0
    Broadcast: 192.168.1.255
    Gateway: 192.168.1.1
    Primary DNS: 192.168.1.1
    Secondary DNS: 0.0.0.0
==================
eth0 does not appear to have an assigned IP address the first time /etc/init.d/nis is run.

[Gary Mansell (garymansell)]

will have to look at this when I am back at work next week....

----- Original Message ----
From: James R. Phillips <email address hidden>
To: <email address hidden>
Sent: Saturday, 20 October, 2007 12:03:21 AM
Subject: [Bug 152794] Re: nis daemon fails to attach to domain the first time it is run in Gutsy

OK. BTW, it is /usr/bin/nm-tool, not /usr/sbin/nm-tool.

Output of first run (during boot)
==================
NetworkManager Tool

State: connected

- Device: eth0
 ----------------------------------------------------------------
  NM Path: /org/freedesktop/NetworkManager/Devices/eth0
  Type: Wired
  Driver: e100
  Active: yes
  HW Address: 00:02:55:1A:5D:7C

  Capabilities:
    Supported: yes
    Carrier Detect: yes
    Speed: 100 Mb/s

  Wired Settings
    Hardware Link: yes

  IP Settings:
    IP Address: 0.0.0.0
    Subnet Mask: 0.0.0.0
    Broadcast: 0.0.0.0
    Gateway: 0.0.0.0
    Primary DNS: 0.0.0.0
    Secondary DNS: 0.0.0.0
==================

Output of second run (after boot)
==================
NetworkManager Tool

State: connected

- Device: eth0
 ----------------------------------------------------------------
  NM Path: /org/freedesktop/NetworkManager/Devices/eth0
  Type: Wired
  Driver: e100
  Active: yes
  HW Address: 00:02:55:1A:5D:7C

  Capabilities:
    Supported: yes
    Carrier Detect: yes
    Speed: 100 Mb/s

  Wired Settings
    Hardware Link: yes

  IP Settings:
    IP Address: 192.168.1.11
    Subnet Mask: 255.255.255.0
    Broadcast: 192.168.1.255
    Gateway: 192.168.1.1
    Primary DNS: 192.168.1.1
    Secondary DNS: 0.0.0.0
==================
eth0 does not appear to have an assigned IP address the first time
 /etc/init.d/nis is run.

--
nis daemon fails to attach to domain the first time it is run in Gutsy
https://bugs.launchpad.net/bugs/152794
You received this bug notification because you are a direct subscriber
of the bug.

      ___________________________________________________________
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

[Mark Brown (broonie)]

James, in your case it does look like Network Manager is reporting that the network is up before it actually is up. There are a series of existing bugs against Network Manager discussing this issue which you could subscribe to to track work on the problem.

[James R. Phillips (james-r-phillips)]

Um, what about a work-around while I am waiting for the real fix? The current state of this problem requires being at the console to manually login as a non-nis user with sudo privileges, to rerun the nis startup command, following any reboot.

[Mark Brown (broonie)]

You could try adding -no-ping to YPBINDARGS in /etc/default/nis. This will disable the Network Manager integration. See http://www.sirena.org.uk/log/?p=41

[James R. Phillips (james-r-phillips)]

OK, thanks. I am away from home at the moment, but will try this when I get back home - I don't want to try rebooting remotely while this problem exists.

Another thing - there are over 200 open bugs on network manager, and I was unable to find one that was clearly linked to the issue you described. So if you could give me a couple relevant bug numbers to track, that would be great.

[Mark Brown (broonie)]

Hrm. I can't find any of the relevant bugs in Network Manager either so I've added Network Manager to this bug.

[ben hall (benjamin-hall)]

The above workaround didn't work for me (-no-ping), and this is a show stopping bug for gutsy in my lab environment (mostly a mixture of dapper and feisty workstations, using NIS). I've two workarounds; one is to manually reload autofs on start, but this is impractical for the number of workstations in use. The other is to turn off roaming on my wired connection and set it manually to use DHCP. I've three boxes effected by this bug, and I'll test the other two ASAP and report back if it doesn't work for them.

[Mark Brown (broonie)]

The above workaround will only help with NIS - things using NIS will need additional work. If you are distributing your autofs master map via NIS you could try distributing it statically and only use NIS for the main maps - that might help and the master map normally doesn't change too often. That should allow autofs to at least start before the network.

[James R. Phillips (james-r-phillips)]

The machine with this problem is not a master in my home setup - the master is a headless server/router running debian etch. So distributing maps is not an issue, I just need to attach to the domain.

I have a workaround though - I simply added "/etc/init.d/nis restart" as a line in /etc/rc.local. Neither of the suggested arguments in YPBINDARGS worked for me.

[Mark Brown (broonie)]

Master maps are important client side for autofs users - if autofs starts up while unable to obtain the master map it may decide that there are no NIS maps availiable and therfore never try to use them even when they come on-line. If you are not using autofs then this subthread is irrelevant.

[István Váradi (ivaradi)]

I had the same problem since upgrading to Gutsy. The problem seems to be that the dhcdbd (some DHCP daemon) is started after NIS and autofs, so the interface has no chance to come up before init attempts to start NIS. One solution seems to be to start dhcdbd earlier, i.e. rename S24dhcdbd to S13dhcdbd in /etc/rc2.d. It seems to work for me.

Another solution may be to uncomment the "iface ethX inet dhcp" (or similar) line in /etc/network/interfaces, but I have not tried that one.

[Mark Brown (broonie)]

István Váradi: Yes, that's exactly the problem: Network Manager reports the interface as up before it is actually up.

[Basilio Kublik (sourcercito)]

Hi there
do you still experience this issue with the current version of the application?, could you please try to reproduce this using the live environment of the Desktop CD of the development release - Hardy Heron.

Thanks in advance

[James R. Phillips (james-r-phillips)]

Hm, well I tried. But I need to actually do an install in order to test
it. That is, I need to install, configure NIS, then boot to test.

But there is a rub. I can't install from the Live CD, because I use
LVM, which isn't supported. I have to use the alternate install, which
isn't available yet. So I have to wait until it is. Sorry. I'll test
as soon as an alternate install CD is available.

Basilio Kublik wrote:
> Hi there
> do you still experience this issue with the current version of the application?, could you please try to reproduce this using the live environment of the Desktop CD of the development release - Hardy Heron.
>
> Thanks in advance
>
> ** Changed in: network-manager (Ubuntu)
> Importance: Undecided => Low
> Assignee: (unassigned) => Basilio Kublik (sourcercito)
> Status: New => Incomplete
>
>

[James R. Phillips (james-r-phillips)]

OK, I found a different machine that doesn't use LVM, and was able to complete an install, then set up nis. While I didn't set up a nis login, I was able to use ypcat after a clean reboot, and a local login. So apparently all is well.

This was using the daily build posted on 3/21. Daily torrents would be nice - it took about 6 hours to download via http.

RE installing from the live CD, I changed several mount points during partitioning from "/media/x" to "/mnt/x", which is my preference for hard drive partitions. The installer created correct entries in "/etc/fstab", but _didn't_ create the requested mount points in the root file system. This appears to be a bug, not just an annoyance.

Writing over the MBR without a warning is annoying, but maybe not a bug, since at least it does scan for other OS installs and creates boot options for them. This is another reason why I generally use the alternate install (in addition to the LVM support issue).

[Brent Nelson (brent-phys-deactivatedaccount)]

I am seeing this issue on a fresh Hardy amd64 install. ypbind is actually failing to register with portmap, even though portmap started significantly earlier (nis startup is S18 in rc2, while portmap seems to be starting as S43 in rcS; curiously, portmap is also listed as S17 in rc2, but that's not what actually starts it). Other things started a little later (NFS) do register with portmap.

However, if I add nis to rcS after portmap (S46), it works. It seems like something in-between is causing a temporary disruption (could be NetworkManager, although I have a static IP configured in /etc/network/interfaces).

[Paul Smith (psmith-gnu)]

I believe this bug is fixed in Hardy. There's a new version of NIS's ypbind that uses dbus to connect to networkmanager and doesn't bind until after the network interface is brought up.

Once I modified my /etc/yp.conf to use an IP address instead of a hostname (I know the comments there say you should, but before networkmanager it used to work fine to have a hostname, because DNS was always running as soon as dhcp configured the interface, which always happened before NIS was started) I was able to boot and have nis started properly.

However, this is not the end of the story, although I will open other bugs for the rest. There are still other facilities on a typical enterprise desktop that rely on NIS (in particular I'm thinking of autofs here) which FAIL TO START in Hardy, because of this fix. Yeesh.

[Mark Brown (broonie)]

dbus/network manager integration is not new in Hardy - it has been present for several Ubuntu releases with the NIS side of the code unchanged. Many of the problems experienced in this area have stemmed from Network Manager providing inaccurate information about the state of the interface (these have now mostly been resolved, as far as I can tell).

System wide there are (as you say) still big problems with the lack of integration of this bit of the stack into upstart or some other dependency based startup mechanism.

[Paul Smith (psmith-gnu)]

Hm, that's interesting. Because when I turned of NetworkManager in past releases, NIS just worked fine. In Hardy beta, when I turn of NetworkManager NIS never comes up; I assumed that was because it was listening on dbus for NetworkManager to tell it the interface was available. I had to add the -no-dbus flag to YPBINDFLAGS in /etc/default/nis to get NIS to start working again.

Is THAT a bug, then?

Really, I think all the need to continually internalize GNU/Linux specific features like dbus and networkmanager into portable, generic, veteran tools like NIS and automount shows that we're going the wrong way. Maybe, as you say, the solution is to integrate upstart with networkmanager/dbus, then fix these tools to use upstart instead of sysv init, and keep the dependency external that way.

Another option, that might be simpler, would be to create some kind of command-line interface to dbus/networkmanager, so that we could wrap a script or program around the startup of these network services that would wait for the proper events then start them up. It would be a generic utility so it could be used for ANY tool, without having to modify them all one by one. Is there a Perl or similar interface to dbus?

It just annoys me that we seem to be marching full speed into a networkmanager-controls-the-universe world, without really considering everything that is impacted by this. Sure, it's great for laptop users but what about the rest of us? But I suppose this bug report isn't the place to discuss that.

[Mark Brown (broonie)]

Yes, that's a bug - if you ever need to specify -no-dbus to NIS it indicates a problem. See the earlier comments in this bug for diagnostic suggestions.

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

[David Munro (dhmunro)]

Sorry -- I intended to attach the above comment to bug #224828; I apologize if it's completely unrelated.

[Alain Baeckeroot (alain-baeckeroot)]

Confirmed on Hardy

need to modify /etc/default/nis and add --no-dbus options to have it at boot time:
# Additional options to be given to ypbind when it is started.
YPBINDARGS=-no-dbus

[doyston (r-a-sanderson)]

This bug has caused me a lot of confusion; on some machines the YPBINDARGS=-no-dbus worked, on others it did not. Moving the positions of startup scripts provided inconsistent results. It does not seem to be a NIS bug at all, but is something to do with NetworkManager taking too long to start (confirmed by putting a call to nm-tool in /etc/rc.local). The only consistent solution for me was to follow a trick in a NetworkManager posting on bug #50430 to put a file containing the two lines:

#!/bin/sh
invoke-rc.d --quiet nis restart &

into /etc/network/if-up.d

This has been a show-stopper of a bug for me until now, but I'm eager to upgrade to 8.04LTS, and with support for 7.04 expiring this month had been desperate to change. Unsurprisingly, users would not budge until they could login to their PCs after a reboot. I'm not a computer expert at all and therefore has taken me a while to sort out a workaround, and am surprised that this crippler of a bug seems to have an importance of "low". It has been sufficiently serious for some of our users to give up with Ubuntu and go to other distros.

[fil (fil-taz)]

this seems a duplicate of #50430.

shortcutting NM by configuring your interface "the old style" in /etc/network/interfaces should solve your problems for the time being.