Just trying to understand since I've written software with the same restart to config workflow and would like to understand what causes it to be problematic.
If reloading was an option then there wouldn't be downtime, and I wouldn't need to schedule a maintenance window for something as simple as updating an email address. The idea being that if there is a config error during a reload, the system just continues uninterrupted with the original config. If I have to stop the system completely in order to run the config sanity checks when it starts again, the potential for prolonged downtime is much greater.
Would a system that did something like an internal cut-over be useful? e.g. try to start a whole new instance of the application, if it loads, then let it become the running application, if not, write an error log and shutdown?
It would still lose all the state associated with the previous instance, e.g. user sessions, but would avoid this specific issue.
I agree that it's pretty silly that things like email addresses need a restart, but I'm wondering in general how bad this pattern is.
An interrupted session isn't a big deal if it's an infrequent occurrence and they can just login again.
I think an improved solution in this vein would be a tool that would let you sanity check the config before reloading.