Your message dated Wed, 12 Oct 2016 11:56:37 +0200
with message-id <20161012095636.ga30...@msgid.wurtel.net>
and subject line Re: Bug#505108: rsync in some cases fails to detect disk full
has caused the Debian Bug report #505108,
regarding rsync in some cases fails to detect disk full
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
505108: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505108
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Subject: rsync in some cases fails to detect disk full condition
Package: rsync
Version: 3.0.3-2
Severity: important
The rsync client will get stuck in some scenarios
if a disk full condition occurs at the server side.
In a rsycnc-based backup system (network connection via ssh),
I am running into a nasty problem.
Actually, it is a combination of 2 problems:
1) If on the client side a filesystem is mounted after rsync has
started, it will include this filesystem, even if called with
"--one-file-system" (which is sad, but probably would be very
hard to avoid due to the design of rsync)
2) If in this situation the server runs out of disk space (which is
likely to happen if the accidentally included file system is large),
the server notices the error but obviously just exits without
notifying the client which doesn't notice the error and hangs until
killed.
The server writes something like this to the syslog:
rsyncd[8493]: receiving file list
rsync: write failed on \"/some/file\" (in backup): No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(298) [receiver=3.0.3]
connection unexpectedly closed (550 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(635)
[generator=3.0.3]
while on the client side there is no indication that something went
wrong.
In general, the handling of "disk full" conditions on the server side
seems to vary (I guess, depending on what exactly fails) and is not
always really gracefull (often the log gets flooded with error
messages for every single failed operation), but at least eventually
all processes will terminate and the client will notice that something
went wrong.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages rsync depends on:
ii base-files 4.0.5 Debian base system miscellaneous f
ii libacl1 2.2.47-2 Access control list shared library
ii libc6 2.7-15 GNU C Library: Shared libraries
ii libpopt0 1.14-4 lib for parsing cmdline parameters
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
rsync recommends no packages.
Versions of packages rsync suggests:
ii openssh-client 1:5.1p1-3 secure shell client, an rlogin/rsh
ii openssh-server 1:5.1p1-3 secure shell server, an rshd repla
-- no debconf information
--- End Message ---
--- Begin Message ---
On Mon 28 Mar 2016, Bo Kersey wrote:
> This has been fixed with a newer upstream version. I have verified it works
> in v3.1.1
>
> On the server side (pulling from a remote client)
> rsync: write failed on
> "/test/cd-images/centos/CentOS-5.10-i386-bin-DVD/CentOS-5.10-i386-bin-DVD-1of2.iso":
> No space left on device (28)
> rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.1]
>
> On the client side rsync just exits.
Agreed and also verified by me with 3.1.2.
Now closing this bug report.
Thanks,
Paul
--- End Message ---
