Open GoogleCodeExporter opened 9 years ago
conmand doesn't currently support reloading its config file. You can force
reloading via the init script (eg, /etc/init.d/conman force-reload). This will
perform a conditional restart which restarts the service only if it is already
running.
As it stands, a SIGHUP will re-open all logfiles and re-evaluate any conversion
specifiers within those filenames.
Original comment by chris.m.dunlap
on 27 Mar 2012 at 5:25
From Hai Wu on 2013-02-20:
I am using conman from RHEL6: conman-0.2.5-2.4.el6.x86_64. And when I do
"/etc/init.d/conman reload", it does not re-read the configuration file.
It would be much better for conman to be able to reload the daemon's
configuration without the process being stopped and restarted, and thus
creating many login/logout ILO/DRAC logs ..
Original comment by chris.m.dunlap
on 21 Feb 2013 at 8:09
From Ellsworth Wente on 2013-10-08:
I'm needing to auto generate conman.conf several times a day for 4000 node
clusters as nodes get added/shifted around, but every time I have to restart,
it kills all open consoles.
Original comment by chris.m.dunlap
on 8 Oct 2013 at 10:17
Hi,
Do you have any feel for how hard this would be to implement? I'm looking at
the source and get the impression it would be achievable but there may be
gotchas I'm not aware of as I'm unfamiliar with the codebase.
Mark
Original comment by markgodd...@gmail.com
on 9 Feb 2015 at 1:34
It's certainly achievable; it's just a question of time and effort.
It will require some extensive restructuring of server-conf.c. That was
originally written assuming the configuration was static. There's no locking,
errors there are often fatal, and configuration parsing is commingled with
processing/instantiation.
It's been a while since I've been in that code, but I think you'd need to so
something like the following:
On the server side, upon receipt of a SIGHUP (i.e., when the server.c:reconfig
flag is set):
1. stat config file to see if it's changed
a. check st_dev, st_ino, st_size, and st_mtime
b. if they're all the same, no need to re-parse; otherwise...
2. parse a new config
3. lock the config
4. compute the delta between configs
a. what's been added?
b. what's been removed?
c. what's had options changed?
5. close consoles that have been removed and/or modified
6. open consoles that have been added and/or modified
7. replace the current config with the new config
8. destroy the old config
9. unlock the config
On the client side:
1. if the server closes the connection,
attempt to reconnect using an exponential backoff for successive retries
I'd need to dig into the code again to formulate a more detailed plan. But the
steps above are a starting point.
Original comment by chris.m.dunlap
on 10 Feb 2015 at 1:52
Thanks Chris, that is very helpful.
I think by far the most common use case for this (and indeed mine) would be to
add or remove consoles from the configuration dynamically. Given that, do you
think that it would be reasonable to add the restriction that only console
config entries can be modified? This could be documented as a limitation in the
same way that the current limitation is documented.
This should simplify the required change and drastically reduce the number of
tricky edge cases to consider - e.g. server port number changes etc.
Original comment by markgodd...@gmail.com
on 10 Feb 2015 at 5:09
For now, I think it would be fine to restrict reconfiguration to just
adding/removing/modifying consoles (i.e., the console directives and global
directives). The server directives can be left static.
Original comment by chris.m.dunlap
on 11 Feb 2015 at 8:57
Original issue reported on code.google.com by
si...@zombe.es
on 27 Mar 2012 at 12:57