The network tests in LTP require the presence of 'rpc.rstatd' but I've been unable to locate it via `emerge --search rpc.rstatd` nor via googling against site:gentoo.org. I suspect it should be part of netkit-base, or else part of xinetd, but I've installed both of those packages and neither includes it. Could you point me in the right direction? Thanks, Bryce
net-fs/nfs-utils has rpc.statd, if that's not what you want, then provide some real information about which package should distribute this.
I don't think rpc.statd and rpc.rstatd are equivalent. rpc.statd is a daemon used by the NFS locking service. rpc.rstatd is a program to remotely monitor kernel statistics such as load, interrupts, etc. LTP tests for rpc.rstatd (note the 'r'), to measure compliance with the SunRPC standard. Gentoo currently fails against the Linux Test Project's network test case 'rup01' due to this lack. The specific test is here: http://cvs.sourceforge.net/viewcvs.py/ltp/ltp/testcases/network/rpc/rup/rup01?rev=1.2&view=auto The test fails as follows: <<<test_start>>> tag=rup stime=1134770895 cmdline="export TCbin=$LTPROOT/testcases/network/rpc/rup; rup01" contacts="" analysis=exit initiation_status="ok" <<<test_output>>> Checking for rstatd on cl009 Attempting to start rstatd on cl009 bash: line 1: /usr/sbin/rpc.rstatd: No such file or directory rstatd started on cl009 Test rup with defaults....please be patient rup Test rusers with options set...please be patient rup cl009 rup: cl009: RPC: Program not registered rup01: doing /usr/src/ltp-full-20050405/testcases/bin/rup01. bash: line 1: kill: (11199) - No such process rstatd daemon stopped on cl009 Test Failed: rup cl009 - failed The definitive source of the rstatd program appears to be the following sourceforge page: http://rstatd.sourceforge.net/ http://sourceforge.net/projects/rstatd The effect of implementing this fix will be to make gentoo more LTP-compliant with the RPC standards. Thanks, Bryce
(In reply to comment #2) > http://rstatd.sourceforge.net/ > http://sourceforge.net/projects/rstatd Not in portage, sorry... If you care enough, submit an ebuild.
Nah, I'll just mark gentoo as failed on this.
Created attachment 93264 [details] rstatd-4.0.1.ebuild I've just created an ebuild for rpc.rstatd.
Created attachment 93265 [details] rstatd.initd /etc/init.d/rstatd
Although I created it I'm afraid I don't want to maintain this ebuild as I'm not network system expert. (I just made it for my lab maintainance) Feel free to take this ebuild. Thanks in advance.
The statistics could be collected through any of the following: 1. http://jperfmeter.sourceforge.net/ 2. textmeter from http://sourceforge.net/project/showfiles.php?group_id=27012 3. $ /usr/dt/bin/sdtperfmeter othermachine 4. $ gnome-perfmeter othermachine 5. $ rup (provided in this rstatd-4.0.1 package)
Created attachment 149388 [details] rstatd-4.0.1-r1.ebuild Include also the patch available at sourceforge site.
Created attachment 149390 [details] rstatd files/rstatd to be installed as /etc/init.d/rstatd
Created attachment 149392 [details] xinetd.rstatd Sample /etc/xinetd.d/rstatd file NOT being installed by the ebuild. The ebuild installs /etc/init.d/rstatd as a general solution.
Created attachment 149393 [details, diff] rstat_initialize_fromlen.patch Patch for bug #1546060 at http://sourceforge.net/tracker/index.php?func=detail&aid=1546060&group_id=27012&atid=388924
Created attachment 149394 [details, diff] rpc.rstatd-netstats.patch Fix for bug #1529174 from http://sourceforge.net/tracker/index.php?func=detail&aid=1616546&group_id=27012&atid=388926
Created attachment 149396 [details] rstatd-4.0.1-r2.ebuild Two patches from sourceforge apply to this version (4.0.1), 2 other patches are against much older version (3.x) only -- one of them fixed(es) some int overflows in the code and the other added some extra disk and VM stats to the output. Somebody should audit the code first before pushing this into portage tree. http://www.google.com/search?hl=en&q=bugtraq+rstatd&btnG=Google+Search
Joerg Ahrens had a look whether those 2 patches are really applied to this source tree at sourceforge in 4.0.1 and indeed, they are.
It seems 4.0.1 (which, for the record, was released in December 2005) is the last version released by upstream. Not a good sign for software which exposes potentially sensitive information over networks... Just to be in the clear, though - is there still any interest in adding this to the tree? If not, the bug will be closed as WONTFIX in 30 days.
