<div dir="auto"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon 20 Jan 2020, 16:40 Joseph C. Sible via rsync, <<a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Today, rsyncd manages its pid file by open()ing it with O_CREAT|O_EXCL<br>
at startup, and then unlink()ing it at shutdown. If the open() fails<br>
at startup because the file already exists, then rsyncd will assume<br>
another instance of itself is already running and not start.<br>
<br>
However, there's a problem with this approach: if rsyncd is terminated<br>
without being able to clean up (e.g., kill -9, or the server losing<br>
power), then the stale pid file will prevent rsyncd from ever<br>
restarting until an administrator manually intervenes.<br>
<br>
I propose a solution to this problem: open the file without O_EXCL,<br>
then try to take an exclusive lock on the whole file (we already use<br>
file locks to limit max connections, so this change wouldn't add any<br>
new requirements to rsyncd). If we can't get the lock, then abort, and<br>
if we can, then truncate the file and write our PID into it. Since<br>
locks never outlive the process that took them, this fixes the stale<br>
pid file problem.<br>
<br>
Does this seem like a reasonable idea? If so, I'll write and submit a<br>
patch that implements it.<br>
<br>
Joseph C. Sible<br>
<br>
-- <br>
Please use reply-all for most replies to avoid omitting the mailing list.<br>
To unsubscribe or change options: <a href="https://lists.samba.org/mailman/listinfo/rsync" rel="noreferrer noreferrer" target="_blank">https://lists.samba.org/mailman/listinfo/rsync</a><br>
Before posting, read: <a href="http://www.catb.org/~esr/faqs/smart-questions.html" rel="noreferrer noreferrer" target="_blank">http://www.catb.org/~esr/faqs/smart-questions.html</a><br>
</blockquote></div>