df -k results different from snmpdf 1

[gosuc]

Hello Sun-gurus,

this question should perhaps belong into another forum, but as I have the problems only with solaris (V 8), I try to post it here.

As I need to monitor Disk-space , Cpu activity and other things that the sun agent can't provide, I disabled Suns snmpdx agent and installed the net-snmpd agent.
The agent is responding to snmp-requests, but when I request diskspace via snmpdf (which is the snmp - equivalent to df -k) , I have different results than df -k -it differs baout by 3%. The only thing that shows the same result is the total disk-space available.
Doing a snmpwalk and checking for dsk.Avail, dsk.Used and dsk.Percent Values showed the same differences with respect to df -k.

I´ve tried all sort of things to find the problem, but I'm getting nowhere now.

Perhaps someone out there has already implementet net-snmp without any problems. As I run out of ideas to solve the problem, any help would be apreciated.

Thanks in advance.

Regards,
Fred

(Excuse my poor English, please)

 

[daFranze]

Fred,

(in English, so everybody can read this... )

this might be a bug in snmpdf or a bug in df; please check 'du -sk' output vs. 'df -k' output. Do they report the same results?

What is snmpdf, an executable or a shellscript? (debugging!?)

Regards
-- Franz
Sorry I'm not a native spaeker, I'm from Munich, Germany - "Home of the Whopper", oh no, "Home of the Oktoberfest" ;-)
Solaris System Manager; I used to work for Sun Microsystems Support (EMEA) for 5 years

 

[gosuc]

Hi Franz,

it was a good idea to try both, df -k and du -sdk (I added "d" as well)

The results:

du -sdk / ---> 75803

df -k / ---> 75813
----
du -sdk /tmp --> 336
du -sdk /tmp --> 376

But no difference with the following:

du -sdk /usr --> 728738

df -k /usr --> 728738



Just for the sake of info: / = c0t0d0s0 ; /usr = c0t0s6

(perhaps some patches needed ?)

snmpdf is a binary. Until now I've used it only on Linux systems, no errors there. This utility is provided in the snmp-package by net-snmp, the successor of ucd-snmp.

Another thing, -- just in case your time allows it -- ( because I have no one knowledgeable around )...
In the process of preparing the system for network-monitoring, I had to add openssl too.I noticed during the config-and compilation phase, that there were warnings about the random-number generator. But openssl seems to be ok, because SSH (which was installed after that) works well, and it needs the openssl - libraries.
After that I compiled a program that needed openssl too (an agent progr. for the monitoring-plugins). This time, configure stopped with an error, complaining that there is no /dev/random. By checking the open-ssl FAQ's I found, that this problem was known for solaris 8, and the patch 112438-03 was recommended.
I've installed the patch with "patchadd 112438-03" with no problems.
But after reboot I still didn't find a "/dev/random". By trying to reinstall the package I got the Information, that one or more packages contained in 112438 are not installed and patchadd terminated. After checking that with patchadd -p I saw only 3 of 6 packages under 112..., SUMW... etc.
But these packages are all there in the unzipped patch-directory.

I was not aware I would face such problems and if I would, I would have startet with the sun - box first.

Any ideas where I made mistakes?


Regards,

Fred

bigcheeks

 

[daFranze]

Fred,

I'm not sure, whether the ssl problems are in coherence with the snmp problems; if snmp package compiles and runs everything is fine...
I am running nagios as system monitoring; it comes along with an Oracle plugin, the script resultet some strange messages, so I debugged it and fout out that the result of a calculation was float but the container was int, the automatic cast failed, I had to write a workaround.

I guess your snmpdf is something similar OR realy a bug in a Solaris systemcall!

I recommend to procede the following:
doublecheck the patches (there is a 'patchdiag' Tool on sulsolve.sun.de) and install missing patches such as ufs Patches etc. or install Recommended Patch Cluster.

If you have problems installing a patch:
create a LOCAL! Directory eg. /patches
move the Patch.ZIP file to this directory
unzip AS ROOT!
boot to single user mode and install the patch (I saw a lot of problems, when people copy patches around or unzip patches as a user)

if / or /tmp have different output (just a few blocks) I wouldn't worry; you can doublecheck this: boot from cdrom, mount / to /a and run du and df on /a

Sorry, I am not realy familiar to ssl and /dev/random...

Regards
-- Franz
Sorry I'm not a native spaeker, I'm from Munich, Germany - "Home of the Whopper", oh no, "Home of the Oktoberfest" ;-)
Solaris System Manager; I used to work for Sun Microsystems Support (EMEA) for 5 years

 

[gosuc]

Hi Franz,

the problems are solved.

As mentioned in the posts before, a random numbergenerator is needed for the ssl encryption business. The Patch-description said, the included file is /kernel/drv/sparcv9/random. So I scanned the system for a "random" file and found one in /kernel/drv/random - aparently independent of the patch. Knowing that, I just createt a link from /dev/random to
/kernel/drv/random and that was it. Now I could compile the agent-program, that needed SSL. (By the way, it is the nrpe V.2 from Nagios) , which is SSL-enabled, contrary to nrpe V1.x. Perhaps there is a more professional solution, but as I am under real time-pressure, I postpone the cosmetics for the weeks to come - that includes of course all patch-installations.

If you are working with nagios, perhaps you are also using SMS-notification.

As I start with nagios, I'd be interested how you configured that.
But that is something that doesn't necessarily belong into the Solaris forum.

Have a nice day and thank you for all the tips.

Regards,

Fred