[Bug 1840640] Re: sync_file_range fails in nspawn containers on arm, ppc

[Dan Streetman]

** 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