[Csync2] csync2 - Reaction to SIGTERM

[Lars Ellenberg]

On Mon, Aug 07, 2017 at 03:39:53PM +0200, Jonathan Keuser wrote:
> Thanks for your quick response.
> If csync2 just dies, what happens with the file I was syncing on my target
> system?


Depends on csync2 version, timing and some environmental factors.

> Do I have an incomplete file inside my filesystem or does it sync the content to
> a tempfile at first, like rsync?

csync2 version 1.something would prepare the "new" data in some temp
file, then truncate the existing one and then in chunks copy-over the
perared data into the existing now truncated one.
Yes, that could result in serious outch moments.


csync2 version 2.something would try to create a temp file next to the
target path, and then fsync/rename it over the target path,
but could potentially still fall back to the old behavior if that fails.

> If it works like rsync, will the tempfile be removed on the target system or do
> i have a dead file?

csync2 (at least in version 2.) tries to create temp files (stolen from
rsync) as .$target_basename.XXXXXX (see mkstemp) in the target directory
(so you at least have a chance to match with the actual target),
and if that fails falls back to try some other temp dirs, finaly /tmp/.
(see the paper, or source, for details).

If you crash csync2 (or the box it is running),
you will likely end up with dead files,
and would need to clean them up yourself.

Yes, SIGTERM would be considered "crashing csync2" in this context.

It should not be too hard to add a signal handler
to unlink the "current" tempfile on INT / TERM / ...
but as is, that is not implemented.

-- 
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support

DRBD® and LINBIT® are registered trademarks of LINBIT