[mrtg] Re: "include" in mrtg.cfg?
swb at cmenoc.campbell-mithun.com
Wed Aug 16 16:33:23 MEST 2000
----- Original Message -----
From: "Jason Frisvold" <Jason.Frisvold at corp.ptd.net>
| I'm not so sure this would be such a great thing... I guess it would
| it's application somewhere, but if you've broken things up into
| config files, wouldn't that normally be because you want to run
| processes? Seeing that you can comment the config file, I don't see
| being a real advantage...
| Now, if you could specify multiple configs (include lines or command
| and mrtg would spawn a separate process for each, that would kick
| And perhaps even an option to stagger the starts of each config by a
| specified time so they're not completely overlapping? ... Hrm.. I
| learn perl...
There's no reason you couldn't cobble something like this together. I
keep a seperate .cfg file for each device I monitor; when I run mrtg
from cron I run a script that concats all the individual .cfg files
along with a master "header" into a single .cfg file which I then use
when calling mrtg.
What you could do instead of concating them all together into one cfg
file is figure out how many mrtg processes you want to spawn and concat
your individual configs into that many unique config files and then run
mrtg against each config. This'd give you a manually "forked" mrtg.
I haven't done this with my script, I'm running uniprocessor so forking
doesn't buy me that much. I imagine that there would be some issues
with mrtg not wanting to run multiple instantations of itself (it checks
for PID file doesn't it?) but that would trivial to kludge, er, fix.
Probably a lot simpler than trying to make mrtg multithreaded.
Now that I'm thinking about it, what's gained by forking/threading mrtg,
anyway? Ie, where's the bottleneck? Is it in picture generation, log
updates, or the snmp queries?
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
FAQ http://faq.mrtg.org Homepage http://www.mrtg.org
More information about the mrtg