[systemd-devel] Using systemd to as a FD Store to provide service while package upgrade

[Lennart Poettering]

On Wed, 06.01.16 13:05, Pathangi Janardhanan (path.jana at gmail.com) wrote:

>     Currently in my package scripts I am doing a service stop and start.
> But when I need to do an upgrade, if I do a service stop, systemd clears
> all the fds. So would that mean that my package scripts would have to:
> 
>  a. In case of upgrade, do not call stop, but ensure that the fds are
> saved, and then after the upgrade, ensure that we call a service restart?
> Is it safe to remove/change the service files while it is executing?

Well, my recommendation would be to push the fds to systemd as soon as
you received them, so that systemd always has them. Then, a simple
"systemctl restart" is sufficient to restart the daemon while the fds
stay open.

By pushing the fds to PID 1 right-away when you acquire them you get a
certain level of stability regarding crashes: you can crash any time,
and systemd will allow you to continue if your daemon is restarted
after the crash right where you left off...

An alternative to pushing the fds to PID 1 right-away is to do so when
your daemon shuts down. Note that it doesn't really matter if your
daemon is restarted or shut down in this case, all fds you pass to
systemd will be closed by systemd should your service just be stopped
and not actually restarted...

>  b. In case the service package is being removed, do a normal stop in the
> scripts
> 
>    Is this approach o.k., or are there other recommendations?

This should be fully sufficient.

> 
> 2. I had also indicated in the other thread, that systemd does not seem to
> clear the fds, even if the fds are actually closed. So to repeat, the
> sequence is

See other thread, shutdown() is your friend.

> 3. Is Systemd intended for this type of fd store for upgrade handling, and
> if others have any other approaches or limitations with this approach, that
> would be welcome?

Yes, we added it explicitly for purposes like this. journald has been
made restartable using this logic. It needs to deal with many incoming
client connections, and get them passed back should it die
or get restarted. In journald we send the connection fds to PID 1
right after we got them via accept().

Lennart

-- 
Lennart Poettering, Red Hat