NIS has problems starting before the network comes up

[Heiko]

Binary package hint: nis

in /etc/rcX.d there are the symlinks, but I can not log in with a nis User.
If I manually start /etc/init.d/nis from console with a local Account, after that I can log in with an NIS-account on Console and GDM.

This Bug appears after Update to Kernel -25. May be NIS starts to early, before the Network is running.

[Heiko (heiko-barg)]

The problem could be resolved with "dpkg-reconfigure nis".

[Chris Yoder (cyoder)]

What I am seeing with this is that the /etc/iniit.d/nis script will not start if the network is not up, saying that it will be handled in if-up.d

There is nothing to handle nis startup in if-up.d

[Mark Brown (broonie)]

Are you positive that you haven't modified the init script yourself? While there is code in the init script that will try to do that it is disabled since it is only partially implemented (as you have noticed).

[Chris Yoder (cyoder)]

Yes, I am positve that I have not modified the init script.

However, in the script I have, I find the following, which looks like it would do what we are talking about.

        #
        # If the network is not up yet, do not start ypbind.
        # We assume that /etc/network/ifup.d will start ypbind.
        # It doesn't matter if it already did.
        #
        network=`route -n | sed -ne '/^224/d' -e '/^127/d' -e '/^[0-9]/p'`
        if [ "$network" = "" ]
        then
                return 1
        fi

        return 0
}

do_start ()

It turns out that this was probably not the problem I was hitting ;), but still an issue.

The work around should be obvious, but in case it isn't, to disable the network check, just comment the if then segment of the code.

(The workaround is not for Mark, but for others who might see this later.

[Mark Brown (broonie)]

Notice that immediately before the block you quite there is another block:

        #
        # For now, we do not use the /etc/network/if-{up,down}.d
        # stuff yet. Not sure if it is useful for NIS or how
        # it should work, exactly.
        #
        return 0

which ensures that the check for network interfaces is never actually performed. This is true in the upstream Debian package and in version 3.16-1ubuntu3 which appears to be the latest in Ubuntu. I can't see anything which suggests that it has ever been enabled.

[Chris Yoder (cyoder)]

That's what I get for reading code on a Sunday when kind of tired.

[Johan Walles (walles)]

I *think* I'm having the same problem.

For some reason my network card is slow at coming up. Because of that, "/etc/init.d/nis start" gets run before the network is up. Then ypbind gives up with "localhost ypbind: Host name lookup failure", and I have to start it manually after boot :-(.

[Mark Brown (broonie)]

If it can't resolve localhost that suggests some other problem: it ought to be able to do that without the network.

[Johan Walles (walles)]

It's probably not localhost that cannot be looked up, thats just the format of the syslog(3) message. Here's the full line from my /var/log/user.log.0:
"
Feb 1 08:32:39 localhost ypbind: Host name lookup failure
"

[gmlion (gm-l)]

Is the bug still present in Feisty?

[Johan Walles (walles)]

Assuming I'm seeing the same problem as the original reporter, yes.

What happens during my boot sequence is (in order):
* network manager starts trying to get a dhcp address
* /etc/init.d/nis attempts to start but fails because the network isn't up
* network manager manages to get a DHCP address at the second attempt.
* I start /etc/init.d/nis manually, which works fine since the network is up.

Attempting to start NIS before the network is up doesn't work.

[Kyle Gordon (kylegordon)]

I am also encountering this issue on a fresh Feisty install. Restarting NIS resolves the issue.

[Kyle Gordon (kylegordon)]

Removing network-manager and dependencies resolves this issue. NetworkManager seems to let the system continue booting before the network is completely ready. Removing it cures it.

[Sebastian Stark (kybercran)]

It's funny. The same problem exists on Mac OS X Tiger: ypbind starts before the system received an IP from DHCP. Now Ubuntu joins the crowd.

I put the following in /etc/network/interfaces:

auto eth1
iface eth1 inet dhcp
up /etc/init.d/nis restart

This seems to help sometimes.

[Dag-Erling Smørgrav (dag-erling)]

The NIS failure is obviously highly visible since it does not fail gracefully (i.e. it will not magically fix itself once the network is up) and it prevents you from logging in, but this is not just a NIS issue; it affects anything that requires a working network connection and / or DNS to start (NTP; LDAP; autofs, if you use NIS or LDAP maps). I use the following hack in /etc/rc.local:

echo -n "Waiting for network to come up..."
while :; do
        nm-tool | egrep -q 'DNS:[[:space:]]+[1-9]' && break
        sleep 1
        echo -n "."
done
echo " OK"

/etc/init.d/ntp restart
/etc/init.d/nis restart
/etc/init.d/autofs restart

Just checking for an IP address will not work, because nm-tool reports a valid IP address almost immediately, but it takes almost a minute for DNS to show up. I have no idea why DHCP is so slow on this network.

[Mark Brown (broonie)]

In the case of NIS all you need to do is edit /etc/default/nis to ensure that Network Manager integration is enabled (make sure the -no-dbus option isn't being passed to ypbind). If it still fails after that then there's a problem with Network Manager. With Network Manager integration enabled ypbind will only attempt to discover a server if Network Manager reports that the network is on-line.

[Johan Walles (walles)]

Attached my /etc/default/nis. It doesn't say anything about Network Manager integration. No options seem to be passed to ypbind AFAICT.

Mark, how do I edit it to ensure Network Manager integration is enabled?

[Mark Brown (broonie)]

If it's not explicitly disabled and you're running version 3.17-1 or later then it is enabled - if Network Manager is running then ypbind should pay attention to it.

[Dag-Erling Smørgrav (dag-erling)]

Once again, this is *not* a NIS problem, it is a NetworkManager problem that affects far more than NIS. I do not have -no-dbus in /etc/default/nis.

[Dag-Erling Smørgrav (dag-erling)]

One thing that just occurred to me, could this be caused by interoperability issues between NetworkManager and the specific NIC driver being used (tg3 in my case), as in this report of a similar problem which was fixed by switching drivers: https://bugs.launchpad.net/network-manager/+bug/38586

[Johan Walles (walles)]

Mark, I'm running nis 3.17-2ubuntu2. You have my config file, feel free to have a look. I am having problems.

I *think* this violates your hypothesis. Please clarify if you think otherwise.

  Regards //Johan

[Mark Brown (broonie)]

Dag-Erling: The point here is that the Network Manager integration in NIS (which is disabled by default) is supposed to work around these issues by doing something very similar to what the script fragment you posted does. This means that NIS is affected by only a subset of the problems that affect the system in general - usually only those where Network Manager reports a connection status that does not correspond to reality.

Without something like that there is a general issue many services have with Network Manager independently of any bugs in Network Manager.

Johan: It mostly eliminates the problem that causes 90% of these issues but unfortunately it doesn't tell us what went wrong.

Could one or both of you please insert something into the bind wait loop in /etc/init.d/nis to log the output of nm-tool while it is probing (eg:

               for i in 1 2 3 4 5 6 7 8 9 10
                do
                        /usr/bin/nm-tool >> /tmp/nm-tool-log # ADDED LINE
                        sleep 1
                        log_action_cont_msg "."

) and then also log the output of nm-tool when you are able to restart NIS succesfully. If Network Manager is reporting bad information this should confirm it; it may also show that NIS is paying attention to the wrong information from Network Manager.

[Dag-Erling Smørgrav (dag-erling)]

See the attached log. The first ten or so instances are from /etc/init.d/nis in the normal startup sequence. The second-to-last instance is from the beginning of /etc/rc.local. The final instance is from /etc/rc.local immediately before /etc/init.d/nis is run again (successfully).

Note that ypbind doesn't seem to notice that anything's wrong until it fails to resolve the address of the NIS server, at which point it exits.

When doing this manually, before I set up the wait-for-DNS-to-come-up loop in /etc/rc.local, I often saw nm-tool report an IP address but no gateway or DNS.

[Mark Brown (broonie)]

Dag-Erling: It looks like you're right and Network Manager is confused on your system. Even in the last entry in the log you have there it reports:

| State: connecting

rather than reporting that it is in the connected state. The ypbind code triggers on the connected state so if Network Manager isn't reporting that it'll get confused. I'd suggest filing a bug against Network Manager if there isn't already an appropriate one.

Network Manager also reports

| IP Address: 0.0.0.0

which doesn't bother ypbind but is likely to be part of the confusion.

[Andre Costa (blueser)]

Hi,

I just upgraded to gutsy and this annoying bug has also bitten me. Fortunately I found a simple workaround somewhere else (can't remember where =( ) that worked for me, and only messes with the real culprit AFAICS: if you disable NetworkManager's "roaming mode" and force "Automatic configuration (DHCP)" autofs starts up just fine when the system boots.

HTH

Andre

PS: to edit NetorkManager's properties, just go to System > Administration > Network, choose "Wired connection" on the "Connections" tab and then click on "Properties".

PPS: of course these instructions assume you use a wired connection.

[Morten Kjeldgaard (mok0)]

If you have a stationary workstation setup, with NIS, autofs, fixed IP numbers etc. you are better off removing network-manager altogether.

I've had several of the problems above, and they magically disappeared when I did this:

apt-get remove network-manager

It removes a number of GUIs as well, but if your network connections are fixed you don't need them.

[Ted Cabeen (ted-cabeen)]

I can confirm this bug still exists in hardy, and the workaround of removing network-manager does fix it.

[Mathi (mathiraj)]

I too can confirm the problem. nis starts before network is fully up and times out. It would be great if this bug is fixed and the functionality works out of the box without having to remove network manager.

I also have a problem with automounter not mounting my home directory. I had to create my own /etc/auto.home (This happens only with 8.04 and with previous versions the automounter used to work fine)

[Johan Walles (walles)]

I just upgraded to Hardy (on a new machine, so settings might have changed), and the workaround in comment 14 does not work for me any more.

However, putting an executable file with the following contents in /etc/network/if-up.d works:

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

[xcorex (xcorex)]

I too can confirm the problem.

Hardy 64

[jhaig (josephhaig)]

I know this isn't specifically a NIS problem, as someone has already mentioned, but the NIS issue causes auto logins to fail. Johan's hack appears to fix it for me (thanks, Johan).

[Dag-Erling Smørgrav (dag-erling)]

If you use NIS-distributed autofs maps, you need to restart autofs as well - *after* you've restarted NIS.

[Russel Winder (russel)]

It seems that after 2.5 years, we are no nearer having NIS work properly during boot. Intrepid tries 11 times to start NIS and fails -- this takes up a long time, trippling or quadrupling boot times.

Once booted NIS appears to be working fine.

Assuming you are on a laptop and not a workstation, Network Manager fails to run dhclient on my workstation, I have to do this manually after boot. NIS starts fine straight away.

I thought the whole point of Network Manager was to remove problems with networks not create them :-(

[Stefano Forli (ntropia)]

Apparently, the problem is not limited to NIS, but if there is no user logged with the greeter, none of the network services (i.e. ssh, nfs) seems to run properly.

Call it "feature", but I consider it a critical bug, since activating the network manually with the init.d commands doesn't help.

This is way *more* than annoying.
Having to remove the package to fix it means that something went lost in the design process.

[Stefano Forli (ntropia)]

Addenda: forgot to mention, I'm running Ibex with both default kernel and default installation.

[Desert Penguin (jtbock-daylight)]

My problem system: Dell Dimension E521, 2GB ram, AMD 64x2 5000+

I had this problem (nis failed to start, which cascaded to autofs not being able to read the yp auto.home map) in 8.04, but just worked around by restarting nis and autofs after system was up.

I upgraded (via a complete reinstallation) to 9.04 (amd64) earlier this week. The nis problem is now much more severe, at least for me. If nis is enabled, the system will take a very long time to boot and (possibly) never fully come up. The first problem is the same nis issue...starting nis fails. After trying to ypbind 10 times, the boot process then hangs a couple of lines later when it reaches hald. It stays at hald for a long time (10 minutes?). After making it past that, things seem to proceed normally until it tries to switch back to graphics and display the login screen. The mouse is visible (but not movable) on a whitish background. Maybe it would eventually come up, but I've never waited longer than 15 minutes or so.

One can ctl-alt-f2 and login with a local account, which takes a couple of minutes. Moving around via the command line seems mostly ok, but "sudo" anything, and you are going to be waiting minutes for the password prompt. And the gui, back on f7, never seems to change from its whitish background.

Starting nis once the system is up is fine, but the trick is actually getting the system to usable state.
So now, reboots are somewhat more complicated, as I have to disable nis, reboot, and then enable and start nis once the system is up. I haven't tried moving nis (and thus autofs) to later in the boot sequence to see if that would help.

[fil (fil-taz)]

Same old problem on a fresh 9.04.

It boils down to: ypbind is tried at S18nis, NetworkManager starts a lot later at S28NetworkManager. IP connectivity often isn't up after S99, at least if using DHCP.

The problem disappears after configuring the old way via /etc/network/interfaces , thereby shortcutting NetworkManager.
Looks like NM introduced having network only a lot later in the startup process; Should affect other network-dependent services similiarly.

ypbind's NM integration does not help at all as long NM isn't yet running while it is started (see ypbind manpage).
i.e. -no-dbus does not make any difference here...

Fix it by having ypbind started after NM without -no-dbus, or via /etc/network/if-up.d/ to ensure we already have net.
In case of NIS passwd this creates the possibility of having a temporarily unfunctional login prompt shown, so some user feedback about network connectivity should be introduced there.

The startup sequence currently delivered with nis is generally incompatible with Ubuntu Desktop's reliance on NetworkManager for bringing up IP connectivity. One of three things needs to happen:
* rework nis startup sequence + handle possible login deferral, or
* return to using /etc/network/interfaces at least for some primary interface, or
* move nis from main and regard it unsupported

g., Filip Moritz

[fil (fil-taz)]

or, solution #4
* add some package "legacy-network" or the like, that re-introduces /etc/network/interfaces config. Let nis, autofs and the like depend on this one. Traditional unix concepts require having network up early. Don't twist them all, instead satisfy their need.

[Alex F (frase)]

It seems like the problem is NetworkManager botching its role in the boot process. It's supposed to bring the network up at S28, but starting almost three years ago with this bug and yet today on a fresh 9.04 install, the network is not even up by S99 for rc.local.

Can NetworkManager please be fixed? It's been awhile now.

[darylb (darylblanc)]

Is this still the case even with "System setting" (renamed to "Available to
all users" in jaunty) and "Connect automatically" both checked?

On Tue, May 19, 2009 at 2:19 PM, Alex F <email address hidden> wrote:

> It seems like the problem is NetworkManager botching its role in the
> boot process. It's supposed to bring the network up at S28, but
> starting almost three years ago with this bug and yet today on a fresh
> 9.04 install, the network is not even up by S99 for rc.local.
>
> Can NetworkManager please be fixed? It's been awhile now.
>

[Alex F (frase)]

> Is this still the case even with "System setting" (renamed to "Available to
> all users" in jaunty) and "Connect automatically" both checked?

Yes. In my case it isn't NIS that's affected however, but rather my network mounts which are run from rc.local. They never work at boot (and if I log their output, it says they can't resolve or route to the mounts' hosts); they work just fine after boot (by which time the network is actually started, which IIUC should have been true after S28NetworkManager and long before S99local).

[Paul Smith (psmith-gnu)]

S28NetworkManager simply requires that networkmanager be started. That does NOT guarantee that you have an active network connection. The whole idea behind NM is that it will manage network connection and disconnect for the system, behind the scenes.

What's happening here is that NM comes up and starts trying to bring the network up in the background. In the meantime the init process continues along to the next item to be started.

This is the major paradigm shift that NM brings in, but unfortunately it requires that every network service be rewritten to be NM-aware and use dbus so that they can delay starting up until NM tells them the network is available. If they don't do that then there is no way your system can be robust while using NM.

ypbind has been modified to speak NM, so as long as NM is properly reporting the network connection status for your system (apparently this is quite difficult to get right, for whatever reason) then NIS should be working OK at this point.

However, other network services, most notably autofs (see for example bug #213574 ), do not speak NM, even today (years after it was introduced). So, NM still breaks many enterprise systems.

[Rorschach (r0rschach)]

@Paul: I can confirm the problem with nis and NM on Ubuntu Jaunty so I don't think that problem is already solved.

[Chuck Short (zulcss)]

Hi,

I was wondering if this is still a problem on karmic?

Regards
chuck

[MattW (seattle) (mbw)]

Chuck,

This seems to be working, but my box isnt a super clean test - its had
upgrades from earlier revs and I cant
remember if I moved the /etc/rc2.d startup script #'s around... can you
tell if this is the stock order of init scripts?

testu1@lucky:/etc/rc2.d$ ls -la
total 20
drwxr-xr-x 2 root root 4096 Oct 5 13:47 .
drwxr-xr-x 149 root root 12288 Oct 13 11:21 ..
-rw-r--r-- 1 root root 677 Oct 2 06:57 README
lrwxrwxrwx 1 root root 19 Aug 12 14:22 S01policykit ->
../init.d/policykit
lrwxrwxrwx 1 root root 14 Aug 12 14:22 S10apmd -> ../init.d/apmd
lrwxrwxrwx 1 root root 18 Aug 12 14:22 S10sysklogd ->
../init.d/sysklogd
lrwxrwxrwx 1 root root 15 Aug 12 14:22 S11klogd -> ../init.d/klogd
lrwxrwxrwx 1 root root 13 Aug 25 14:56 S16ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 13 Aug 12 14:42 S18nis -> ../init.d/nis
lrwxrwxrwx 1 root root 16 Aug 12 14:42 S19autofs -> ../init.d/autofs
lrwxrwxrwx 1 root root 17 Sep 14 11:55 S20couchdb -> ../init.d/couchdb
lrwxrwxrwx 1 root root 28 Aug 27 12:34 S20dkms_autoinstaller ->
../init.d/d

if it is the same as a default karmic install, then I think the bug is
fixed.

if I have time, I could do a fresh karmic install and test - which ISO
would you like me to use to test this?
thanks for checking in...

BTW: Karmic Xorg server has been really nutty lately... thats my current
problem. Just logged a bug. :)

Matt

Chuck Short wrote:
> Hi,
>
> I was wondering if this is still a problem on karmic?
>
> Regards
> chuck
>
> ** Changed in: autofs (Ubuntu)
> Importance: Undecided => Low
>
> ** Changed in: autofs (Ubuntu)
> Status: New => Incomplete
>
>

[fil (fil-taz)]

I assume there's a conceptual bug, not to fix in any single package: NetworkManager is basically incompatible with sysV init. This also applies to "sysV powered by upstart". Unless a consistent event-driven model is in place NetworkManager may be fine for the occasional network-hopping Laptop but stays bogus on any centrally-managed corporate network. Just don't use it there yet. For the time being dependencies should be fixed: Install nis or kin -> purge nwm.

Even then: The idea behind nwm is to flexibly handle failures or delay of non-essential services. There's no flexibility in handling missing user-maps or other name-service. On my OSX Desktop I regularly get a login prompt refusing my nis credentials since booting the shell overtook setting up the network. Three failures gave me some early coffe and newspaper befor I realized the cause. The only sensible way here would be to tell the user what we're waiting for. Another package to be hacked.

For the new era to dawn we have to look into service dependencies from a higher level. Guess here's the limitation of a per-package bug-tracking approach. And I'd agree to favour wrapping over fixing. Shouldn't be autofs's burden what new concepts nwm or upstart make up.

g., fil

----- "Paul Smith" <email address hidden> schrieb:

> *** This bug is a duplicate of bug 50430 ***
> https://bugs.launchpad.net/bugs/50430
>
> On Tue, 2009-10-13 at 18:16 +0000, Chuck Short wrote:
> > *** This bug is a duplicate of bug 50430 ***
> > https://bugs.launchpad.net/bugs/50430
> >
> > ** This bug has been marked a duplicate of bug 50430
> > NIS has problems starting before the network comes up
>
> Why has this bug been marked as a duplicate of 50430?
>
> 50430 talks about NIS (ypbind) not working properly on NetworkManager
> enabled systems. That should be fixed for a few releases now, and
> indeed I haven't seen it on my systems in a while. My suspicion is
> that
> the people who are still having trouble are really having problems
> with
> NetworkManager not detecting/reporting the network status of their
> systems properly (saying the network is up when it isn't or vice
> versa).
>
>
> This bug (213574) is about autofs not working properly on
> NetworkManager
> enabled systems. That is basically the same problem, but a
> completely
> different package (in fact that's my major complaint about
> NetworkManager: adding it to your system requires that you go around
> and
> hack on each network-aware service on your system, one at a time, to
> make them compatible with NetworkManager).
>
> I've not upgraded to Karmic but I've seen absolutely nothing that
> leads
> me to believe anyone has made any effort to enhance autofs, either
> the
> daemon itself (a la ypbind) or even just the init scripts, to be
> NM-aware. Until that happens this bug will not be fixed.
>
> What has to happen on a very abstract level is that you can't start
> autofs until all the services that it utilizes (based
> on /etc/nsswitch.conf for example) are running, if they are supposed
> to
> be started. It's hard because on many systems, /etc/nsswitch.conf
> lists
> "nis" or "nisplus" as a source for automount, and yet these ...

[abc_echo (siren442-gmail)]

vagrant@vagrant-laptop:/etc/init.d$ sudo /etc/init.d/nis start
sudo: unable to resolve host vagrant-laptop
 * Starting NIS services
 * binding to YP server...
 * ....
 * ....
  * ....
 * ....
 * ....
* ....
 * ....
* ....
* ....
 * .... [fail]
                                                                                [ OK ]

OS: Ubuntu9.10 karmic
software version: nis_3.17-25ubuntu1_i386.deb

Could anyone have a workaround fix?
Thank you very much, Amen....
I've searched related possible resolutions for the whole day. : '(

[Russel Winder (russel)]

The workaround for this is well known but is not really explained anywhere in any one place; there are comments on all the bugs related to this one (especially 354588) and also in the Ubuntu forums. What is comes down to is the ordering of startup of NIS and NetworkManager. If NetworkManager is allowed to start after NIS then NIS takes ages to time out hence the boot delay. If NIS is started after NetworkManager then NIS still fails to start properly at this time but its time outs are much quicker and so there is no noticeable delay in booting. NIS binding still completes correctly once NetworkManager completes its boot up later in the cycle.

So the workaround had to rearrange the boot order. In particular to reset the start number of NIS to 60 -- something sufficiently after 50 (the start number of NetworkManager) that things work. So if you use the services manager tool:

    System | Administration | Services

You unlock the settings then check the properties of NIS and reset the start number for all active run levels to something bigger than NetworkManager. In my case I chose 60.

I have no idea how the changes is boot system coming with Karmic will affect all this. Given that the problem has existed for years and whilst confirmed no real fix has been made, I fully expect the upgrade from Jaunty to Karmic to result in total chaos requiring manual fixing by the user -- again.

OK so I am grumpy, but this problem has been known for over 3 years and not been properly addressed by the Ubuntu team.

Let us hope my fears do not come to fruition.

[Sean Whitney (sean-whitney)]

 System | Administration | Services

That's all nice and good, but with the conversion to Upstart in karmic, this doesn't apply anymore. Anyone have a more "karmic" solution?

Sean

[Johan Walles (walles)]

Has anybody managed to work around this on Karmic?

I just upgraded to Karmic, and my previous workaround is no good any more, and I now have to (re)start NIS manually at each boot :-(.

Also, the top of the bug page says "This bug affects you and one other person". Considering the amount of people subscribed to this that doesn't sound reasonable, please mark the top of the bug page if you're affected!

[fil (fil-taz)]

Johan, unless you use NIS on an laptop I recommend to deinstall network-manager and use the old style /etc/interfaces configuration. At least this works for me. Don't have the respective machine at hand right now, so I'm not 100% sure if it is karmic already but I positively think so.

g., fil

----- "Johan Walles" <email address hidden> schrieb:

> Has anybody managed to work around this on Karmic?
>
> I just upgraded to Karmic, and my previous workaround is no good any
> more, and I now have to (re)start NIS manually at each boot :-(.
>
> Also, the top of the bug page says "This bug affects you and one
> other
> person". Considering the amount of people subscribed to this that
> doesn't sound reasonable, please mark the top of the bug page if
> you're
> affected!
>
> --
> NIS has problems starting before the network comes up
> https://bugs.launchpad.net/bugs/50430
> You received this bug notification because you are a direct
> subscriber
> of the bug.
>
> Status in “autofs” package in Ubuntu: Confirmed
> Status in “network-manager” package in Ubuntu: New
> Status in “nis” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: nis
>
> in /etc/rcX.d there are the symlinks, but I can not log in with a nis
> User.
> If I manually start /etc/init.d/nis from console with a local Account,
> after that I can log in with an NIS-account on Console and GDM.
>
> This Bug appears after Update to Kernel -25. May be NIS starts to
> early, before the Network is running.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/50430/+subscribe

[MattW (seattle) (mbw)]

I will second the recommendation to remove network-manager... I also
have had success in earlier revs of ubuntu
in re-ordering the startup scripts so that NIS starts before autofs...
dont remember if I had to do that in Karmic or not.

This problem has been around a while now on various ubuntu and other
linux distros. Network manager gets in
the way in a fixed-ip "corporate" environment. On the other hand, NIS is
a real pain if you are getting and releasing IP addresses
frequently on a wireless LAN, which I believe is now a more frequent
user scenario than a corporate scenario...

Matt

On 1/4/10 7:28 AM, fil wrote:
> Johan, unless you use NIS on an laptop I recommend to deinstall network-manager and use the old style /etc/interfaces configuration. At least this works for me. Don't have the respective machine at hand right now, so I'm not 100% sure if it is karmic already but I positively think so.
>
> g., fil
>
>
> ----- "Johan Walles"<email address hidden> schrieb:
>
>
>> Has anybody managed to work around this on Karmic?
>>
>> I just upgraded to Karmic, and my previous workaround is no good any
>> more, and I now have to (re)start NIS manually at each boot :-(.
>>
>> Also, the top of the bug page says "This bug affects you and one
>> other
>> person". Considering the amount of people subscribed to this that
>> doesn't sound reasonable, please mark the top of the bug page if
>> you're
>> affected!
>>
>> --
>> NIS has problems starting before the network comes up
>> https://bugs.launchpad.net/bugs/50430
>> You received this bug notification because you are a direct
>> subscriber
>> of the bug.
>>
>> Status in “autofs” package in Ubuntu: Confirmed
>> Status in “network-manager” package in Ubuntu: New
>> Status in “nis” package in Ubuntu: Confirmed
>>
>> Bug description:
>> Binary package hint: nis
>>
>> in /etc/rcX.d there are the symlinks, but I can not log in with a nis
>> User.
>> If I manually start /etc/init.d/nis from console with a local Account,
>> after that I can log in with an NIS-account on Console and GDM.
>>
>> This Bug appears after Update to Kernel -25. May be NIS starts to
>> early, before the Network is running.
>>
>> To unsubscribe from this bug, go to:
>> https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/50430/+subscribe
>>
>

[Johan Walles (walles)]

NetworkManager can't be uninstalled without uninstalling "ubuntu-desktop" as well :-(.

Filed bug 503264 about that.

[Vincent Fortier (th0ma7)]

got a really ugly fix that make nis finally working... at this to your /etc/rc.local :

while [ ! "`/bin/pidof ypbind`" ]
do
   /etc/init.d/nis restart
   sleep 2
done

exit 0

that should do it!

[Paul Smith (psmith-gnu)]

Here's what I use. This works for me in 10.04 (and below) but I haven't tried it with 10.10 yet.

It sure as heck would be nice if someone paid a little attention to this bug.

Save this as "reautofs", then follow the directions in the comments.

#!/bin/sh
#
# Stupid NetworkManager doesn't wait for NIS to start before starting
# autofs, so we have no maps. Restart it.
#
# Install with:
# sudo cp ~/Downloads/reautofs /etc/init.d
# sudo update-rc.d reautofs defaults 99
#
#
# Author: Paul Smith <email address hidden>

start () {
    nohup /bin/sh -c '
        while true; do
            ypwhich && break;
            sleep 1;
        done;
        /etc/init.d/autofs restart
    ' </dev/null >/dev/null 2>&1 &
}

case $1 in
    start) start ;;
    *) : no op ;;
esac

[gwir (gwir)]

Hello,

This is the script i'm using :

/etc/network/if-up.d/net_is_configured :

#!/bin/sh
# Testing if network is up before continuing
network=`route -n | sed -ne '/^224/d' -e '/^127/d' -e '/^[0-9]/p'`;
timeout=0
while [ "${network}" = "" ] && [ ${timeout} -le 20 ]
        do network=`route -n | sed -ne '/^224/d' -e '/^127/d' -e '/^[0-9]/p'`;
        echo -n ".";
        timeout=$((${timeout} + 1));
        sleep 1;
done
if [ ${timeout} -ge 20 ];then
        echo " Pas de connexion réseau";
else
        echo " Done";
fi

Hope this will help you

[Claudio Bernardini (claudiob)]

Solution suggested by gwir above does not solve the problem on Natty 11.04.
I still need to restart autofs by hand to get access to my NFS remote home directories and so to my Ubuntu desktop.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thomas Hood (jdthood)]

Is anyone still having this problem in Ubuntu 12.04?

[Thomas Hood (jdthood)]

Should be fixed in Ubuntu 12.04 after moving to Upstart.