[systemd-devel] Revisiting the "ExecRestart" issue

[Lennart Poettering]

On Fri, 28.03.14 12:12, Brandon Black (blblack at gmail.com) wrote:

> 4) Socket Activation! I know this is what some will scream when they skim
> the above, but it's not a realistic solution in this case for a few reasons:
>     a) The startup delay, in some cases, can be many whole wallclock
> seconds.  This is necessary and acceptable in the general sense (this is
> network service that people use with large server-side installations, not a
> desktop thing).

UDP is lossy anyway, and a startup delay of a few seconds shouldn't be
an issue at all. If we are speaking of 15min or so here, that might be a
problem, but otherwise this really sounds fine. And if your daemon
really takes 15min this sounds like something to look into...

>     c) Another side-point that might be better addressed in another thread:
> even if both of the above weren't true, this daemon uses several sockets
> for multiple "roles" internally, some of which share all low-level details
> (e.g. two distinct use-cases for multiple TCP sockets that serve different
> high-level protocols, where the user might choose arbitrary ports for
> both).  I'm not seeing any trivial way to distinguish these via socket
> activation - perhaps some kind of socket "label" that could be accessed by
> the daemon via sd_* APIs to distinguish would be useful here?

You can query the listening ports and properties using getsockname() and
friends. Also, sd-daemon provides sd_is_socket() which allows you to do
similar checks.

On our TODO list is to add an "fd store" concept to units where service
code can push fds to systemd, and pull them out again (to make reloads
nice). At the same time we'd add concept of labelling them.

> 5) ExecReexec - this was one of Lennart's musings in the previous thread in
> Dec2012.  However, this doesn't map well to gdnsd's model if implemented in
> the "obvious" manner of having ExecRexec send a signal to the running
> daemon to re-exec itself.  It would map well if gdnsd could respond to
> SIGFOO via fork()->execve() on itself with the "restart" verb and let the
> new instance replace itself when it's ready.  The problem is that the new
> restarting copy needs elevated privileges to bind its sockets, which it
> then loses permanently by the time it becomes a real daemon (and thus can't
> provide to the newly execve'd copy).  In some cases we could pass on the
> sockets on by clearing FD_CLOEXEC, but there's no guarantee as to what
> socket bindings the new daemon will have: typically the same as before, but
> perhaps the address or port number has changed in the config file for one
> of five different sockets.

At this point in time I am quite sure that ExecReload= should simply be
used for this.

I am quite sure that "systemctl restart" should do the same thing for
all services, and that means stopping the service, followed by starting,
and have both of these jobs follow the usual ordering dependency
logic (so that other jobs might be order between the stop/start!). 

OTOH "systemctl reload" should be that verb where some service-specific
reload operation is executed, where no restriction is made how this
ultimately is implemented, and where no ordering logic really
applies. Whether a process reexec is done for this or not is an
implementation detail of the specific service, where systemd shouldn't
really have to be involved. In general the only suggestion we'd make is
that the effect of ExecReload should be synchronous, as comprehensive as
possible, yet also as graceful as possible. Reexecing as part of reload
sounds like a good idea, if enough care is taken not to stop any ongoing
connections or transactions.

There have been some changes in systemd a while back that makes sure
that ExecReload= can replace the process, so this should pretty much
work now if the daemon is up to it.

Lennart

-- 
Lennart Poettering, Red Hat