conmand does not re-read list of consoles on reload

[GoogleCodeExporter]

conman-0.2.7, Ubuntu 10.04

With a running conmand process, the config file is changed from:

  console name="host1" dev="ipmi:%N.ipmi"
  console name="host2" dev="ipmi:%N.ipmi"

to:

  console name="host1" dev="ipmi:%N.ipmi"
  console name="host3" dev="ipmi:%N.ipmi"

and HUP is sent to the conmand process. However, conmand still opens a console 
for host2 and does not recognize host3.

Original issue reported on code.google.com by si...@zombe.es on 27 Mar 2012 at 12:57

[GoogleCodeExporter]

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

• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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