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 simon@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 (e.g., /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 markgoddard86 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
   1. check st_dev, st_ino, st_size, and st_mtime
   2. 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
   1. what's been added?
   2. what's been removed?
   3. 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 markgoddard86 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