mountall tries to mount NFS filesystem before statd starts, generating a non-fatal warning

[Steve Atwell]

Binary package hint: mountall

mountall sometimes tries to mount NFS filesystems before rpc.statd has started. When this happens, you get an error on the console like this:

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.
mountall: mount /net [402] terminated with status 32
mountall: Filesystem could not be mounted: /net

It seems the problem is that the statd upstart job is started on "mounting TYPE=nfs", but mountall doesn't wait until statd is started before attempting the mount. This becomes a race condition. If statd may or may not be started by the time the mount is attempted. It's easy to expose the race condition by adding a "sleep 1" immediately before the "exec rpc.statd" in /etc/init/statd.conf.

Eventually the nfs filesystem does get mounted (looks like there is some retry behavior), but it does result in errors being printed about failed mount attempts.

version info:

Description: Ubuntu lucid (development branch)
Release: 10.04

mountall 2.8
nfs-common 1:1.2.0-4ubuntu4

[Brian J. Murrell (brian-interlinx)]

I see that this was changed from mountall to nfs-utils. I wonder what the reasoning behind that is. It seems to me that it's mountall that's jumping the gun here and trying to mount nfs filesystems before nfs is ready. I can't imagine how nfs-utils can be responsible for or control what mountall is doing.

Does the nfs-utils maintainer agree that this is an nfs-utils problem?

[Steve Langasek (vorlon)]

There is no nfs-utils maintainer in Ubuntu, but as a frequent uploader of the package, I don't agree that it's a problem at all to try to mount NFS filesystems before statd starts. The only problem is if mountall fails to *retry* the mount once statd *does* start.

Since you say the NFS filesystem does eventually get mounted, I regard the extra messages about failed mount attempts to be a 'wontfix' issue. If the filesystem fails entirely to be mounted, that's a bug - but that's already tracked as bug #525154.

[Brian J. Murrell (brian-interlinx)]

On Fri, 2010-05-14 at 13:20 +0000, Steve Langasek wrote:
> There is no nfs-utils maintainer in Ubuntu, but as a frequent uploader
> of the package, I don't agree that it's a problem at all to try to mount
> NFS filesystems before statd starts. The only problem is if mountall
> fails to *retry* the mount once statd *does* start.

This sounds *very* race prone to me. Discarding proper ordering, hoping
that a "mop up" later will fix things is just bad design, IMHO. There
really is no need for it. ISTM that mountall is simply trying to do too
much work all at once and too hastily.

It is interesting that there is already mountall-net.conf which tells
mountall (via SIGUSR1) when a network interface has become available.
Perhaps mountall needs to be told when NFS (or any number of filesystems
that have prerequisites) is fully available and wait for that before
mounting NFS filesystems.

Or mountall needs to be split into multiple tools and/or have multiple
personalities which can be called to mount different filesystem (types)
when the prerequisites for such filesystems have been met.

> Since you say the NFS filesystem does eventually get mounted,

So far. But I will not be holding my breath on that.

> I regard
> the extra messages about failed mount attempts to be a 'wontfix' issue.

That's a pity. "Cleanliness" should be every developer's goal. i.e. it
should not be simply accepted that "yeah, well there will be error
messages on boot, but you can ignore them" because it creates an
environment of complacency where all errors are ignored. "but you told
me i could ignore errors on boot -- oh, not these error messages, just
those other ones? how am i to know which errors i can ignore and which
ones i can't?"

[Tore Anderson (toreanderson)]

I also have this problem, but in my case, the NFS share is _not_ mounted. From the console:

[...]
fsck from util-linux-ng 2.17.2
/dev/mapper/tore.users-varlog: clean, 198/262144 files, 28568/524288 blocks
Starting SpamAssassin Mail Filter Daemon: 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.
mountall: mount /backup [441] terminated with status 32
spamd.
[...]

When the machine has finished booting, /backup is not mounted. Running "mount /backup" after the machine is up works without any problems. The relevant line in /etc/fstab is:

nfs:/export/backup /backup nfs defaults,hard,intr 0 0

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04 LTS
Release: 10.04
Codename: lucid

Tore

[Forest (foresto)]

I have this problem on Natty. On most boots, nfs shares never mount unless I do it manually.

Based on the error messages produced when mountall runs, it looks like the problem is that nfs mounting is done by /etc/init/mountall-net.conf, which runs on net-device-up, but would need to run after statd is fully up and running in order to reliably mount nfs.

I see an upstart script called statd-mounting.conf that might be useful here. Oddly, it doesn't seem to be referenced by any other upstart scripts.

[Steve Langasek (vorlon)]

> I have this problem on Natty. On most boots, nfs shares never mount
> unless I do it manually.

That is not the problem described by this bug. This bug report is about the
extra error message caused by trying to mount NFS before statd is running;
failures to mount the filesystem at boot are tracked on bug #525154.

[Forest (foresto)]

Okay, I'll follow that bug, but you might want to update the title of this one. The current title exactly describes the situation I'm seeing.