Hello Pegerto, or anyone else affected, Accepted systemd into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/232-21ubuntu7 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: systemd (Ubuntu Zesty) Status: Triaged => Fix Committed ** Tags added: verification-needed verification-needed-zesty -- 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/1709649 Title: 229 backport for race between explicit mount and handling automount Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Zesty: Fix Committed Status in systemd source package in Artful: Fix Released Bug description: [Impact] In systemd prior to 234 a race exists between .mount and .automount units such that automount requests from kernel may not be serviced by systemd resulting in kernel holding the mountpoint and any processes that try to use said mount will hang. A race like this may lead to denial of service, until mount points are unmounted. [Testcase] Create a race between .mount and .automount units, such that automout request is serviced after .mount unit has been started. Observe a hang. More detailed steps are available at https://github.com/systemd/systemd/pull/5916 [Butfix] Cherrypick upstream commit https://github.com/systemd/systemd/commit/e7d54bf58789545a9eb0b3964233defa0b007318 [Regression Potential] The underlying logic of starting/stopping/triggering units is unchanged. However, there the logic as to when to send automout_send_ready() is relaxed, such that it is always sent whenever unit is already mounted. This is done to explicitly cope with late arrival of the incoming [aircraft] automount request. [Original Bug report / request] Hi, We have a blocking issue in systemd for the following release ``` NAME="Ubuntu" VERSION="16.04.3 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.3 LTS" VERSION_ID="16.04" HOME_URL="http://www.ubuntu.com/"; SUPPORT_URL="http://help.ubuntu.com/"; BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"; VERSION_CODENAME=xenial UBUNTU_CODENAME=xenial ``` This release runs systemd229, we are affected by the following auto- mouting race condition ``` https://github.com/systemd/systemd/pull/5916 ``` Is back porting the fix to the release 229 an option? Regards. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1709649/+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
