<div dir="ltr">Hi Lennart,<div><br></div><div> Thanks.</div><div><br></div><div> Yes, shutdown does take care of removing the fds from the systemd context.</div><div><br></div><div> The solution seems fine and it is working good. Thanks for the help.</div><div><br></div><div>Thanks</div><div>Jana</div><div><br></div><div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 12, 2016 at 12:24 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 06.01.16 13:05, Pathangi Janardhanan (<a href="mailto:path.jana@gmail.com">path.jana@gmail.com</a>) wrote:<br>
<br>
>     Currently in my package scripts I am doing a service stop and start.<br>
> But when I need to do an upgrade, if I do a service stop, systemd clears<br>
> all the fds. So would that mean that my package scripts would have to:<br>
><br>
>  a. In case of upgrade, do not call stop, but ensure that the fds are<br>
> saved, and then after the upgrade, ensure that we call a service restart?<br>
> Is it safe to remove/change the service files while it is executing?<br>
<br>
</span>Well, my recommendation would be to push the fds to systemd as soon as<br>
you received them, so that systemd always has them. Then, a simple<br>
"systemctl restart" is sufficient to restart the daemon while the fds<br>
stay open.<br>
<br>
By pushing the fds to PID 1 right-away when you acquire them you get a<br>
certain level of stability regarding crashes: you can crash any time,<br>
and systemd will allow you to continue if your daemon is restarted<br>
after the crash right where you left off...<br>
<br>
An alternative to pushing the fds to PID 1 right-away is to do so when<br>
your daemon shuts down. Note that it doesn't really matter if your<br>
daemon is restarted or shut down in this case, all fds you pass to<br>
systemd will be closed by systemd should your service just be stopped<br>
and not actually restarted...<br>
<span class=""><br>
>  b. In case the service package is being removed, do a normal stop in the<br>
> scripts<br>
><br>
>    Is this approach o.k., or are there other recommendations?<br>
<br>
</span>This should be fully sufficient.<br>
<span class=""><br>
><br>
> 2. I had also indicated in the other thread, that systemd does not seem to<br>
> clear the fds, even if the fds are actually closed. So to repeat, the<br>
> sequence is<br>
<br>
</span>See other thread, shutdown() is your friend.<br>
<span class=""><br>
> 3. Is Systemd intended for this type of fd store for upgrade handling, and<br>
> if others have any other approaches or limitations with this approach, that<br>
> would be welcome?<br>
<br>
</span>Yes, we added it explicitly for purposes like this. journald has been<br>
made restartable using this logic. It needs to deal with many incoming<br>
client connections, and get them passed back should it die<br>
or get restarted. In journald we send the connection fds to PID 1<br>
right after we got them via accept().<br>
<span class="HOEnZb"><font color="#888888"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</font></span></blockquote></div><br></div></div></div>