rsync server bootscript - stop and status considerations

rsync at catcons.co.uk rsync at catcons.co.uk
Thu Dec 30 10:54:57 MST 2010


> Date: Wed, 29 Dec 2010 10:27:07 +0100
> From: "Alexander Dahl" <post at lespocky.de>
> To: rsync at lists.samba.org
> Subject: Re: rsync server bootscript - stop and status considerations
> Message-ID: <0LtBwl-1QUkFi1BRz-012roD at mrelayeu.kundenserver.de>
> Content-Type: text/plain; charset="windows-1252"
> 
> Hello,
> 
> sorry for the late answer, I just try to catch up with my 
> mailing lists ?
> 
> Am 15.12.2010 15:20, schrieb rsync at catcons.co.uk:
> > I want to create a boot/shutdown script including the usual 
> restart, start,
> > status and stop options (on Slackware64 13.1).  
> Netsearching for prior art,
> > I did not find any comprehensive examples.  The normal 
> technique seems to be
> > to kill the process recorded in the PID file (let's call it 
> the daemon) but
> > this does not terminate all the rsync server processes.
> 
> I did write an init script for eisfair-1? roughly one year ago. I took
> into account not killing any rsync processes running not as daemon.
> 
> > Experimenting and reading the documentation it seems that 
> rsync in daemon
> > mode spawns a worker process for each connection and they 
> in turn spawn
> > further workers.  When the daemon is killed the connection leader(s)
> > re-parent themselves to the init process and continue to run.
> 
> How did you verify this? I assume like this:
> 
>  * run the daemon
>  * start at least two client connections from somewhere
>  * see the process list
>  * kill the deamon
>  * see the process list again
> 
> > A bootscript restart or stop option should do the same; it 
> should send
> > SIGTERM to all the rsync server processes. 
> 
> Why should it? Don't the worker processes terminate when their
> transmissions are complete? I would assume it's enough to restart the
> "main" daemon.
> 
> > Similarly a bootscript status
> > option should report not only the status of the process 
> recorded in the PID
> > file but also of any worker processes.
> 
> Interesting thought. How would you implement this?
> 
> > This seems so obvious I am surprised not to have found 
> comprehensive prior
> > art so wonder if I have overlooked something basic ... ?
> 
> I don't find it that obvious, as explained above. I would just restart
> the daemon in case of a changed config for example to make new
> connections possible. I wouldn't touch running rsync 
> operations, because
> these must not be restartet, must they?
> 
> If you're interested in my script, you could extract it from
> http://www.pack-eis.de/dl.php?l=9592/rsync.tar.bz2 ? this archive
> contains a / folder structure, you should find the script in 
> /etc/init.d 8-)
> 
> Greets
> Alex

Thanks Alex :-)

I verified as you list but for only one client.

Yes -- it does make sense to decide the functionality of a boot script
before coding!

A key decision, as you highlighted, is whether to stop the rsync server (the
daemon and all its descendents) or just the daemon.  You are right to
question my assertion that a bootscript stop option should do the same as
the Linux shutdown process.  Considering what we are trying to achieve might
help decide which functionality is required.  One possibility is to have
both stop and stopall (and restart and restartall) options. 

The functionality of the start and status options is less controversial. A
start option could usefully remove a staled PID file.  My current
implementation is posted at
http://www.linuxquestions.org/questions/blog/catkin-444761/rsync-server-boot
-control-script-3452/

I was interested in your script but pack-eis.de wasn't interested in giving
it to me! ("source file could not be read" -- server glitch?)  Will try
again later.

Best      

Charles



More information about the rsync mailing list