[Pkg-sysvinit-devel] Why do we fall back to trying /sbin/portmap?
jdthood at yahoo.co.uk
Thu Jan 12 08:48:12 UTC 2006
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
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.
More information about the Pkg-sysvinit-devel