Bug 163258
| Summary: | rpc.statd logs many erroneous SM_UNMON requests after update | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Pierre Girard <pierre.girard> |
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | amartins |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.0.6-36EL | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-07-27 12:44:40 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Pierre Girard
2005-07-14 15:22:00 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 172.31.206.72 where 172.31.206.72 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 172.31.206.72 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 bugzilla Upgrading your nfs-utils to 1.0.6-36EL or higher should take care of this problem. 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 nfs-utils-1.0.6-33EL 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 1.1.3.1 i386 mozilla-chat 1.7.10 1.1.3.1 i386 mozilla-dom-inspector 1.7.10 1.1.3.1 i386 mozilla-js-debugger 1.7.10 1.1.3.1 i386 mozilla-mail 1.7.10 1.1.3.1 i386 mozilla-nspr 1.7.10 1.1.3.1 i386 mozilla-nss 1.7.10 1.1.3.1 i386 [...] The rpms in http://people.redhat.com/steved/rhel3/ fix the problem... Steve, I installed your rpms that fix the bug #163258 and the problem persists, look: root@mail1(click21):~# rpm -qa | egrep "^nfs-utils|^shadow" shadow-utils-4.0.3-25.RHEL3 nfs-utils-1.0.6-41EL Any tip? 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.... Steve, 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 200.255.40.220 So, I think that I can install your rpms to the others 26 servers. :-) |