Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 286355 - GKrellMD incorrectly classifies automounted filesystems as local filesystems [explanation and proposed fix included]
Summary: GKrellMD incorrectly classifies automounted filesystems as local filesystems ...
Status: RESOLVED DUPLICATE of bug 416141
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Jim Ramsay (lack) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-25 04:18 UTC by Kevin Pyle
Modified: 2012-06-27 17:52 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pyle 2009-09-25 04:18:19 UTC
I reported this issue upstream to billw@ earlier this month, but have not received a response.  I am reposting the report here, for the benefit of other Gentoo users until he has a chance to issue a release with the fix.

This was observed on a stable amd64.  A few non-system packages, such as autofs, were installed from unstable.  There is no unstable release of gkrellm at this time.

-- Begin excerpt --

Recently, I noticed unwarranted network activity when a system running gkrellmd automounts an NFS export.  My configuration file sets both fs-interval and nfs-interval to 0.  The latter is supposed to be supported, and I misread the comment as stating that the former was also supported.  Running strace -e trace=statfs -p $(pgrep gkrellmd) showed that the gkrellmd was calling statfs both for my local mounts and for my NFS mount.  I attached gdb to the gkrellmd, which confirmed that my setting of nfs-interval=0 was translated to _GK.nfs_interval=0, and alerted me that I had misread the comment, since _GK.fs_interval was set to 2.  Since I do not use the file system monitor feature, I patched the gkrellmd code to allow fs-interval=0, and fixed a divide-by-zero crash that occurred in server/monitor.c!update_fs as a result of code that divides by _GK.fs_interval.  The shipped gkrellmd never allowed _GK.fs_interval to be zero, so the crash was introduced by my other change.  The patch consists of two sed commands executed by the ebuild: 

sed -e '/_GK.fs_interval < 1 || _GK.fs_interval > 1000/s/1/0/' \
    -i server/main.c || die "sed server/main.c failed"
sed -e 's/!(check_tick % _GK.fs_interval)/_GK.fs_interval ? & : 0/'\
    -i server/monitor.c || die "sed server/monitor.c failed"

The first changes the lower boundary from 1 to 0.  The second fixes the divide-by-zero crash that is created by the first command.

Debugging of the daemon revealed that the statfs of the NFS mount is because my /proc/mounts lists the entry twice, first with a type of "autofs" and then again with a type of "nfs".  The daemon correctly did not statfs the entry marked as "nfs", but did try to statfs the entry marked "autofs".  On a related note, the daemon currently classifies CIFS mounts as local, but SMBFS mounts as NFS.  As a quick fix, adding "cifs" and "autofs" to server/monitor.c!remote_fs_types[] should address both these issues.  I have not done or tested this, since disabling all statfs usage was adequate for my purposes.

-- End excerpt --
Comment 1 Jim Ramsay (lack) (RETIRED) gentoo-dev 2010-01-12 15:01:38 UTC
A new version of gkrellm has been added to the tree (unstable as of this moment), so please try gkrellm-2.3.4.  I don't see anything specific in the Changelog that would likely address your issue, but I'd like to just make sure this is the case.
Comment 2 Kevin Pyle 2010-01-12 17:18:51 UTC
I looked at the source for 2.3.4 when it came out, and it definitely does not have the fix I proposed here.  I did not do an exhaustive check of whether it was fixed in some other way.  I will try it out within a few days and report back.
Comment 3 Jim Ramsay (lack) (RETIRED) gentoo-dev 2012-06-27 17:52:56 UTC
Fixed in 416141!

*** This bug has been marked as a duplicate of bug 416141 ***