OK, so my kernel didn't have seccomp support compiled in and systemd
just silently fails to set seccomp filters in that case.

Have now reproduced the bug on an armhf disco VM, and verified that the
package in proposed, 240-6ubuntu5.8 fixes it.

** Tags removed: verification-needed-disco
** Tags added: verification-done-disco

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Fix Committed

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.

  nspawn instructions:
  sudo apt install debootstrap systemd-container
  sudo -i
  debootstrap --arch=armhf bionic ~/bionic-tree/
  systemd-nspawn -D ~/bionic-tree/

  [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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to