regression in 2.23-0ubuntu10: rsync in glusterfs's georeplication fails
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
rsync |
Unknown
|
Unknown
|
|||
rsync (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Since somewhere in the Jan 14-18 range my glusterfs georeplication reports Faulty. Georeplication uses rsync internally, and tracking this this down leads to an exit code 3 out of rsync.
I have no stacktraces myself, but I found this report about the same problem:
https:/
with traces:
strace rsync :
30743 23:34:47 newfstatat(3, "6737", {st_mode=
30743 23:34:47 newfstatat(3, "6741", {st_mode=
30743 23:34:47 getdents(3, /* 0 entries */, 131072) = 0
30743 23:34:47 munmap(
30743 23:34:47 close(3) = 0
30743 23:34:47 write(2, "rsync: getcwd(): No such file or directory (2)", 46) = 46
30743 23:34:47 write(2, "\n", 1) = 1
30743 23:34:47 rt_sigaction(
30743 23:34:47 rt_sigaction(
30743 23:34:47 write(2, "rsync error: errors selecting input/output files, dirs (code 3) at util.c(1056) [Receiver=3.1.1]", 96) = 96
30743 23:34:47 write(2, "\n", 1) = 1
30743 23:34:47 exit_group(3) = ?
30743 23:34:47 +++ exited with 3 +++
The Changelog of glibc mentions that getcwd has been changed:
* SECURITY UPDATE: Buffer underflow in realpath()
- debian/
Make getcwd(3) fail if it cannot obtain an absolute path
- CVE-2018-1000001
and downgrading glibc to (2.23-0ubuntu3) indeed fixes my georeplication problem. 0ubuntu3 is the latest version that is available in the repositories, other than 0ubuntu10.
affects: | glibc → rsync |
affects: | glibc (Ubuntu) → rsync (Ubuntu) |
Do you have strace output for the getcwd system call before the failure? That would be helpful.