portmap/statd can not be restarted

This problem does not allways occur. Sometimes portmap starts up just fine right after being stoped.

Status changed to 'Confirmed' because the bug affects multiple users.

This happens every time that portmap is stopped while something has a connection open to it. The problem can be reliably reproduced like this:

# nc localhost sunrpc &
[1] 14894
# stop portmap
[1] + done nc localhost sunrpc
portmap stop/waiting
# start portmap
start: Job failed to start

You can see from netstat that the server-side socket is sitting in TIME_WAIT, blocking portmap from starting:

# netstat -a | grep sunrpc
tcp 0 0 localhost:60269 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:sunrpc localhost:33281 TIME_WAIT

I would expect portmap to use SO_REUSEADDR to deal with this case, but apparently it only does this if the weird LOOPBACK_SETUNSET #define is enabled.

Debian package portmap 6.0.0-5 in experimental has patch 06-615642-reuse-socket.diff that makes portmap set SO_REUSEADDR. I do not understand what the LOOPBACK_SETUNSET #define actually do, but it basically removes it.

It's also worth noting that rpcbind suffers from bug #924593, which is quite similar and that upstream resolved by setting the SO_REUSEADDR option.

Note that portmap has been dropped from precise as obsolete, entirely superseded by rpcbind. We should probably target this bug at the releases you are considering SRUs for (lucid-oneiric?)

I agree, this should be an SRU. Currently lucid is being targeted, but this is fairly small fix and thus we could apply to lucid-oneiric.

This patch backports the patch 06-615641-reuse-socket.diff from debian experimental.

I have built a test package for verification on lucid:
http://people.canonical.com/~arges/lp688550/

Thanks

Tested portmap 6.0.0-1ubuntu3~lp688550 on Lucid and verified that it can restart after being stopped with an active connection.

Steve,

Assuming no blockers are present with this please wait until it is released into -proposed and if you have extra cycles to re-test this that would be greatly appreciated.

Thanks
Adam

Uploaded into lucid-proposed. Currently in the unapproved queue. You can check the status here:

https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=

Unsubscribing ubuntu-sponsors. Please subscribe again if you want to SRU this change into other releases.

portmap doesn't exist beyond lucid, unsetting all those tasks.

Hello Goswin, or anyone else affected,

Accepted portmap into lucid-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/portmap/6.0.0-1ubuntu2.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Steve/Goswin,

Were either of you able to test that this package resolves your issue?

Thanks
Adam

portmap 6.0.0-1ubuntu2.3 restarts correctly even with open connections. However, when upgrading to portmap 6.0.0-1ubuntu2.3 from 6.0.0-1ubuntu2.2, portmap fails to restart if there's an open connection. (Because the old version wasn't using SO_REUSEADDR, the new version can't take over the port.) I'm not sure this can be avoided though.

On Mon, Dec 10, 2012 at 08:34:05PM -0000, Steve Atwell wrote:
> portmap 6.0.0-1ubuntu2.3 restarts correctly even with open connections.
> However, when upgrading to portmap 6.0.0-1ubuntu2.3 from
> 6.0.0-1ubuntu2.2, portmap fails to restart if there's an open
> connection. (Because the old version wasn't using SO_REUSEADDR, the new
> version can't take over the port.) I'm not sure this can be avoided
> though.

It was discussed that the maintainer script should include a very long
timeout between stopping and restarting portmap on upgrade for this reason.
I don't know if this was implemented; I did argue that unless something like
this was implemented, we should not SRU for this issue alone, due to the
fact that the SRU itself triggers the problem.

I wasn't aware of the specifics wrt to the maintainer script before changing hands to me so I based my conclusion on

https://bugs.launchpad.net/ubuntu/+source/portmap/+bug/688550/comments/9

If this is not the case and we need to extend the timeout (I assume greater than 30 seconds?) We need to invalidate this SRU and I can implement the timeout portion of the upgrade process.

Adam,

On Mon, Dec 10, 2012 at 10:11:52PM -0000, Adam Stokes wrote:
> I wasn't aware of the specifics wrt to the maintainer script before
> changing hands to me so I based my conclusion on

> https://bugs.launchpad.net/ubuntu/+source/portmap/+bug/688550/comments/9

> If this is not the case and we need to extend the timeout (I assume
> greater than 30 seconds?)

The timeout needs to be 240 seconds. See
<https://bugs.launchpad.net/bugs/925717> for the full discussion. In
particular, comment #9 has my skeleton code for this.

> We need to invalidate this SRU and I can implement the timeout portion of
> the upgrade process.

Yep, marking v-failed.

Thanks will get this fixed up

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".