[Bug 1840640] Re: sync_file_range fails in nspawn containers on arm, ppc
Dan Streetman
ddstreet at canonical.com
Thu Oct 10 21:24:52 UTC 2019
** Description changed:
- ARM has two sync_file_range syscalls, sync_file_range and
- sync_file_range2. The former is apparently not used, and glibc calls the
- latter whenever a userspace program calls sync_file_range. I'm guessing
- systemd-nspawn doesn't know this, because the follow code consistently
- fails in an nspawn container on ARM:
+ [impact]
+
+ calling the glibc function sync_file_range() on a armhf nspawn container
+ fails.
+
+ [test case]
+
+ see sample C program from original description below. compile and run
+ that inside a nspawn container on armhf and it will fail.
+
+ [regression potential]
+
+ this only adjusts spawn to allow the sync_file_range2 syscall which is
+ used on armhf, so the regression potential is very low. any possible
+ regressions would likely be when calling sync_file_range().
+
+ [other info]
+
+ original description:
+ ---
+
+
+ ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn container on ARM:
#define _GNU_SOURCE
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
void main()
{
- int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
- int r=sync_file_range(f, 0, 0, 0);
- if (r)
- perror("sync_file_range");
- close(f);
+ int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
+ int r=sync_file_range(f, 0, 0, 0);
+ if (r)
+ perror("sync_file_range");
+ close(f);
}
This seems to be causing problems specifically for borg(backup) and
postgres:
https://github.com/borgbackup/borg/issues/4710
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
The solution should be to cherrypick
https://github.com/systemd/systemd/pull/13352, I am currently waiting
for systemd to rebuild on a slow ARM box. Any chance of an SRU?
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd-container 237-3ubuntu10.24
Uname: Linux 4.14.66+ armv7l
NonfreeKernelModules: extcon_usb_gpio
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: armhf
Date: Mon Aug 19 11:10:48 2019
ProcEnviron:
- TERM=screen
- PATH=(custom, no user)
- LANG=en_GB.UTF-8
- SHELL=/bin/bash
+ TERM=screen
+ PATH=(custom, no user)
+ LANG=en_GB.UTF-8
+ SHELL=/bin/bash
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed:
[impact]
calling the glibc function sync_file_range() on a armhf nspawn container
fails.
[test case]
see sample C program from original description below. compile and run
that inside a nspawn container on armhf and it will fail.
[regression potential]
- this only adjusts spawn to allow the sync_file_range2 syscall which is
+ this only adjusts nspawn to allow the sync_file_range2 syscall which is
used on armhf, so the regression potential is very low. any possible
regressions would likely be when calling sync_file_range().
[other info]
original description:
---
-
- ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn container on ARM:
+ ARM has two sync_file_range syscalls, sync_file_range and
+ sync_file_range2. The former is apparently not used, and glibc calls the
+ latter whenever a userspace program calls sync_file_range. I'm guessing
+ systemd-nspawn doesn't know this, because the follow code consistently
+ fails in an nspawn container on ARM:
#define _GNU_SOURCE
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
void main()
{
int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
int r=sync_file_range(f, 0, 0, 0);
if (r)
perror("sync_file_range");
close(f);
}
This seems to be causing problems specifically for borg(backup) and
postgres:
https://github.com/borgbackup/borg/issues/4710
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
The solution should be to cherrypick
https://github.com/systemd/systemd/pull/13352, I am currently waiting
for systemd to rebuild on a slow ARM box. Any chance of an SRU?
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd-container 237-3ubuntu10.24
Uname: Linux 4.14.66+ armv7l
NonfreeKernelModules: extcon_usb_gpio
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: armhf
Date: Mon Aug 19 11:10:48 2019
ProcEnviron:
TERM=screen
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1840640
Title:
sync_file_range fails in nspawn containers on arm, ppc
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
In Progress
Bug description:
[impact]
calling the glibc function sync_file_range() on a armhf nspawn
container fails.
[test case]
see sample C program from original description below. compile and run
that inside a nspawn container on armhf and it will fail.
[regression potential]
this only adjusts nspawn to allow the sync_file_range2 syscall which
is used on armhf, so the regression potential is very low. any
possible regressions would likely be when calling sync_file_range().
[other info]
original description:
---
ARM has two sync_file_range syscalls, sync_file_range and
sync_file_range2. The former is apparently not used, and glibc calls
the latter whenever a userspace program calls sync_file_range. I'm
guessing systemd-nspawn doesn't know this, because the follow code
consistently fails in an nspawn container on ARM:
#define _GNU_SOURCE
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
void main()
{
int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
int r=sync_file_range(f, 0, 0, 0);
if (r)
perror("sync_file_range");
close(f);
}
This seems to be causing problems specifically for borg(backup) and
postgres:
https://github.com/borgbackup/borg/issues/4710
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
The solution should be to cherrypick
https://github.com/systemd/systemd/pull/13352, I am currently waiting
for systemd to rebuild on a slow ARM box. Any chance of an SRU?
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd-container 237-3ubuntu10.24
Uname: Linux 4.14.66+ armv7l
NonfreeKernelModules: extcon_usb_gpio
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: armhf
Date: Mon Aug 19 11:10:48 2019
ProcEnviron:
TERM=screen
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1840640/+subscriptions
More information about the foundations-bugs
mailing list