[ixpmanager] MRTG - Restart on config changes?

[Ian Chilton]

Hi,

I’m interested what users are actually doing in practise - are you
letting MRTG pick up config changes, or forcing a restart on update?

(Am particularly interested in those running Debian/Ubuntu).


The IXP Manager documentation states:

> The above assumes that MRTG automatically reconfigures itself when
> the configuration changes as stated in the MRTG documentation for
> RunAsDaemon. We have seen inconsistent behaviors for this and
> if it does not work for you, you will need to add a step to
> restart the MRTG daemon to the reconfiguration script above
> (at the very end).


But the MRTG documentation contradicts itself:

> Also note that in daemon mode restarting the process is required
> in order to activate changes in the config file.

… but later ..

> If the modification date on the configuration file changes
> during operation, then MRTG will re-read the configuration on
> the next polling cycle.


I’ve implemented a forced restart on config updates, using
systemd path units (running on Debian) as my initial thought
was that it wouldn’t harm to make sure it was loading changes.

But now I’m wondering what happens if MRTG gets restarted in the
middle of a polling…

- can you end up with corrupt data because it’s written half
  the run and then got stopped?

- does it cause anything visual on the graph as one of the 5
  minute intervals is missing?

- or does it do the right thing on restart and detect that
  the last run was interrupted and repeat/finish?


I’m now wondering whether it really is better to run it as a
deamon, over cron? - obviously running it as a daemon you
don’t have to start up and parse the config on each run, but
the benefit with cron is you get a guaranteed run every 5
mins, with it automatically using the latest config - so there
are no problems of config loading or daemon dying to deal with.

Is there a big benefit to running as a daemon?

Thanks,

Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20210217/6ff7778c/attachment.htm>