What is elegant way to do configuration on server app

[Chris Angelico]

On Sat, Mar 28, 2015 at 12:23 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> The number of cases where this matters is fairly low. Doing the reload
>> asynchronously is generally sufficient.
>
> Not sure. Not sure at all. Issues like this occupy a great part of my
> office hours.

Only because your office hours are occupied by problems, not by the
cases that work flawlessly. You don't see the innumerable times that
fire-and-forget works fine :)

>> And even if you have something that waits for the reload to finish,
>> you'll usually fire-and-forget that command anyway.
>
> The command
>
>    systemctl reload xyz.service
>
> is supposed to return when the service is happily running with the
> updated its configuration.
>
> Any failures should be reported with a nonzero exit code from
> "systemctl".

Sure. But how often do you actually need that, compared to the number
of times when you deploy an updated config that was working fine on
your test system, signal a reload, and off you go? You don't need to
wait for it to finish; you'll see errors in the log, if there are any,
and most likely there won't (your test system IS virtually identical
to live, right?). I have scripts that edit config files and pop off
SIGHUPs, usually in response to external events, and they neither need
nor want to wait. It's pretty common.

>> For maximum portability, most programs are going to want to continue
>> to respond to SIGHUP, even if they do a systemd-triggered reload some
>> other way.
>
> I disagree. You can't just assume you can send a SIGHUP to a daemon for
> the LOLs. You must first discover the trick in the documentation.
>
> The default reaction to SIGHUP is to crash. A daemon (which has detached
> from the controlling terminal) is within its rights to do just that.

Sure it can, and you do need to know what you're sending signals to.
But if you're unsure how to reload a daemon, the easiest way to probe
it is to send it a SIGHUP (on your test system, of course), and see if
it's still running afterwards. And once you know that this process
responds thusly to SIGHUP, you can do this many *many* times more,
never needing to worry about it. I would guess that there are
hundreds, maybe thousands, of times when you can safely
fire-and-forget, for every one that you actually need to wait on it -
where you need some other action to be delayed until the reload is
complete.

ChrisA