After boot/logout portmap needs to be reconfigured and restarted

[Carl Nobile]

Binary package hint: portmap

I am running automount (autofs) for my NFS mounts. When I log out then back in I cannot get to the mounts any more. I need to run

$ sudo dpkg-reconfigure portmap <choose No>
$ sudo service portmap restart

to get them working again. Restarting alone doesn't fix it.

This is happening on two machines both running Lucid 10.04 right after an upgrade. One is a headless server and the other is my laptop. I have a third netbook that I put a fresh install on and it does not have this issue.

[Steve Langasek (vorlon)]

Thank you for taking the time to report this issue and help to improve Ubuntu.

> Restarting alone doesn't fix it.

How are you trying to restart it? Is portmap even running at this point?

The only effect dpkg-reconfigure has is to let you pick whether portmap should listen only on loopback, or on all interfaces. However, portmap doesn't reconfigure itself, so there should be no need ot run this command more than once ever. Is the timestamp on /etc/default/portmap changing in between these invocations of dpkg-reconfigure?

[Carl Nobile (cnobile1)]

Portmap is always running.

To restart portmap I use:
$ sudo service portmap restart

The time stamps have not changed since I last reconfigured portmap.

I am seeing behavior I have never seen before on two machines after upgrades. A third machine was a fresh install and doesn't exhibit this behavior. If I just restart portmap the mounts will never work unless I must reconfig first. I know it sound crazy but this is the only thing that gets the mounts to automount.

The only thing I was mistaken on is that this only seems to be an issue after rebooting. Logging out then in again seems to work fine if I had reconfigured and restarted portmap beforehand.

Another possibly related issue a friend of mine is having is that 10.04 seems to be trying to mount external file systems before the network has fully come up and consequently fails to mount anything. He also claims this has happened after an upgrade.

Could there be a timing issue in the startup sequence?
I get the following when I look at /var/log/message every time I boot:

Jun 10 10:16:14 foundation kernel: [ 14.654977] svc: failed to register lockdv1 RPC service (errno 97).
Jun 10 10:16:14 foundation kernel: [ 14.656050] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Jun 10 10:16:14 foundation kernel: [ 14.683755] NFSD: starting 90-second grace period
Jun 10 10:16:29 foundation kernel: [ 29.988891] ppdev: user-space parallel port driver
Jun 10 10:21:50 foundation portmap: Removing stale lockfile for pid 718

[Carl Nobile (cnobile1)]

Some more recent info on this bug:

A complete stop and start of portmap will also get things working. So here's the current situation. Either do a

$ sudo service portmap stop
$ sudo service portmap start

or

$ sudo dpkg-reconfigure portmap <choose No>
$ sudo service portmap restart

will get automount working.

[Carl Nobile (cnobile1)]

This seems to be the same bug as in 573919 where statd is not started. If you look in /etc/init/portmap.conf you will see that its prerequisite for starting is statd which must have been started when I used one of the two methods mentiond above to restart portmap.

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

I will continue posting in the 573919 thread since this seems to be the same bug.

[Josh Brown (joshbrown)]

I'm not sure if this is related, but I found this in my /var/log/boot.log file:

init: portmap main process (771) terminated with status 2
init: portmap main process ended, respawning
init: statd pre-start process (788) terminated with status 2

[Carl Nobile (cnobile1)]

Yes most likely it is related as portmap is used in NFS and it must be
running for NFS to work.

~Carl

On Wed, Sep 22, 2010 at 3:46 PM, Josh Brown <email address hidden> wrote:
> I'm not sure if this is related, but I found this in my
> /var/log/boot.log file:
>
> init: portmap main process (771) terminated with status 2
> init: portmap main process ended, respawning
> init: statd pre-start process (788) terminated with status 2
>
> --
> After boot/logout portmap needs to be reconfigured and restarted
> https://bugs.launchpad.net/bugs/590570
> You received this bug notification because you are a direct subscriber
> of the bug.
>

-------------------------------------------------------------------------------
Carl J. Nobile (Software Engineer)
<email address hidden>
-------------------------------------------------------------------------------

[Launchpad Janitor (janitor)]

[Expired for portmap (Ubuntu) because there has been no activity for 60 days.]