[Bug 1795764] Re: systemd: core: Fix edge case when processing /proc/self/mountinfo

Eric Desrochers eric.desrochers at canonical.com
Mon Dec 17 17:29:25 UTC 2018 

[VERIFICATION XENIAL]

I confirm that this specific bug is now fix with that proposed package.


# Confirmation of the use of proposed systemd packages:

ii  libpam-systemd:amd64                229-4ubuntu21.11                           amd64        system and service manager - PAM module
ii  libsystemd0:amd64                   229-4ubuntu21.11                           amd64        systemd utility library
ii  libudev1:amd64                      229-4ubuntu21.11                           amd64        libudev shared library
ii  systemd                             229-4ubuntu21.11                           amd64        system and service manager
ii  systemd-sysv                        229-4ubuntu21.11                           amd64        system and service manager - SysV links
ii  udev                                229-4ubuntu21.11                           amd64        /dev/ and hotplug management daemon


# Confirmation that I ran the test on xenial

root at ubuntu:/tmp# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.5 LTS"


# Reproducer as describe in upstream bug and above in the SRU tmpl:

root at ubuntu:/tmp# mkdir -p bind-test/abc
root at ubuntu:/tmp# mount --bind bind-test bind-test
root at ubuntu:/tmp# mount -t tmpfs tmpfs bind-test/abc
root at ubuntu:/tmp# umount bind-test/abc
root at ubuntu:/tmp# systemctl list-units --all | grep bind-test
  tmp-bind\x2dtest.mount loaded    active   mounted   /tmp/bind-test                                                                                     


I also did some dogfooding here and there, BUT, since systemd is a pretty critical piece, I would appreciate more feedback from other impacted users before I can proceed with the release in xenial-updates. 

Meaning I won't change this bug to "verification-done-xenial" until
then. I'll return from vacation on the week of January 7th (mid-week)
which will give us a reasonable amount of time for impacted users and
other volunteers to test this new proposed package.

- Eric

-- 
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/1795764

Title:
  systemd: core: Fix edge case when processing /proc/self/mountinfo

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  kubernetes loaded inactive dead transient mount points grows
  https://github.com/kubernetes/kubernetes/issues/57345

  [Test Case]

  # cd /tmp
  # mkdir -p bind-test/abc
  # mount --bind bind-test bind-test
  # mount -t tmpfs tmpfs bind-test/abc
  # umount bind-test/abc
  # systemctl list-units --all | grep bind-test
  tmp-bind\x2dtest-abc.mount loaded inactive dead /tmp/bind-test/abc
  tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test

  Expected outcome (w/ the fix) :

  # cd /tmp
  # mkdir -p bind-test/abc
  # mount --bind bind-test bind-test
  # mount -t tmpfs tmpfs bind-test/abc
  # umount bind-test/abc
  # systemctl list-units --all | grep bind-test
  tmp-bind\x2dtest.mount loaded active mounted /tmp/bind-test

  [Regression Potential]

  This is a adapted version of 2 upstream fixes as the original upstream
  commit has been made on top on 2 functions mount_setup_new_unit() &
  mount_setup_existing_unit() that not yet exist systemd 229. It is
  easily adaptable because the current function mount_setup_unit() is
  dealing with both of at the moment instead of being individually
  separate in two distinct function.

  It is an adaptation of commits :
  [65d36b495] core: Fix edge case when processing /proc/self/mountinfo
  [03b8cfede] core: make sure to init mount params before calling mount_is_extrinsic()

  This patch changes mount_setup_unit() to prevent the just_mounted
  mount setup flag from being overwritten if it is set to true. This
  will allow all mount units created from /proc/self/mountinfo entries
  to be initialised properly.

  Additionally, the patch got the blessing of 'xnox' who looked at it
  and mention it looks fine to him.

  [Pending SRU]

  Note: No autopkgtests has been reported since systemd (21.5) ...
  between 21.5 and now (21.11) everything released has been about
  security fixes :

  systemd (229-4ubuntu21.11) xenial; urgency=medium ==> Current SRU
  systemd (229-4ubuntu21.10) xenial-security; urgency=medium
  systemd (229-4ubuntu21.9) xenial-security; urgency=medium
  systemd (229-4ubuntu21.8) xenial-security; urgency=medium
  systemd (229-4ubuntu21.6) xenial-security; urgency=medium
  systemd (229-4ubuntu21.5) xenial; urgency=medium ==> Previous SRU

  
  * Regression in autopkgtest for nplan (s390x): test log
  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/n/nplan/20181023_132448_031b9@/log.gz

  Error:
  modprobe: FATAL: Module cfg80211 not found in directory /lib/modules/4.4.0-138-generic

  Justification:
  This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.

  I don't think having wifi module is relevant in s390x anyway, so most
  likely the module is not there on purpose for kernel w/ s390x
  architecture.

  * Regression in autopkgtest for nplan (amd64): test log
  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/n/nplan/20181217_010129_e07e2@/log.gz

  Error: (Ran on autopkgtest Ubuntu infra)
  test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... Error: Could not create NMClient object: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL

  test_bridge_priority (__main__.TestNetworkManager) ... Error: Could
  not create NMClient object: Cannot invoke method; proxy is for a well-
  known name without an owner and proxy was constructed with the
  G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL

  test_dhcp6 (__main__.TestNetworkManager) ... Error: Could not create
  NMClient object: Cannot invoke method; proxy is for a well-known name
  without an owner and proxy was constructed with the
  G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag.FAIL

  Justification:

  The test are "passing" if ran manually in my own HW :

  autopkgtest [15:29:15]: host <MY_HOSTNAME>; command line: /usr/bin/autopkgtest nplan -U --apt-pocket=proposed --log-file /tmp/adt-proposed.out --- qemu /var/lib/libvirt/images/autopkgtest-xenial-amd64.img
  .....
  Setting up systemd (229-4ubuntu21.11) ...
  Setting up nplan (0.32~16.04.6) ...
  Setting up network-manager (1.2.6-0ubuntu0.16.04.3) ...
  ....
  test_dhcp6 (__main__.TestNetworkManager) ... ok
  test_bridge_priority (__main__.TestNetworkManager) ... ok
  test_bond_mode_balance_rr_pps (__main__.TestNetworkManager) ... ok

  I *think* that these test may eventually works, but is it really worth
  it to retry them until success if it works fine outside the Ubuntu
  infra w/ the same proposed packages ? (See attachment:
  autopkgtest_result.txt for the whole ADT log)

  * Regression in autopkgtest for nplan (armhf): test log
  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/n/nplan/20181217_132248_e07e2@/log.gz

  Error:
  Traceback (most recent call last):
    File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop
      command()
    File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 646, in command
      r = f(c, ce)
    File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 342, in cmd_reboot
      caller.hook_wait_reboot()
    File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 230, in hook_wait_reboot
      wait_booted()
    File "/home/ubuntu/autopkgtest/virt/autopkgtest-virt-lxd", line 104, in wait_booted
      VirtSubproc.check_exec(['lxc', 'exec', container_name, '--', 'sh', '-ec', '[ ! -d /run/systemd/system ] || systemctl start network-online.target'], timeout=60)
    File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 183, in check_exec
      stdout=stdout, stderr=subprocess.PIPE)
    File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 144, in execute_timeout
      (out, err) = sp.communicate(instr)
    File "/usr/lib/python3.5/subprocess.py", line 1062, in communicate
      stderr = self.stderr.read()
    File "/home/ubuntu/autopkgtest/lib/VirtSubproc.py", line 64, in alarm_handler
      raise Timeout()
  VirtSubproc.Timeout

  Justification:
  It is a recurrent failure since "systemd/229-4ubuntu21.3".
  Nothing to do with the current SRU "systemd/229-4ubuntu21.11".
  Since then quite a few SRU has been approved so I'm not too worry here.

  * Regression in autopkgtest for systemd (s390x): test log
  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/systemd/20181213_162040_4f06f@/log.gz

  Error:
  FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg'

  Justification:
  This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.

  * Regression in autopkgtest for snapd (i386): test log
  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/s/snapd/20181213_212830_ea0ac@/log.gz

  Error:
  2018-12-13 21:28:16 Failed tasks: 1
      - autopkgtest:ubuntu-16.04-i386:tests/main/dirs-not-shared-with-host:alternatives
  error: unsuccessful run

  Justification:
  This above seems to be a recurrent failure since a couple of release already. This wasn't introduce by this particular SRU.

  *
  *

  [Other Info]

  One line fix in https://github.com/systemd/systemd/pull/7811/files

  Referenced issue: https://github.com/systemd/systemd/issues/7798

  Related kubernetes issue:
  https://github.com/kubernetes/kubernetes/issues/57345

  systemd v237 has this fix, but we'd like to have it fixed in 16.04.

  It only affect systemd for Xenial, later release already has the fix:

  $ git describe --contains 65d36b495
  v237~140

  ==>  systemd | 229-4ubuntu21.4  | xenial-updates
       systemd | 237-3ubuntu10.3  | bionic-updates
       systemd | 239-7ubuntu9     | cosmic

  [Original Description]

  From the PR:
  Currently, if there are two /proc/self/mountinfo entries with the same
  mount point path, the mount setup flags computed for the second of
  these two entries will overwrite the mount setup flags computed for
  the first of these two entries. This is the root cause of issue #7798.
  This patch changes mount_setup_existing_unit to prevent the
  just_mounted mount setup flag from being overwritten if it is set to
  true. This will allow all mount units created from /proc/self/mountinfo
  entries to be initialized properly.

  One line fix in https://github.com/systemd/systemd/pull/7811/files

  Referenced issue: https://github.com/systemd/systemd/issues/7798

  Related kubernetes issue:
  https://github.com/kubernetes/kubernetes/issues/57345

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795764/+subscriptions

More information about the foundations-bugs mailing list