NIS-based autofs maps don't load on startup

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we can't fix it because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem. We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures.
At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
Thanks!

When reporting bugs in the future please use apport, either via the appropriate application's "Help -> Report a Problem" menu or using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

here are more information about this issue :

The hardware I used for this test and I witnessed this problem with : SAMSUNG N150 Laptop

What I wanted to do :
I have Installed Ubuntu with the 10.04 BETA1, then I did daily updates.
Today I decided to install autofs (cause I forgot to do it), I use to do it for my NAS access with previous Ubuntu version.

To do this I did :
sudo apt-get install autofs

then I changed the /etc/auto.master and I created the /etc/auto.nfs (these two files are attached to this comment)

In the /net directory nothing is present, so it's impossible to access to the NAS
I tried to find something on the Ubuntu community forum, many guys have the same problem but I don't really found any solution or workaround.

After a check on Launchpad I didn't find relative topic, so here we are.

Don't hesitate to ask me any information, it will be a pleasure for me to help as I can ...

I can confirm this. I got the same problem with network-mounted directories.
When I switch on autofs, the directories that should be mounted, are empty and not accessable. Once I uninstall autofs, the directories reappear.
In Karmic everything works fine, not so in Lucid.

Does anyone know what to do?

Same problem here: NFS disk mounted via autofs does not mount since upgrade to lucid.

Besides, when trying to stop/restart the service, I encounter the following result:
$ service autofs restart
restart: Rejected send message, 1 matched rules; type="method_call", sender=":1.64" (uid=1000 pid=32756 comm="restart) interface="com.ubuntu.Upstart0_6.Job" member="Restart" error name="(unset)" requested_reply=0 destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init"))

No workaround so far...

autofs should depend on statd in upstart
Run:
  start statd
to verify

It looks like this is a bug in statd... which is just plain wrong :)

With upstart do you have to teach other services about your service?

eg autofs needs statd. statd says "start on (started portmap or mounting TYPE=nfs)" which I assume needs to go to "start on (started portmap or started autofs or mounting TYPE=nfs)"

I checked http://upstart.ubuntu.com and found no "depends"-like stanza that could be placed in autofs

k3nt-1 :
 I've got the same message. Doing
 sudo start autofs
worked.

But I still was unable to make autofs start at boot where other dameon depending on filesystem or on net-device-up where started as expected. Any direction on how to debug the problem ?

This bug started out as 'autofs does not work with lucid'
but the more recent comments indicate 'autofs works with lucid but does not start on boot in lucid'

Can we nail down which it is and fix the notes and/or the title?

I'm running Ubuntu 10.04 LTS; autofs is working fine for me but does not start on boot despite :
$ runlevel
N 2
$ ls -l /etc/rc2.d/*autofs
lrwxrwxrwx 1 root daemon 16 2010-05-02 07:38 /etc/rc2.d/S20autofs -> ../init.d/autofs

I work around this by adding 'service autofs start' to /etc/rc.local :
$ grep autofs /etc/rc.local
service autofs start

It seems autofs is completely broken for me not only does the service not start automatically it doesn't mount NFS shares on manual start.

Here is what I have tried

$ sudo service autofs restart
autofs start/running, process 4590

in syslog I see

May 14 12:44:17 sky-ubuntu automount[4590]: syntax error in nsswitch config near [ syntax error ]

here is my nsswitch.conf not sure what is wrong here

$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: compat
group: compat
shadow: compat

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

If I try to automount manually this is what I see

$ sudo automount -v -d -F -C -f -t 60
Starting automounter version 5.0.4, master map /etc/auto.master
using kernel protocol version 5.01
lookup_nss_read_master: reading master file /etc/auto.master
parse_init: parse(sun): init gathered global options: (null)
lookup_read_master: lookup(file): read entry +auto.master
syntax error in nsswitch config near [ syntax error ]

lookup_nss_read_master: reading master files auto.master
parse_init: parse(sun): init gathered global options: (null)
lookup(file): failed to read included master map auto.master
no mounts in table

Any ideas on how I can fix this ... ??

I also have this problem under Ubuntu 10.04LTS.
Running the automounter manually (thanks onkara), on attempting to change to an NFS-mounted directory, I noticed:

>> mount.nfs: rpc.statd is not running but is required for remote locking.
>> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.

On starting statd ("sudo start statd") and autofs ("sudo start autofs"), the automounter is now working.

Neither autofs nor statd appear to be in /etc/rc?.d/

Hi,
After upgrading from 9.10 to 10.04, I had a short bit of trouble getting
autofs working until I figured out that I needed to re-add the line

automount: files nis

to /etc/nsswitch.conf . Now things are working OK for me.

Same problem here, autofs doesn't work because statd is not started.

Some more debugging revealed that:

if some NFS3 mount is used in /etc/fstab, anything work, statd ist started automatic, but if there is no NFS3 mount inside fstab statd is not started even with autof. So some of the upstart rules for statd/autofs will not work correctly.

Workaround for me is now to add a static NFS3 mount inside /etc/fstab

I can't also use autofs5 to automount server's home directory for my users.
The workaround to get it work was to remove autofs5 autofs-ldap autofs5-ldap, then download karmic version of autofs and autofs-ldap
wget http://fr.archive.ubuntu.com/ubuntu/pool/main/a/autofs/autofs_4.1.4+debian-2.1ubuntu2_i386.deb
wget http://fr.archive.ubuntu.com/ubuntu/pool/universe/a/autofs/autofs-ldap_4.1.4+debian-2.1ubuntu2_i386.deb

dpkg -i for both files, reboot and all is working again, without any problem's.
I think it was a bad idea remove autofs4 from lucid without have autofs5 well tested.

For those who can't get autofs start automatically, please do the following:
create a file named "autofs" with the following content:

#!/bin/sh
[ "$IFACE" != "lo" ] || exit 0
/etc/init.d/autofs reload

and copy it to:
/etc/network/if-down.d and /etc/network/if-up.d

I'm sure all will work fine.
At least to me it works.

Finally managed to successfully connect to my NFS server.
Steps to solve the problem:
* Add the following line to /etc/nsswitch.conf:
automount: nis files
* Change my /etc/auto.nfs config file by removing the options and leaving only the local folder and the target

I'm not sure if my problem is exactly the same as others are having here. but it definitely matches the description of "autofs doesn't work with lucid". I've tried the workarounds listed here without success, though.

My original problem is described here: http://ubuntuforums.org/showthread.php?t=1515997
I can add that statd and autofs are running. I've added an automount line to /etc/nsswitch.conf and tried the karmic version of autofs instead (I'm not using autofs-ldap at all), with no effect.

Autofs doesn't work because it startup script has incorrect dependency to statd (doesn't have). Can submit workaround: in /etc/init/autofs.conf add line

status statd | grep -q start/running || start statd

after "pre-start script" line

If you look in /etc/init/portmap.conf you will see that its prerequisite for starting is statd which is done in /etc/init/portmap.conf. However, there are numerous errors in my /var/log/boot.log file.

I upgraded two machines and both have the same issue as mentioned above. A new install I did does not have this issue, so it obviously is some config issues that is going badly when upgrading.

I was originally fixing this issue by stopping then starting portmap again. (A restart didn't work.)

I have found this in my /var/log/boot.log file:

init: statd main process (730) terminated with status 1
init: statd main process ended, respawning
init: statd main process (736) terminated with status 1
init: statd main process ended, respawning
init: statd main process (747) terminated with status 1
init: statd main process ended, respawning
init: statd main process (754) terminated with status 1
init: statd main process ended, respawning
init: rpc_pipefs pre-start process (703) terminated with status 32
init: statd main process (764) terminated with status 1
init: statd main process ended, respawning
init: statd main process (770) terminated with status 1
init: statd main process ended, respawning
init: statd main process (776) terminated with status 1
init: statd main process ended, respawning
init: statd main process (782) terminated with status 1
init: statd main process ended, respawning
init: statd main process (788) terminated with status 1
init: statd main process ended, respawning
init: statd main process (794) terminated with status 1
init: statd main process ended, respawning
init: statd main process (800) terminated with status 1
init: statd respawning too fast, stopped

This is the same bug as 590570, but this one has been around longer.

I think the real issue underlying this bug is in bug 525154 which relates to a race condition while starting portmap which in turn starts statd. This only seems to be an issue if you have /var as a separate mount point where /var is not mounted when statd is started.

Post 13 on bug 525154 seems to solve this issue, but it is only a workaround, it does not solve the race condition if my understanding is correct.

Strange, because /var is mounted as part of / in my configuration (though I faced the problem...)

Post 13 in bug 525154 above has solved the issue with statd, but now autofs is failing to start. I tried to something similar with /etc/init/autofs.conf but to no avail. Still no joy here.

k3nt-1 are you seeing the error messages in your /var/logs/boot.log file that I posted above?

13 in bug 525154 and #15 of this solved my problems.

For me workaround given in comment #8 in bug 525154 worked on four systems, but on the fifth it was not enough, and I had to combine it with #15 from this bug report. I have to admit that number of problems caused by Upstart is astoundingly high, and they crop up unexpectedly in a random fashion. I am beginning to think that Upstart is an inherently flawed design.

#15 worked for me as well. I also set NEED_STATD=yes in /etc/default/nfs-common.

But autofs should only depend on statd if it is mounting NFS volumes. autofs can be used with other filesystems besides NFS.

On yet another machine autofs would not start correctly neither with the workaround from comment #15, nor without it. My efforts to convince Upstart to run startup scripts in a correct sequence ended in an utter failure. What I did instead is to modify /etc/init/autofs.conf so that Upstart doesn't touch autofs at boot at all, by changing line "start on (filesystem and net-device-up IFACE!=lo)" to "start on never". I then added the following line to /etc/rc.local: "service autofs start" (before "exit 0" line). Works like a charm, though feels like going back to the days before sysv-init was invented.

Someone have an idea on how start autofs on boot with upstart???
I have a server with 9.10 and 10.04, the first is ok, the second no.

The solution with the "start on never" and adding "service autofs start" in the file
/etc/rc.local works, but is very very worst under the sysadmin's point of view...

I'm very tired about this kind of problem in ubuntu...no support, but someone
continue to change the configuration of the system on every new release, and break the system!!!
I'll start to move out from my datacenter any installation of ubuntu, isn't
possibile to follow this kind of distrubution that is worst after every new release...

Our 10 machine system (all lucid 64-bit) also suffers from this diffuse bug. Workaround #23 did not work, some of the machines start autofs anyway even with "start on never" in /etc/init/autofs.conf . Putting "service autofs restart" in /etc/rc.local works only for about half of the machines and not reproducibly either. When I type manually sudo service autofs restart at console the system recovers almost all the time. I don't understand how that is different from putting the command in /etc/rc.local. I tried with various sleep delays with no success. It is quite frustrating indeed.

Further investigation revealed that in my case autofs was not racing with statd, but rather with nis (client daemon): bug 569757 and bug 570513. The workaround #15 appeared to work in some cases, because it introduced a small delay into autofs init script, which gave time for the nis daemon to start before autofs needed it.

I sympathize with other frustrated users of Ubuntu. I recently installed lucid on 9 machines (servers and workstations), none of which was able to boot correctly without extensive fiddling with init scripts, due to various Upstart-related problems.

Hello to all reporters of this issue. It seems to me that the upstream encoded requirements for autofs:

# Required-Start: $network $ypbind
# Required-Stop: $network $ypbind

Have not been properly captured in the upstart job:

start on (filesystem
    and net-device-up IFACE!=lo)
stop on runlevel [!2345]

$ypbind is particularly tricky because it has not been converted to upstart yet. That is bug #569757

That said, until that bug is fixed, we can just start ypbind in the pre-start, alleviating this problem.

For $network, the exact meaning of this has never been clear[1], so emitting it when "the first real interface" is up is probably a decent best effort.

Given all of that, and the fact that we are the upstream for the upstart job, I am marking this as Triaged.

1. http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/facilname.html

Oh and to another point, statd's start on has changed and now always starts before NFS mounts are attempted. So the patch provided isn't really valid.

Latest Lucid and I'm having this issue. Can't be true it's still borked :-(

Yury, I'm sorry this bug is affecting you. It is blocked on bug #569757 , which has made slow progress, but may be close to landing in precise.

autofs does not need and should not have a strong require for ypbind (or, even statd)

However, when configured to autostart NFS mounts or to use NIS (!) then of course it depends on those services.

The way we're dealing with it at my site is as follows:

blacklist autofs4 module
# echo "blacklist autofs4" > /etc/modprobe.d/autofs.conf
# chmod 644 /etc/modprobe.d/autofs.conf
# chown root:root /etc/modprobe.d/autofs.conf

load autofs module
# echo "autofs" >> /etc/modules
# reboot

This is forced on all our machines by cfengine just after the kickstart/preseed. YMMV. We don't use NIS or NFSv4 so don't blame me if this breaks anything as I have only tested it on my particular setup.

It is really great that work is in progress I look forward to see this bug fixed in lucid/precise! I have a small comment though: in my case the autofs startup problem is unrelated to NIS, as I use LDAP. Out of desperation 1.5 years ago I also experimented with flat map files on local fs and even with that setup I encountered periodic problems with autofs startup at boot. Either autofs is not started or needs to be restarted to pick up the shares.

Gergely, LDAP would be a different bug. Perhaps open a new bug report explaining that? It should be solvable in a similar way, by starting openldap with invoke-rc.d if it is on the system and not yet started.

In reference to LDAP, it probably is the same bug, if you're using autofs-ldap which is part of the same source package then you can have you auto.master in LDAP, so you probably don't have openldap running locally, but require the network to be working before starting autofs to do ldap queries to find out the auto.master.

I am effected by this problem, restarting the autofs service after the network is up makes it work, I do not have openldap running locally on client machines using autofs.

the fix in #569757 will probably not help autofs-ldap users.