<div dir="ltr"><div><div><div><div>Hi,<br><br></div> 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 <br></div>"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)<br><br></div>Thanks<br></div>Jana<br><br><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 6, 2016 at 1:05 PM, Pathangi Janardhanan <span dir="ltr"><<a href="mailto:path.jana@gmail.com" target="_blank">path.jana@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div><div>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.<br><br></div> I am trying to provide continuous service to connected clients (over TCP socket) while my service package is being upgraded.<br><br></div> In regard to that I had a few questions on what is the best way to handle this:<br><br></div>1. When I initiate the upgrade, I have my service store the fds into systemd using the call sd_pid_notify_with_fds. <br><br></div>    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:<br></div></div><br></div> 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?<br><br></div><div> b. In case the service package is being removed, do a normal stop in the scripts<br></div><div><br></div><div>   Is this approach o.k., or are there other recommendations?<br><br></div><div>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<br><br></div><div>   a. First invocation of the service, start servicing the clients, and then store the fds in systemd<br></div><div>    b. Do a restart, the new instance gets these fds, and continues to service the clients. things work o.k.<br></div><div>    c. the client closes the connection, the service also closes all its state and connection about this client.<br></div><div>    d. I do another restart and since at this time there is no client fds, the service does not store anything with  systemd<br></div><div>    e. In the new invocation of my service, in sd_listen_fds, I still get the older fd that I had stored.<br></div><div>    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.<br><br></div><div>    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?<br><br></div><div>    What is the correct approach to handle this situation?<br><br></div><div>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?<br><br></div><div>Thanks<br></div><div>Jana<br><br></div><div><br></div></div>
</blockquote></div><br></div></div></div></div></div></div></div>