[Pkg-sysvinit-devel] Why do we fall back to trying /sbin/portmap?

[Thomas Hood]

Miquel van Smoorenburg wrote:
> Well that code was changed after sarge by an NMU.


OK, I see the changelog entry for it.

sysvinit (2.86.ds1-1.1) unstable; urgency=low
  * Check if there is a portmapper running before starting it up in
    mountnfs.sh, also, use the portmap init.d script instead of running it
    through start-stop-daemon if it is available (Closes: #85221)
 -- Javier Fernandez-Sanguino Pen~a <jfs at computer.org>  Wed, 10 Aug 2005 18:58:47 +0200


> At first it didn't
> look at /etc/init.d/portmap at all, it just started /sbin/portmap. It
> just is lower overhead, and it avoids the 1 second delay
> in /etc/init.d/portmap. Well that's the reason I just now thought up, it
> might have been something else :) But the 1 second delay still sucks.


Sucks less than the 2 second delay that's in mountnfs.sh.  :)

The current portmap package installs its own initscript at S:S43 so (sarge backport
concerns aside) we could eliminate both calls to portmap and add a dependency on
the current version of the portmap package.


Petter Reinholdtsen wrote:
> [...] I discovered that neither statd nor
> lockd is started until later in the process (in init.d/nfs-common),
> started after portmap in runlevel 2.  If we need to start portmap, we
> also need to start nfs-common, I believe.  And I believe we can run
> just fine without both until we start programs after rcS.d/ is done
> executing.


Maybe, but why does the portmap package start portmap at S:S43portmap?

For sarge backport reasons I guess we should leave the code as it is.
I'll add a comment that the code will go away after etch.
-- 
Thomas