autofs does not start automatically after reboot

[Thomas Schweikle]

After rebooting and logging in, I am prompted with "no home for user. logging in with /". looking for a running autofs I find it not started. Executing "sudo service autofs start" starts autofs. After "cd ~" my home is mounted and available.
This error is erratic, but only on 12.04 systems. 10.04.4 LTS, 11.04, or 11.10 are not affected.
AFAICD autofs is sometimes started by upstart without the necessary services running (mainly DNS, just because Networking is not completely up) making autofs bail out. Starting it later it finds all necessities and starts.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: autofs (not installed)
ProcVersionSignature: Ubuntu 3.2.0-24.39-virtual 3.2.16
Uname: Linux 3.2.0-24-virtual x86_64
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Fri Jun 1 08:16:46 2012
InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2)
ProcEnviron:
 TERM=xterm
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: autofs5
UpgradeStatus: Upgraded to precise on 2012-04-12 (49 days ago)

[Clint Byrum (clint-fewbar)]

Hi Thomas.
 been b
autofs5 starts when runlevel 2 is reached.

This means that it starts after any network connections that are configured in /etc/network/interfaces have been brought up. That would include DNS configurations of any kind that a server would have.

If, however, you have configured your server's networking with something else, like network manager, or conman, its possible that the networking from those services was not up yet, leading to difficulties doing DNS lookups.

Can you confirm that your setup only uses /etc/network/interfaces to configure network/DNS?

[Thomas Schweikle (tps)]

Yes, I can confirm my servers setup doesn't use network manager or conman.
Sometimes autofs is started, sometimes it is not. It seems to depend on how fast the network interfaces are up – if they are up before autofs tries to get names resolved by DNS all is OK and autofs starts. If not, it fails and will not start. With upstart this time depends on which services are started and when. There is no prediction any more which service starts before which other and thus it maybe autofs starts (seldom) or not (most).

[Clint Byrum (clint-fewbar)]

Thomas, with Ubuntu 11.10 and later, there is a guarantee that all of the "auto" interfaces have been brought up before runlevel 2 is reached (or after 2 minutes of waiting for said interfaces has passed). This is controlled by if-up.d scripts, which are only called after the interface has been configured. This means it has an IP, its DNS settings have been applied, and any gateways mentioned have been assigned.

Now, if you have configured DNS to point at a local DNS cache, that may be the issue. I would recommend having your DNS cache service do this:

start on starting rc RUNLEVEL=[2345]

That will ensure that it is started before any other runlevel [2345] services are started.

[Thomas Schweikle (tps)]

This problem is fixed now. Seems like dnsmasq is started this way jet, making sure it starts before any other service depending on dns is started.

[Clint Byrum (clint-fewbar)]

Thanks Thomas, so does that mean that the bug is solved for you?

[Kevin Phillips (kevin-grenville-phillips)]

I have encountered this too while trying to put together an image for 12.04.1 LTS kernel 3.2.0-31-generic. Same premise, upstart fails to correctly initialize autofs (5.0.6-0ubuntu5) on boot because of ypbind wait-for-state issues but it doesn't seem to be related to dnsmasq (server is NOT managed by NM). It works after the autofs service is reset/reloaded post-boot. Here are my logs,

Some Interesting stuff in the boot log:
fsck from util-linux 2.20.1
fsck from util-linux 2.20.1
rpcbind: Cannot open '/run/rpcbind/rpcbind.xdr' file for reading, errno 2 (No such file or directory)
rpcbind: Cannot open '/run/rpcbind/portmap.xdr' file for reading, errno 2 (No such file or directory)
/dev/sda6: clean, 172583/61014016 files, 4655506/244044544 blocks
/dev/sda1: clean, 230/121920 files, 50217/487424 blocks
Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
 * Starting AppArmor profiles [ OK ]
speech-dispatcher disabled; edit /etc/default/speech-dispatcher
 * Starting VirtualBox kernel modules [ OK ]
 * Starting Waiting for state [ OK ]
 * VirtualBox Additions disabled, not in a Virtual Machine
 * Starting mDNS/DNS-SD daemon [ OK ]
saned disabled; edit /etc/default/saned
 * Starting bluetooth daemon [ OK ]
 * Starting crash report submission daemon [ OK ]
 * Starting network connection manager [ OK ]
 * Checking battery state... [ OK ]
 * Starting CUPS printing spooler/server [ OK ]
 * Stopping System V runlevel compatibility [ OK ]
 * Starting NIS binding process [ OK ]
 * Stopping Waiting for state [ OK ]
 * Stopping Waiting for state [ OK ]
 * Stopping Waiting for state [ OK ]
 * Stopping block processes that need ypbind [ OK ]
 * Stopping block processes that need ypbind [ OK ]
 * Stopping block processes that need ypbind [ OK ]
 * Starting LightDM Display Manager [ OK ]
 * Starting deferred execution scheduler [ OK ]

/var/log/syslog | grep autofs
Sep 25 17:16:31 $HOSTNAME kernel: [ 17.471221] init: wait-for-state (autofsypbind) main process (1103) killed by TERM signal

/var/log/upstart/wait-for-state-autofsypbind.log && /var/log/upstart/wait-for-state-atdypbind && /var/log/upstart/wait-for-state-lightdmypbind.log
start: Job is already running: ypbind

/var/log/upstart/ypbind
Setting NIS domainname to: $NIS_DOMAIN
Binding to YP server .....backgrounded
Setting NIS domainna...

[Kevin Phillips (kevin-grenville-phillips)]

I was able to circumvent this issue by removing the network-manager package and managing devices manually.

[Vidya Alankar (vidya-alankar)]

I encountered exactly the same issue encountered by Kevin including the contents of the log files, and worked around it the same way he did. Thanks, Kevin!

In my case NIS servers are not local. Could that have caused ypbind to get backgrounded?

Though that doesn't explain why it binds fine with network-manager out of the picture.

[Kevin Phillips (kevin-grenville-phillips)]

The issue seems to revolve around the upstart scripts, I attempted to rewrite sections of the scripts so that the service would start at later (higher) run level but to no effect. The issue is not with DNS resolution of the domain though. Something is wrong when network-manager initializes the interfaces. Personally I would prefer sysvinit over upstart. Disabling network-manager for desktops is a non-issue but it would be a show-stopping problem for laptops (managing wlan ifs by hand is plain stupid).

[Jeff Davis (jdavis-n)]

I have a similar issue, in my case it is related to ldap automount maps. We ran into this same issue in 10.04 and ended up adding a condition in the autofs upstart script to wait for a network connection, as well as in the gdm (now lightdm) upstart script.

Bottom line is that the autofs startup is happening before it should. Nothing I've tried in upstart seems to make a difference, and I have 80 netbooks to get out to students/teachers that require this functionality.

I concur with Kevin Phillips that uninstalling network-manager is a non-starter. Could be a reasonable band-aide for certain situations, but would fail miserably for mobile or wireless.

[Ernst Kloppenburg (ernst-kloppenburg)]

several people have commented that they have the same or similar problems

[Clint Byrum (clint-fewbar)]

So, I took another look at this problem. autofs5's upstart script is 'start on runlevel [2345]. This just means start on runlevel 2 in Ubuntu, because the others are not used.

Runlevel 2 is reached after all of the filesystems are mounted and any interfaces in /etc/network/interfaces are up (since 11.10 anyway, 10.04 would not wait for network interfaces).

It sounds to me like there are a bunch of local autofs dependencies that need to be started before it. I'm a bit puzzled as to why this really matters, because what if the LDAP or Kerberos server are not on the same box as autofs? You can't control that order at all, so IMO autofs should do a better job of not freaking out if it can't connect to these for a few seconds.

Anyway, there's a solution for this, which is to simply start the services you know you'll need in the pre-start of autofs5. I see that the debian sysvinit script does a 'Should-Start' on ypbind and nslcd. So by blocking the start until those start, if they are installed on the system, one can achieve this. For anything that is already an upstart job (ypbind is I think) you can add this:

start wait-for-state WAITER=autofs5 WAIT_FOR=nslcd

[Andreas Greve (andreas-greve)]

If the automounter daemon starts before the ypbind daemon is ready to answer queries than the automounter does not work for nfs mounts depending on nis (other mount types not tested), even if the ypbind daemon later gets ready.

There exists a race condition in ubuntu 12.04 between autofs.conf and ypbind.conf which leads to the above described problem.

The reason for that is that ypbind.conf sometimes lies about the state of the ypbind daemon. The post-start script in ypbind.conf terminates after 5 tries ( about 5 sec.) to contact the nis-server or when ypbind respawns and change its state to running. Upstart than kills the dedicated wait-for-state job. Now autofs.conf starts the automounter daemon but the ypbind daemon is not ready to work and the automounter does not work for nfs automounts too. I have to restart the automounter daemon manualy (stop autofs; start autofs) after the ypbind daemon is working to get nfs automounts working.

I solve the problem by changing ypbind.conf so that the "test loop" in post-start script only terminates when ypwhich is working.

Additional I add a parameter TIMEOUT=300 to the exec wait-for-state .... call in start-ypbind.conf because the default default timeout of 30 sec is to short for my network and leads to the above described problem.
OK the 5min time out is not a 100% resolution. For a 100% resolution of the race condition I have to set the parameter WAIT_FOREVER="T".

autofs.conf:
-------------------vvv snip vvvv----------------------------------
description "NIS binding process"
author "Steve Langasek <email address hidden>"

# Patterned after the statd.conf job in nfs-common.
start on (started portmap ON_BOOT=
          or (started portmap ON_BOOT=y
              and ((filesystem and static-network-up) or failsafe-boot)))
stop on stopping portmap or runlevel [!2345]

expect daemon
respawn
respawn limit 3 250

pre-start script
    NISSERVER=false

    [ -f /usr/sbin/ypbind ] && [ -f /etc/defaultdomain ] || { stop; exit 0; }

    [ -f /etc/default/nis ] && . /etc/default/nis

    oname=$(domainname)
    nname=$(cat /etc/defaultdomain)
    if [ "$oname" != "$nname" ]; then
        echo "Setting NIS domainname to: $nname"
        domainname "$nname"
    fi

    case $NISSERVER in
        master|slave|[Yy]*)
            ;;
        *)
            case $NISCLIENT in
                false|[nN]*)
                    { stop; exit 0; }
                    ;;
            esac
            ;;
    esac

    if [ "$NISSERVER" != false ]; then
        start wait-for-state WAIT_FOR=ypserv WAITER=ypbind WAIT_STATE=running >/dev/null
    fi
end script

script
    [ -f /etc/default/nis ] && . /etc/default/nis

    BROADCAST=-broadcast
    while read arg junk ; do
        case $arg in
            ypserver|domain)
                BROADCAST=
                ;;
        esac
    done < /etc/yp.conf

    exec ypbind $BROADCAST $YPBINDARGS
end script

post-start script
    # Give ypbind time to finish starting up, so that jobs depending on
    # it are actually able to use the maps
    echo -n "Binding to YP server "
    bound=
        #for i in 1 2 3 4 5
    while [ -z "${bound}" ]
 ...

[Pavel Rojtberg (rojtberg)]

#13 contained the fix for me. commenting out the following gave ypbind enough time to start so autofs correctly started as well

      #if status ypbind | grep -q start/respawn; then
      # # something killed ypbind; short-circuit here instead
      # # of continuing to try to call ypwhich, since that
      # # can take more than a minute.
      # break
      #fi

[Florido Paganelli (bjaast)]

Today I installed 12.04.4 and all the above fixes didn't work on a client machine.

Even if in some other thread (i think bug 958704) this was discouraged, i added:

  start wait-for-state WAIT_FOR=ypbind WAITER=autofs WAIT_STATE=running

after line 11 of /etc/init/autofs.conf, below the modprobe -q command.

This is very bad of ubuntu, I am having nis problems since we started adopting it. I might consider going back to OpenSuSE.

[Hugh Caley (hcaley-9)]

I've had this problem with every version of Ubuntu up to and including 15.04. Having a system that actually authenticates with NIS and allows automounting when I log in always requires some kind of hack like this. It's really annoying.

[Naoyuki Tai (ntai)]

I'm a software developer, and my office uses NIS and autofs. Everyone gets RHEL if I let my IT dept. installs, but I chose to install Ubuntu Mate 14.04 LTS by myself.

I must tell you I'm having a hell of a time. First off, when I misconfigured /etc/yp.conf, the upstart hangs. I had to boot up the live CD many times to trouble shoot. Finally I got it sorted out.

Then, autofs does not work with NIS. I'm letting my IT install RHEL.

[Robie Basak (racb)]

I'm following up on some old bugs today.

It sounds like this bug was upstart-specific. Since we are running systemd now, it seems likely that this bug can be treated as fixed or otherwise not relevant.

So I'll mark this Incomplete for now, until someone can please confirm whether or not this issue is fixed in 16.04. Please re-open or mark as Fix Released accordingly. Thanks!