I recently submitted for possible NOCOL inclusion a number
of changes.
One change was to make daemons check the timestamp of the daemon's
configuration file; if the configuration file time changes the daemon
rereads the configuration file.
Currently it seems that when the configuration file has changed,
people "kill" the daemon and either restart it -- oh yeah, I also
submitted start/stop/restart scripts for just such
purposes. Alternatively when one kills the daemon for a configuration
change, one can wait and let the keepalive monitor restart it. The
keepalive program however has no way of knowing if the program stopped
because of such a configuration change or something more serious like
a bug in the code. And the keepalive as to go through all the daemons
to find the one you know you just killed. In contrast
start/stop/restart code I submitted can "know" that a restart was
issued.
The code I wrote to reread the configuration is basically boilerplate
code that I've used many other times and have been quite happy with --
especially given what existing situation which is a bit awkward.
A couple of concerns were raised.
The first concern was this is might be too automatic -- the daemon
might automatically reread the configuration when in an inconsitent
state of modification. Having used this code quite a lot, this hasn't
been a problem. Most text editors save an internal copy of the file
while it is being worked on and they keep an "autosave" copy on disk
so that even if lots of changes are made those are saved if say the
computer or editor session crashes unexpectedly. The file is written
under the its original name only when a "save" command is issued. So
yes, one may have to be more careful and only save when the file is
consistent, but I have not found that overly cumbersome. If it is for
others, I'd suggest making a copy of the configuration file, modifying
that can copying it back when all of the changes are to one's
satisfaction. The other reason automatically rereading a configuration
file when the timestamp changes is not a problem is that the daemon
only checks the timestamp doing work; most of the time the deamon is
sleeping. In fact that the daemon *doesn't* read the configuration
file immediately after it has been changed has also been something of
an annoyance. Therefore in the perl code for hostmon, I added the
ability to send a HUP signal (such as you do for other daemons like
inetd or syslogd) which has the effect of breaking the program out of
a sleep (which is most of the time) and then the configuration file is
reread.
The second concern was that there is a bit of history or state that
one may want to save between configuration changes. For example the
when a condition first started occurring, tracking IP changes between
devices with the same name or a device name changes with the same IP
and so on.
Although this is a good thing to add and I hope it does get added, my
change doesn't attempt to address this facet. I believe this is an
independent problem that needs to be addressed. It's a problem with
the existing code as it stands. You restart a daemon which people have
to do now when there is a configuration change, and the history of
what happened before is lost. If somehow NOCOL daemons are improved so
that on startup they consult existing output data and merge them
before overwriting them, then the code I wrote would probably be able
to take advantage of that too.
I should also mention too that switching between NOCOL versions 4.3
and 4.4 makes the "merging" problem a tad more difficult because one
also has to consider different protocol formats in the output file. I
suggest then in the future output format to store the protocol version
in the data file. Although between 4.3 and 4.4 one can sort of figure
out which format is used by checking the file size to see if it a
multiple of the record size, this is not a good method -- what happens
if the output is a multiple of *both* record sizes? What happens if in
the future there is a output file protocol change that doesn't affect
the size?
Finally I should mention that the hostmon changes I've made now allow
the program write its output to syslog or a file or nowhere. There are
now many command-line switches for many of the things that one had to
edit file for before, like debugging, the configuration file location
and so on.
I still consider the hostmon changes experimental, but if folks want
to test it out, they can contact me for this code or the start/stop
code which currently works on System V-ish systems like Solaris or
Redhat-like (not Debian) Linux.
|