[mrtg] Include vs require [ Was adding a new probe to the cfg file ]

[Steve Shipway]

> > Now, if we're listing requests for the next version of MRTG, what I'd
> really like to have is a wildcarded Include, such as:
> >   Include: *.cfg
> > so that you never need to recreate your master.cfg when running MRTG in
> daemon mode.
>
> Won't work.  The whole advantage of daemon mode is that it only parses
> the config once.  So, it doesn't matter if you change the existing files
> or create new ones, it's still not going to be read and you still have
> to restart the daemon.  That's why I run from cron.

I see your point, but I'd still like this as it would mean you only need to re-start the daemon when you add or remove a cfg file, not change the master.cfg.  Although, if Tobi wants to be clever, he could do what routers2 does - it looks for the last modification time of the directory, and re-reads the contents if it is later than the cache time.  This is also done for .cfg files individually.  Routers2 does this so that you don't need to restart Apache when you change the .cfg files if you're using mod_perl.

> But wildcard includes might be a possibility, although it would mean I
> need to re-write my cfgmaker wrapper to clean up stale configs...
>
> > Having a missing Include: file as a warning rather than a fail would
> > be useful too, although you'd need to be able to do it both ways (your
> > global.cfg would need to be a required, but the various host.cfg files
> > can of course be missed)
>
> Correct.  We'll have to come up with a new directive for optional
> includes for backward-compatibility.  I can't very well call it
> Require: ;-)

For backwards compatibility, should Include: still create a fail on not found, and a new directive created for non-required include?  Such as:

Include-optional: filename.cfg

Or, maybe it would be better to add a second parameter to the existing include statement:

#(This is a required include)
Include: filename.cfg
#(This is an optional include)
Include: filename.cfg optional

I think I prefer the second way for backwards compatibility, although it depends on how MRTG currently parses the file.

Steve