[Nagiosplug-devel] Re: Issues on check_disk

Voon, Ton Ton.Voon at egg.com
Mon Jun 30 10:04:05 CEST 2003

(Damn Outlook makes it hard for me to add comments inline - apologies for
appending at the top)


-w -1% is fine for clearing thresholds. Just seemed like a lot of dashes on
the command line, but you're right - the alternatives are not much better.

Fixed "check_disk warn crit [path]". This syntax had thresholds at used
levels so I've left it like that, whereas the new code is reporting and
expecting -w and -c on free levels so these two are equivalent:

check_disk -w 10% -c 5% -p /
check_disk 90 95 /

Personally, I think it is a bit peculiar to support a syntax which is a few
releases old, especially as we are breaking more current syntax...

The way it is currently coded, when -p is seen, it will "save" the last set
of thresholds specified. If a threshold is set after the path is specified,
then this will be ignored. At the moment, you can't say "check 5% for /var
and 10% for everything else" - you have to list "everything else". Is this a
limitation? If so, what syntax do you propose? Are you saying a later -w -c
without a -p means "this threshold for everything else"? 

(All this syntax stuff is making me think that threshold parameter should
really be held as object variables. I think this is how Patrol does it
(badly) - send all values back to the central server which then does the
checking of thresholds)


> -----Original Message-----
> From:	Karl DeBisschop [SMTP:karl at debisschop.net]
> Sent:	Monday, June 30, 2003 1:49 PM
> To:	NagiosPlug Devel
> Subject:	[Nagiosplug-devel] Re: Issues on check_disk
> Voon, Ton writes: 
> > The code for clearing thresholds is already there! Use -1% or -1: 
> > 
> > $ ./check_disk -v -v -v -w 10% -c 5% -p /tmp -w 10000 -c 5000 -p /var
> > DISK OK [846 MB (85%) free on /var] [1886 MB (93%) free on /tmp]
> > 846 of 992 MB (85%) free on /dev/dsk/c0t0d0s3 (type ufs mounted on /var)
> > warn:10000 crit:5000 warn%:10% crit%:5%
> > 1886 of 2034 MB (93%) free on swap (type tmpfs mounted on /tmp) warn:-1
> > crit:-1 warn%:10% crit%:5%
> I didn't have a chance to check, but I'm not surprised. 
> > $ ./check_disk -v -v -v -w 10% -c 5% -p /tmp -w 10000 -c 5000 -w -1% -c
> -1%
> > -p /var
> > DISK OK [846 MB (85%) free on /var] [1887 MB (93%) free on /tmp]
> > 846 of 992 MB (85%) free on /dev/dsk/c0t0d0s3 (type ufs mounted on /var)
> > warn:10000 crit:5000 warn%:-1% crit%:-1%
> > 1887 of 2035 MB (93%) free on swap (type tmpfs mounted on /tmp) warn:-1
> > crit:-1 warn%:10% crit%:5% 
> > 
> > Looks like any values are accepted, but checked at the end of all
> parameter
> > parsing. It looks a nightmare to read though. 
> I don't find it a nightmare to read. Not pretty, but a nightmare? Can you 
> put you finger on what you find disconcerting? 
> > Do you think it should be something else (-w C -c C?)
> I knew the checking happened late, and thought about 'undef' -- that would
> be pretty clear to a wide audience. But 'undef%' seemed odd as would 'C%'.
> I 
> don't mind accepting a short list of strings like 'undef' and 'null'
> however 
> (but I fail to see hoe 'C' is intuitive). 
> Also, -C as a option to clear all previous defaults is fine. It makes much
> more sense to me in the context of this framework. On its own, as I have 
> expressed before, it was sort of ad hoc to me. 
> I think we also need to make a clear statement on what a threshold becomes
> if it is not specified foir a drive -- is it the last one used, or is it a
> 'default' thta would be specified before and paths are specified? 
> > Also, this currently does not work: 
> > 
> > check_disk -w 10% -c 5% / /tmp /var 
> > 
> > You need to specify as: 
> > 
> > check_disk -w 10% -c 5% -p / -p /tmp -p /var 
> > 
> > I think it makes sense to do it the top way, but check_disk looks like
> it is
> > expecting: 
> > 
> > check_disk warn crit path 
> > 
> > I seem to have broken this with my latest changes. Instead of fixing
> that,
> > can I propose removing warn and crit and assume all additional
> parameters to
> > check_disk are considered as paths?
> 'check_disk warn crit path' is the oldest form of usage, but was
> originally 
> the only valid invocation. I would prefer to keep that as well, since I 
> think it can be accepted without too much trouble, it does not violate 
> POSIX, and my policy has been that reverse compatibility should be
> preserved 
> if reasonably possible. Again, if there is a groundswell of disagreement,
> I 
> will defer. But I do feel rather strenuously that old invocations should
> be 
> supported and would be decidely less happy if we choose not to go that
> way. 
> Release schedule has no core priciples attached, this does. 
>  --
> 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

More information about the Devel mailing list