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

[Pathangi Janardhanan]

Hi,

 To add, another issue with systemd holding on to the service fds is that
if after a restart, the service does a sd_listen_fds gets the saved fds and
starts providing the service. Later on if the service decides to close a
connection than it performs a close, but the remote client is not going to
see the close, since systemd is still holding on to that fd? So we need to
have a mechanism to be able to tell systemd to
"forgot" all the fds that it is holding on behalf of this service (except
for the fds that are coming through the .socket socket invocation)

Thanks
Jana


On Wed, Jan 6, 2016 at 1:05 PM, Pathangi Janardhanan <path.jana at gmail.com>
wrote:

> Hi,
>
> I had a previous thread on some issues in using sd_pid_notify_with_fds,
> but started this as a separate thread, as this is not just about that call,
> which anyway seems to be because I am using a older version.
>
>  I am trying to provide continuous service to connected clients (over TCP
> socket) while my service package is being upgraded.
>
>  In regard to that I had a few questions on what is the best way to handle
> this:
>
> 1. When I initiate the upgrade, I have my service store the fds into
> systemd using the call sd_pid_notify_with_fds.
>
>     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?
>
>  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?
>
> 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
>
>    a. First invocation of the service, start servicing the clients, and
> then store the fds in systemd
>     b. Do a restart, the new instance gets these fds, and continues to
> service the clients. things work o.k.
>     c. the client closes the connection, the service also closes all its
> state and connection about this client.
>     d. I do another restart and since at this time there is no client fds,
> the service does not store anything with  systemd
>     e. In the new invocation of my service, in sd_listen_fds, I still get
> the older fd that I had stored.
>     f. currently in my service, this is not a problem, since when my
> service tries to do a select on these fds, it gets a notification and then
> closes out the fd.
>
>     But this behaviour could cause some issues later on, and also since
> systemd does not seem to ever let go of the fds, If i continue to do many
> restarts, would the set of fds build up to a large set in systemd?
>
>     What is the correct approach to handle this situation?
>
> 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?
>
> Thanks
> Jana
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20160106/b2adf8cb/attachment-0001.html>