<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 23/11/2013 10:39 PM, Wayne Davison
wrote:<br>
</div>
<blockquote
cite="mid:CAHSx_St7adnNpA765V07vvjH9v_L4+nYoD3uUNVMg=dqbPFGXg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Sat, Nov 23, 2013 at 11:36 AM,
Thomas Jordan <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tomjordan766@gmail.com" target="_blank">tomjordan766@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">My
question is: can you also put a wrapper around rsync when
using the inetd (or xinetd) daemon approach to running
rsync, by adding a line for inetd</blockquote>
</div>
<br>
Yes, that would work fine for an inetd approach. For a daemon
approach, you could use a type of pid-lock mechanism using the
"pre-xfer exec" and "post-xfer exec" scripts and the
$RSYNC_PID env var. The only thing that is weird about that
is that the RSYNC_PID value is the pid of the pre-xfer exec
proc, not the pid of the transfer proc. If you want to build
in automatic lock busting, you'd need to store both the
$RSYNC_PID and the pre-xfer func's parent-pid inside the lock
file so that it can check for a running process using the
parent pid (and the post-xfer script can remove the lock based
on the $RSYNC_PID match).<br>
<br clear="all">
<div>..wayne..</div>
</div>
</div>
</blockquote>
Thanks, Wayne, I hadn't picked up on the pre-xfer exec and post-xfer
exec options.<br>
<br>
Tom<br>
</body>
</html>