Forum OpenACS Q&A: Setting server configuration parameters during runtime to avoid reboot

Dear all,

I want to set a NaviServer configuration parameter (in this case ns/parameters/ReverseProxyMode) during server runtime and I need to avoid to reboot the server if possible. Looking at the documentation under (, it seems as if this was not supported.

Is there a way to add/update a configuration parameter after the server has started?

All the best,

in general, the configuration values of AOLserver/NaviServer are designed to be not-changeable at runtime (these are implemented for speed and concurrency). Many internals and user level functions assume, that these values are constant. There are a few NaviServer components, that read initial settings from the configuration parameters, that can be changed at runtime.

How comes, that you want to change the ReverseProxyMode at runtime? This is substantial change in the configuration that deserves a restart.

Thank you for the clarification!

For our production systems, we strive to avoid restarts (during working time) in general. It would be nice if it were possible to send NaviServer signals (e.g. SIGHUP or SIGUSR1) that would trigger a re-read of (a subset of) the configuration. However, for the time being, we will restart the system at not-so-busy times.

All the best!

If you have high interest in such a feature, check out the NaviServer module nsconfigrw [1]. It provides support for changeability of configuration values and addresses scalability/performance via per-thread caching.

The module has a Tcl and a C-level interface. So if all you want is the Tcl-level access, it does pretty much what you want. The C-level code of the main NaviServer modules does not use this for obvious reasons, and as mentioned before, changing the configuration value is simple compared to handling the consequences of configuration changes (implementing the e.g. life migration semantics of a change of a driver/db-port, of an ip-address, change of modules, ...). So in order to make this really useful, one would have to add as well callbacks for value-changes that address such issues on a per-parameter basis.