check_disk syntax question

[Voon, Ton]

My guess is that the numbers returned by df -k are v high (> 2^31 signed).
This means that the integer that holds the values overflow, hence your
negative results.

I've just been reading up large numbers and it seems that what may need to
happen is that the data types for disk_used and total_used should be floats
(to allow numbers up to 3.4E+38) and the subsequent printf formats altered
to reflect. I think I've seen this problem on the CVS HEAD version of
check_disk too.

Try this patch for check_disk.c against r1.3.0. It works on my Sun 2.6
system, but I don't have huge disk to test against!
 <<check_disk.patch_for_floats.c>> 

Let us know how you get on.

Ton

> -----Original Message-----
> From:	Webster, Stuart SITI-ITDIUR [SMTP:Stuart.Webster at shell.com]
> Sent:	Wednesday, June 18, 2003 12:49 PM
> To:	Nagios Users
> Subject:	RE: [Nagios-users] check_disk syntax question
> 
> Regarding the below problem, i see that all the filesystems that give the
> incorrect reading with check_disk are samfs file systems!!. I guess
> check_disk just cant get an accurate reading of samfs, unless anyone knows
> a way???
> 
> help appreciated.
> 
> Stu
> 
> -----Original Message-----
> From: Webster, Stuart SITI-ITDIUR 
> Sent: 18 June 2003 09:55
> To: Karl DeBisschop
> Cc: Nagios Users
> Subject: RE: [Nagios-users] check_disk syntax question
> 
> 
> Thanks for reply...
> the plugin is 
> ./check_disk -V
> check_disk (nagios-plugins 1.3.0) 1.7
> 
> and nagios is version 1.0.
> and both machines are solaris 8
> 
> I thought it was very wierd as well, but i thought my syntax might have
> been wrong.
> 
> cheers
> 
> Stu
> 
> -----Original Message-----
> From: Karl DeBisschop [mailto:karl at debisschop.net]
> Sent: 18 June 2003 05:43
> To: Webster, Stuart SITI-ITDIUR
> Cc: Nagios Users
> Subject: Re: [Nagios-users] check_disk syntax question
> 
> 
> On Tue, 2003-06-17 at 11:04, Webster, Stuart SITI-ITDIUR wrote:
> > Hello all
> > 
> > I am using check_disk plugin to monitor some very large file systems.
> > I was monitoring using percentages, but this is pointless, because
> > when you ar 99% full, you still have lots of space.
> > 
> > so I changed to a minimum killobytes check, now i get critical
> > messages for every disk i check,  probably something obviously wrong
> > in what im doing.
> > 
> > Here is one of my filesystems
> > #df -k
> > sw017    4164728832 858727296 3306001536    21%    /sw017
> > 
> > and here is my nrpe command
> > command[check_sw017]=/nagios/libexec/check_disk -c 1000000 -w 1500000
> > -m /sw017
> > 
> > im trying to set it to 1.5 gb warning, and 1gb crit.
> > 
> > but i get this error every time.
> > DISK CRITICAL [-988965760 kB (79%) free on /sw017] 
> > 
> > 
> > is my sytax wrong????
> 
> What plugin version on the remote machine?
> 
> ISTM there must be a bug, unless you've figured out how to store more
> bytes on a disk than its total capacity (which I take to be the meaning
> of les than 0 bytes free).
> 
> OOTH, if you have figured out a way to create this extra capacity, when
> you take out the patent please be sure you do not mention 'Unix' in the
> application, otherwise SCO may assert ownership ;-)
> 
> --
> Karl
> 
> 


This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
carries out investment business on behalf of Egg and is regulated
by the Financial Services Authority.  
Registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have
received it in error, please notify the sender by replying with
'received in error' as the subject and then delete it from your
mailbox.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_disk.patch_for_floats.c
Type: application/octet-stream
Size: 2743 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/users/attachments/20030618/fe79d3ec/attachment.obj>