nfs-kernel-server doesn't start automatically at startup

[mmalmeida]

When I boot the system nfs-kernel-sever isn't started, even though I have the following in my /etc/exports:

/srv/files 192.168.1.0/24(rw,async,no_subtree_check)
/srv/files/ *(rw,async,all_squash,no_subtree_check)

I have used update-rc.d to add both that service and portmap, and sysv-rc-conf reports both services at 2,3,4 and 5.

After boot, running
service portmap start
and
service nfs-kernel-server start

runs normally and nfs will work.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: 349c06e6f2d8e913fce4da07b736969a
CheckboxSystem: 0531969bcfd4f03af7405c98dc94a948
Date: Sun Oct 18 23:57:09 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: nfs-kernel-server 1:1.2.0-2ubuntu7
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: nfs-utils
Uname: Linux 2.6.31-14-generic i686

[mmalmeida (mmalmeida)]

Regarding this issue: shouldn't portmap have a different priority level on rc.d, since it seems to depend on portmap? This issue is still present on October 25th.

[mmalmeida (mmalmeida)]

Edit: I meant "shouldn't nfs-kernel-server have a different priority level on rc.d, since it seems to depend on portmap?"

[mmalmeida (mmalmeida)]

Steps to recreate the issue:

1) Have postfix running and confirm it works on startup
2) Install nfs-kernel-server
3) Reboot
4) Run "sudo service postfix", "sudo service portmap", "sudo service nfs-kernel-server" and check which services are running
5) If none of them are running, start them (postfix, portmap and nfs-kernel-server)

6) Remove nfs-kernel-server, reboot and see postfix running.

[mmalmeida (mmalmeida)]

More info:

Upon startup, doing ps aux| grep nfs yields:

root 876 0.0 0.0 0 0 ? S< 23:39 0:00 [nfsiod]
root 1988 0.0 0.0 1748 580 ? S 23:39 0:00 /bin/sh /etc/rc2.d/S20nfs-kernel-server start
root 2004 0.0 0.0 1712 592 ? D 23:39 0:00 /usr/sbin/rpc.nfsd 8

Which indicates the startup script is hanging...

[Steve Langasek (vorlon)]

You wrote:

> I have used update-rc.d to add both that service and portmap, and sysv-rc-conf reports both services at 2,3,4 and 5.

The portmap service is no longer started via sysv-rc in Ubuntu 9.10, a symlink is provided as /etc/init.d/portmap for compatibility only. So adding it to the runlevels should be unnecessary, but I acknowledge that there's a race condition here that would permit nfs-kernel-server to start up before portmap. However, in my testing, once portmap comes up nfs-kernel-server seems to continue starting successfully. Is this not your experience?

Did adding start symlinks for portmap to your runlevels fix the boot problem for you? You only mention that running 'service portmap start' manually works.

When the boot breaks for you in this fashion, what does 'sudo status portmap' report? Even though there is a race condition, it seems quite unusual that you would manage to hit it consistently, so I suspect something else is breaking the portmap start.

[mmalmeida (mmalmeida)]

Hi Steve,

> When the boot breaks for you in this fashion, what does 'sudo status portmap' report?

portmap stop/waiting

and service postfix status:
 * postfix is not running

I also attach the results of running pstree and ps aux

[mmalmeida (mmalmeida)]

Steven: I attach the syslog after adding

pre-start exec initctl log-priority debug

to the /etc/init/mountall.conf file

[mmalmeida (mmalmeida)]

And the syslog after a few minutes running - postfix and dovecot eventually start, but not portmap nor nfs-kernel-server

[Steve Langasek (vorlon)]

It looks like we're not capturing all the logging we want to, because rsyslog starts to late - it doesn't start until the filesystem is fully available, whereas portmap starts as soon as local filesystems and localhost are available.

You could try editing these lines in /etc/init/portmap.conf:

  start on (local-filesystems
          and net-device-up IFACE=lo)

to this:

  start on (local-filesystems
          and net-device-up IFACE=lo
          and started rsyslog)

This way, portmap doesn't try to start before logging is going.

From the log you have, though, this is interesting:

Oct 26 23:30:59 htpc init: event_pending_handle_jobs: New instance gdm
Oct 26 23:30:59 htpc init: gdm goal changed from stop to start
Oct 26 23:30:59 htpc init: gdm state changed from waiting to starting
Oct 26 23:30:59 htpc init: event_new: Pending starting event
Oct 26 23:30:59 htpc init: udevmonitor goal changed from start to stop
Oct 26 23:30:59 htpc init: udevmonitor state changed from running to pre-stop
Oct 26 23:30:59 htpc init: udevmonitor state changed from pre-stop to stopping
Oct 26 23:30:59 htpc init: event_new: Pending stopping event
Oct 26 23:30:59 htpc init: job_register: Registered instance /com/ubuntu/Upstart/jobs/networking/_
Oct 26 23:30:59 htpc init: job_register: Registered instance /com/ubuntu/Upstart/jobs/networking/_
Oct 26 23:30:59 htpc init: job_register: Registered instance /com/ubuntu/Upstart/jobs/networking/_
Oct 26 23:30:59 htpc init: event_pending_handle_jobs: New instance networking
Oct 26 23:30:59 htpc init: networking goal changed from stop to start
Oct 26 23:30:59 htpc init: networking state changed from waiting to starting
Oct 26 23:30:59 htpc init: event_new: Pending starting event
Oct 26 23:30:59 htpc init: Handling starting event
Oct 26 23:30:59 htpc init: event_finished: Finished starting event
Oct 26 23:30:59 htpc init: gdm state changed from starting to pre-start
Oct 26 23:30:59 htpc init: gdm state changed from pre-start to spawned
Oct 26 23:30:59 htpc init: gdm main process (1011)
Oct 26 23:30:59 htpc init: gdm state changed from spawned to post-start
Oct 26 23:30:59 htpc init: event_new: Pending started event
Oct 26 23:30:59 htpc init: Handling stopping event
Oct 26 23:30:59 htpc init: event_finished: Finished stopping event
Oct 26 23:30:59 htpc init: udevmonitor state changed from stopping to killed
Oct 26 23:30:59 htpc init: Sending TERM signal to udevmonitor main process (446)
Oct 26 23:30:59 htpc init: Handling starting event
Oct 26 23:30:59 htpc init: event_finished: Finished starting event
Oct 26 23:30:59 htpc init: networking state changed from starting to pre-start
Oct 26 23:30:59 htpc init: networking state changed from pre-start to spawned
Oct 26 23:30:59 htpc init: networking main process (1017)
Oct 26 23:30:59 htpc init: networking state changed from spawned to post-start
Oct 26 23:30:59 htpc init: networking state changed from post-start to running
Oct 26 23:30:59 htpc init: event_new: Pending started event
Oct 26 23:30:59 htpc init: Handling started event
Oct 26 23:30:59 htpc init: event_finished: Finished started event
Oct 26 23:30:59 htpc init: Handling started event
Oct 26 23:30:59 htpc init: event_...

[mmalmeida (mmalmeida)]

Hi Steve,

As requested:

1) syslog3, the log after the change in portmap.conf

2) This is a new Zotac Ion computer, which has a N330 processor, 2GB of ram and one 1TB sata drive. Not the quickest of the machines, I suppose, although it starts quickly (boot in 15-20 secs)

3) The /etc/networks/interfaces only has commented stuff. I added it because that's how I used to define static IP addresses, but I commented when I figured out that would make the NetworkManager applet not work as it should. Here's the cat:

#auto lo
#iface lo inet loopback

#auto eth0
#iface eth0 inet static
#address 192.168.1.100
#netmask 255.255.255.0
#gateway 192.168.1.1

[mmalmeida (mmalmeida)]

Oh, as for
2)

"do you have a lot of devices..."

No. I only have a bluetooth usb adapter and an usb receiver for a wireless media keyboard/mouse. Aside from that, only thing plugging to the board is the SAtA HDD, the network cable and the hdmi cable.

[Steve Langasek (vorlon)]

On Tue, Oct 27, 2009 at 06:50:50PM -0000, wild_oscar wrote:
> 3) The /etc/networks/interfaces only has commented stuff. I added it
> because that's how I used to define static IP addresses, but I commented
> when I figured out that would make the NetworkManager applet not work as
> it should. Here's the cat:

> #auto lo
> #iface lo inet loopback

I think this is the source of your problem. NetworkManager doesn't manage
the loopback interface, and you've told ifupdown not to do so either.
Please confirm this with:

  ifconfig lo

And post the output. If the interface is down, uncommenting the above lines
and then running

  sudo ifup lo

should be enough to bring portmap up, fixing this problem for you. (You'll
then want to make sure youalso reset your changes to the files under
/etc/init/.)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[mmalmeida (mmalmeida)]

You seem to be correct! Uncommenting the lines seems to have solved the issue.

Thank you very much for the assistance, Steve. It's because of people like you that Open Source is a valid, strong and admirable movement.

Sorry for reporting the bug which seems to have been caused by my distraction. I'll mark the bug as invalid.

[Steve Langasek (vorlon)]

Actually, I'm going to reopen this bug against portmap. :) The portmap upstart conversion introduced a dependency on the loopback interface that wasn't there before; previously portmap would start fine as long as /any/ network interface was up. And I think some systems, such as vserver, explicitly don't have lo available as an interface within the container. So even though it doesn't seem sensible to have a system without localhost, we want portmap to be as robust as possible here.

[Steve Langasek (vorlon)]

Mind you, the original reason for setting the dependency on IFACE=lo is that services appear to contact portmap on 127.0.0.1 - so I wonder how this ever worked for you before without a lo interface? (Was something /else/ configuring lo for you, but not communicating with ifupdown?)

[mmalmeida (mmalmeida)]

Can NetworkManager (ie, gnome's, and its tray applet) do that job?

Aside from that, I don't know. Mind you that when I ran " ifconfig lo" and *had* those lines commented, I didn't have an empty output. I had something similar with what is bellow (which was taken just now, after uncommenting the lines). I'm not sure if there was something in the place of "UP", though.

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:1855 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1855 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:574202 (574.2 KB) TX bytes:574202 (574.2 KB)

[Steve Langasek (vorlon)]

> Can NetworkManager (ie, gnome's, and its tray applet) do that job?

Yep - I've tested here by taking down my loopback interface and removing it from /etc/network/interfaces, and restarting network-manager brings loopback right back up, without communicating with ifupdown (and therefore, without emitting the crucial 'net-device-up' signal).

I think this is a real bug in network-manager that should be addressed for Lucid; reassigning.

[Bryan Quigley (bryanquigley)]

This was fixed for 12.04 and 14.04. A similar bug (but very different underlying issues) is now an issue for 15.10/16.04 so closing this.