On Sat, Mar 28, 2015 at 12:23 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: > Chris Angelico <ros...@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 -- https://mail.python.org/mailman/listinfo/python-list
