[Bug 1840640] Autopkgtest regression report (systemd/240-6ubuntu5.8)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (240-6ubuntu5.8) for disco have finished running.
The following regressions have been reported in tests triggered by the package:

prometheus-bind-exporter/unknown (armhf)
php7.2/7.2.24-0ubuntu0.19.04.1 (armhf)
gvfs/1.40.1-1ubuntu0.1 (ppc64el)
pdns-recursor/unknown (armhf)
webhook/unknown (armhf)
munin/2.0.47-1ubuntu3 (armhf, arm64)
systemd/240-6ubuntu5.8 (ppc64el)


Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/disco/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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