This has come up before, but I am still against it.

I believe that reload-by-SIGHUP is not a desirable interface. Maybe in addition to something else to make things easy for the admin, but it should not be emphasized as the ideal interface for realoading by supporting it explicitly in systemd. Why? Simply because it's asynchronous: we just enqueue the reload but systemd does not know when it finished and the new configuration has been applied. What we want here is a synchronous reload: where systemd's service state machine actually reflects when the reload is complete and we can synchronize other jobs to that.

Now, in some cases a synchronous reload is not available, and in some cases it's irrelevant to distuingish between synchronous/asynchronous reloads for a service (and in those cases people can just invoke /bin/kill), but this still means that we shouldn't suggest people to use SIGHUP for reloading by making it natively supported in the service logic.

The right interface for reloading of a daemon could be anything synchronous, for example a dbus call, or suchlike. 

Sorry that I am against this, but I hope this explanation makes some sense.

Ok, I guess you're right. Do you have any ideas how to handle depending on external apps better?

I don't think it's really desirable to hardode paths, and using $bindir in paths to external programs doesn't seem better at all (because the required apps could be installed in any other prefix). Well, I think we'll end up using /usr/bin/env (if systemd exports useful PATH).

I don't think that /bin is likely to go away anytime soon, so I'd just go and use that path for now.

Actually I guess I should take back a bit of what I wrote here earlier. I think SIGHUP for reload can work, if we combine it with a response in some way. And there's actually something that has been suggested in a different context that might do the job nicely here: that we extend sd_notify() to allow signalling when reloading begins/ends. That way a daemon could:

a) tell us when it starts reloading, even if this was triggered from outside systemd, simply by sending sd_notify("RELOADING=1");

b) tell us when it finishes reloading, regardless how that was triggered, by sending sd_notify("RELOADING=0");

If we had that we could introduce ReloadSignal= in a safe way (and I added this now as a follow-up feature for the sd_notify() extension to the TODO list. Of course, it wouldn't work on services that have not been patched to use sd_notify().

Anyway, I hope this makes some sense.

(In reply to comment #3)
> I don't think that /bin is likely to go away anytime soon, so I'd just go and
> use that path for now.

We don't intend to symlink it in Gentoo, so if any packages move to /usr, we have to keep individual symlinks. I'd rather decrease the need for that as much as possible.

> If we had that we could introduce ReloadSignal= in a safe way (and I added this
> now as a follow-up feature for the sd_notify() extension to the TODO list. Of
> course, it wouldn't work on services that have not been patched to use
> sd_notify().

Does that mean that ReloadSignal= will work with services which don't support sd_notify() as well? IOW, just assuming these services don't support signaling like they do now with ReloadExec=.

(In reply to comment #4)
> (In reply to comment #3)

> > If we had that we could introduce ReloadSignal= in a safe way (and I added this
> > now as a follow-up feature for the sd_notify() extension to the TODO list. Of
> > course, it wouldn't work on services that have not been patched to use
> > sd_notify().
> 
> Does that mean that ReloadSignal= will work with services which don't support
> sd_notify() as well? IOW, just assuming these services don't support signaling
> like they do now with ReloadExec=.

Well, my first thou8ght would be: yes, we only would work with those using sd_notify(). But then again, it might make sense to make that part optional, if we have the code anyway... I guess that's something to revisit, when we actually implement it...