Your message dated Sun, 03 Apr 2011 05:29:12 +0100
with message-id <1301804953.4157.58.camel@localhost>
and subject line Re: Bug#620421: nfs-kernel-server: init script depends on
non-existent ‘/dev/tcp/’
has caused the Debian Bug report #620421,
regarding nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
620421: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620421
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: nfs-kernel-server
Version: 1:1.2.2-5
Severity: important
Tags: patch
The ‘/etc/init.d/nfs-kernel-server’ script has a new dependency on a
non-existent directory:
=====
# See if portmap or rpcbind are running
(cat </dev/null >/dev/tcp/localhost/111) 2>/dev/null
RET=$?
if [ $RET != 0 ]; then
echo
log_warning_msg "Not starting: portmap daemon is not
running"
exit 0
fi
=====
This results in the script failing, with “Not starting: portmap daemon
is not running”.
That's nothing to do with the portmapper service. It's because there is
no such directory ‘/dev/tcp/’ on this machine:
$ ls /dev/tcp/
ls: cannot access /dev/tcp/: No such file or directory
To check for the portmapper service, the ‘rpcinfo(1)’ tool is provided.
Using that program, we can see that the service is running on this
machine:
$ rpcinfo -t localhost portmapper
program 100000 version 2 ready and waiting
The following patch uses this test, which works in current “Wheezy”.
=== modified file 'init.d/nfs-kernel-server'
--- old/init.d/nfs-kernel-server 2011-04-01 12:03:38 +0000
+++ new/init.d/nfs-kernel-server 2011-04-01 19:51:56 +0000
@@ -84,7 +84,7 @@
log_progress_msg "nfsd"
- # See if portmap or rpcbind are running
- (cat </dev/null >/dev/tcp/localhost/111) 2>/dev/null
+ # See if the portmapper service is running.
+ (rpcinfo -t localhost portmapper) >/dev/null 2>/dev/null
RET=$?
if [ $RET != 0 ]; then
echo
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (900, 'stable')
Architecture: powerpc (ppc64)
Kernel: Linux 2.6.32-5-powerpc64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_AU.utf8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nfs-kernel-server depends on:
ii libblkid1 2.17.2-9.1 block device id library
ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib
ii libcomerr2 1.41.12-2 common error description library
ii libgssapi-krb5-2 1.8.3+dfsg-4 MIT Kerberos runtime libraries - k
ii libgssglue1 0.1-4 mechanism-switch gssapi library
ii libk5crypto3 1.8.3+dfsg-4 MIT Kerberos runtime libraries - C
ii libkrb5-3 1.8.3+dfsg-4 MIT Kerberos runtime libraries
ii libnfsidmap2 0.24-1 An nfs idmapping library
ii librpcsecgss3 0.19-2 allows secure rpc communication us
ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra
ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip
ii nfs-common 1:1.2.2-5 NFS support files common to client
ii ucf 3.0025+nmu1 Update Configuration File: preserv
nfs-kernel-server recommends no packages.
nfs-kernel-server suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On Sun, 2011-04-03 at 14:20 +1000, Ben Finney wrote:
> On 03-Apr-2011, Ben Hutchings wrote:
> > So you're saying that on your system, the 'cat' command can silently
> > fail?
>
> I'm describing (actually, repeating) what was in the initial bug
> report for that test, modulo my misunderstanding about Bash's special
> treatment of that path.
The initial bug report contained the output from the upgrade and the
init script. The init script redirects errors from the test command to
/dev/null because the error message is not expected to be meaningful in
context. That's why I asked to run the test command directly.
> For now, I've worked around the problem and am unable to reproduce it
> (the test now passes). Possibly that's because of a kernel upgrade; I
> don't know.
OK, closing.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
--- End Message ---
