Bug 163258 - rpc.statd logs many erroneous SM_UNMON requests after update
rpc.statd logs many erroneous SM_UNMON requests after update
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nfs-utils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-07-14 11:22 EDT by Pierre Girard
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.0.6-36EL
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-27 08:44:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pierre Girard 2005-07-14 11:22:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050523 CentOS/1.0.4-1.4.1.centos4 Firefox/1.0.4

Description of problem:
After an update we started seeing a lot of these messages in /var/log/messages
rpc.statd[1906]: Received erroneous SM_UNMON request from eth0.domain.com

We didn't have any of those messages before the update.
It's not clear to me if those indicate a problem or not.

The machine where these messages show up has 2 network interfaces.  The name in the logs is from eth0 interface and the nfs servers it's connecting to is through eth1.  

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Additional info:

Comment 1 Buck Huppmann 2005-07-25 08:32:54 EDT
we have been seeing these for a while. (since before January of this year
and whatever the current RHEL3 releast kernel was at that time and, i'm
sorry to say, for some indefinite time prior.) our messages look more like

rpc.statd[4450]: Received erroneous SM_UNMON request from
`uname -n` for

where is the host that the NFS is ``import''-ed from, from
what i've been able to discern from the logs. this may have something to
do with amd, in our case. what seems to be happening in at least one in-
stance is that amd unmounts a fileystem from and then 30
seconds later it logs that it's successfully remounted the filesystem,
immediately after which the rpc.statd message shows up in the logs, so i
don't know if maybe there's some confusion b/w amd and the kernel nfs/
lockd about what's mounted and what's not maybe, but amd is unequivocal
about thinking that it has successfully re-mounted the filesystem (on the
same mount point), so i wouldn't expect so

sorry if i'm hijacking the thread by bringing up amd. if it's a separate
pathology, please, whoever responds to this, let me know to open another
Comment 2 Steve Dickson 2005-07-27 08:44:40 EDT
Upgrading your nfs-utils to 1.0.6-36EL or higher should take care of this problem.
Comment 3 Pierre Girard 2005-07-27 09:07:47 EDT
Sorry for the stupid question but where do i find this update?  I checked
up2date this morning and it's not listed.

rpm -qa | grep nfs-util

up2date --update --download
Invalid metapkg id emacs-nox

Fetching Obsoletes list for channel: rhel-i386-as-3...

Fetching rpm headers...

Name                                    Version        Rel
cpio                                    2.5            4.RHEL3           i386
cups                                    1.1.17         13.3.29           i386
cups-devel                              1.1.17         13.3.29           i386
cups-libs                               1.1.17         13.3.29           i386
fetchmail                               6.2.0          3.el3.2           i386
httpd                                   2.0.46         46.2.ent          i386
httpd-devel                             2.0.46         46.2.ent          i386
mod_ssl                                 2.0.46         46.2.ent          i386
mozilla                                 1.7.10           i386
mozilla-chat                            1.7.10           i386
mozilla-dom-inspector                   1.7.10           i386
mozilla-js-debugger                     1.7.10           i386
mozilla-mail                            1.7.10           i386
mozilla-nspr                            1.7.10           i386
mozilla-nss                             1.7.10           i386

Comment 4 Steve Dickson 2005-07-27 11:58:45 EDT
The rpms in http://people.redhat.com/steved/rhel3/ fix the problem...

Comment 5 Alessandro Martins 2005-08-08 09:31:19 EDT

I installed your rpms that fix the bug #163258 and the problem
persists, look:

root@mail1(click21):~# rpm -qa | egrep "^nfs-utils|^shadow"

Any tip? 
Comment 6 Steve Dickson 2005-08-08 10:47:02 EDT
hmm... When you mount/remount w/out amd are you able to 
cause those messages to occur... I'm just trying to figure
out a way to reproduce this.... 
Comment 7 Alessandro Martins 2005-08-10 16:42:04 EDT

After that I remount the NFS filesystems the problem didn't occur again.

The last last problem occurred 6 days ago, look:

root@mail1(click21):/var/log# grep SM_UNMON /var/log/messages.1 | tail -1
Aug  4 15:16:08 mail1 rpc.statd[28986]: Received erroneous SM_UNMON request from
mail1 for

So, I think that I can install your rpms to the others 26 servers. :-)

Note You need to log in before you can comment on or make changes to this bug.