<br><div class="gmail_extra">On Thu, Nov 29, 2012 at 11:36 AM, Alexander E. Patrakov <span dir="ltr"><<a href="mailto:patrakov@gmail.com" target="_blank">patrakov@gmail.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Brandon Black <<a href="mailto:blblack@gmail.com">blblack@gmail.com</a>> wrote:<br>

> The daemon's "fast restart" code does all of the expensive startup<br>
> operations in the new daemon first (e.g. parsing large data input), then<br>
</div>This is not what a restart means in systemd world. What you described is just a nice way to do a reload. However, as the main pid changes during this reload, please be careful - several years ago that would hit an assertion in systemd, and due to my aziness I have not verified the fix.<br>
</blockquote><div><br></div><div>The current ExecReload code apparently intentionally doesn't allow for a restart-like operation, though.  If ExecReload replaces the process with a fresh PID, that PID ends up getting SIGKILL'd by systemd.  cf. this post/thread: <a href="http://lists.freedesktop.org/archives/systemd-devel/2012-June/005402.html">http://lists.freedesktop.org/archives/systemd-devel/2012-June/005402.html</a> .  I've confirmed similar behavior recently with my daemon and F18's copy of systemd.</div>
</div></div>