Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163258 - rpc.statd logs many erroneous SM_UNMON requests after update
Summary: rpc.statd logs many erroneous SM_UNMON requests after update
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nfs-utils
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-14 15:22 UTC by Pierre Girard
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: 1.0.6-36EL
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-27 12:44:40 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Pierre Girard 2005-07-14 15:22:00 UTC
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

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 12:32:54 UTC
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 12:44:40 UTC
Upgrading your nfs-utils to 1.0.6-36EL or higher should take care of this problem.

Comment 3 Pierre Girard 2005-07-27 13:07:47 UTC
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 15:58:45 UTC
The rpms in fix the problem...

Comment 5 Alessandro Martins 2005-08-08 13:31:19 UTC

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 14:47:02 UTC
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 20:42:04 UTC

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.