[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
This was fixed in snapd in 2.44 via https://github.com/snapcore/snapd/pull/8467 ** Changed in: snapd (Ubuntu) Status: In Progress => Fix Released ** Changed in: snapd (Ubuntu Focal) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in snapd: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in snapd package in Ubuntu: Fix Released Status in zsys package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Released Status in snapd source package in Focal: Fix Released Status in zsys source package in Focal: Invalid Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
Adding a snapd Ubuntu task, marking as In Progress and assigning to mvo since he is preparing a 20.04 upload. ** Also affects: snapd (Ubuntu) Importance: Undecided Status: New ** Changed in: snapd (Ubuntu Focal) Assignee: (unassigned) => Michael Vogt (mvo) ** Changed in: snapd (Ubuntu Focal) Status: New => In Progress ** Changed in: snapd (Ubuntu Focal) Importance: Undecided => High ** Changed in: snapd (Ubuntu Focal) Milestone: None => ubuntu-20.04 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in snapd: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Status in zsys package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Released Status in snapd source package in Focal: In Progress Status in zsys source package in Focal: Invalid Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
** Changed in: snapd Status: In Progress => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in snapd: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in zsys package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Released Status in zsys source package in Focal: Invalid Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
Daniel, this is a different cause but same result: zfs-load-module.service (2ms) zfs-import-cache.service (8ms) zfs-import.target ... var-lib.mount (69ms) ... snap-multipass-1869.mount (1.358s) ... apparmor.service (279ms) ... In this case, apparmor correctly waited for var.lib.mount, but multipass started before apparmor.service completed. ** Also affects: snapd Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in snapd: New Status in apparmor package in Ubuntu: Fix Released Status in zsys package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Released Status in zsys source package in Focal: Invalid Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
Daniel responded on irc and said after several reboots with the new apparmor, everything was fine on every boot (though his critical-chain has var.lib.mount listed). My attached systemd-analyze plot svg shows that apparmor.service is indeed starting after var.lib.mount on the VM where the critical-chain didn't show it or zfs. On irc Didier thought that critical-chain would only list the longest path to apparmor.service starting and may not show everything (the man page isn't clear on this point IMHO). Based on all of this, I'm going to tentatively mark the zsys task back to Invalid. If people continue to see this bug, we can reopen as necessary (in which case it might be a systemd task for not generating the mount units/requires/after correctly/in a race-free manner or it might indicate zfs initialization is perhaps slow and apparmor.service is starting before var.lib.mount is generated (and therefore RequiresMountsFor is satisfied. Or it is something else ;) ** Changed in: zsys (Ubuntu Focal) Status: New => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in apparmor package in Ubuntu: Fix Released Status in zsys package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Released Status in zsys source package in Focal: Invalid Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
All that said, Daniel and Jean-Baptiste, I installed 20.04 in a vm and tried to reproduce this and could not. The apparmor change was about correctness of the unit so I performed the upload, but I also hoped that it would address the issue you are seeing. I'm not certain it will. On one boot, prior to upgrading apparmor, I saw: $ sudo systemd-analyze critical-chain apparmor.service The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. apparmor.service +11.135s └─local-fs.target @4.376s └─zfs-mount.service @4.327s +48ms └─var-lib-dpkg.mount @4.188s +137ms └─var-lib.mount @3.883s +250ms └─zfs-import.target @3.829s └─zfs-import-cache.service @3.125s +704ms └─zfs-load-module.service @3.121s +2ms └─systemd-udev-settle.service @1.183s +1.937s └─systemd-udev-trigger.service @933ms +248ms └─systemd-udevd-kernel.socket @886ms └─system.slice @535ms └─-.slice @535ms Note that var-lib.mount is already listed. On reboot though (without updating apparmor), I see: $ sudo systemd-analyze critical-chain apparmor.service The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. apparmor.service +101ms └─local-fs.target @2.812s └─run-user-122.mount @5.172s └─swap.target @1.823s └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap @1.799s +22ms └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device @1.798s Oddly, no zfs entries are listed apparently because local-fs.target isn't pulling them in: $ sudo systemd-analyze critical-chain local-fs.target The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. local-fs.target @2.812s └─run-user-122.mount @5.172s └─swap.target @1.823s └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap @1.799s +22ms └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device @1.798s Looking at var-lib.mount, I see zfs is in there: $ sudo systemd-analyze critical-chain var-lib.mount The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. var-lib.mount +179ms └─zfs-import.target @2.248s └─zfs-import-cache.service @1.845s +402ms └─zfs-load-module.service @1.840s +2ms └─systemd-udev-settle.service @692ms +1.143s └─systemd-udev-trigger.service @524ms +167ms └─systemd-udevd-kernel.socket @494ms └─system.slice @357ms └─-.slice @357ms So why after a reboot did the dependencies change and drop the /var/lib entry from local-fs.target? I then upgraded apparmor to have the RequiresMountsFor /var/lib/snapd/apparmor/profiles, rebooted and saw no difference: $ sudo systemd-analyze critical-chain apparmor.service The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. apparmor.service +222ms └─local-fs.target @2.562s └─run-user-122.mount @4.834s └─swap.target @1.687s └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap @1.663s +24ms └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device @1.662s ** Changed in: zsys (Ubuntu Focal) Status: Invalid => New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in apparmor package in Ubuntu: Fix Released Status in zsys package in Ubuntu: New Status in apparmor source package in Focal: Fix Released Status in zsys source package in Focal: New Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
This bug was fixed in the package apparmor - 2.13.3-7ubuntu4 --- apparmor (2.13.3-7ubuntu4) focal; urgency=medium * debian/apparmor.service: add /var/lib/snapd/apparmor/profiles to RequiresMountsFor since Ubuntu's rc.apparmor.functions looks for it (LP: #1871148) * libnss-systemd.patch: allow accessing the libnss-systemd VarLink sockets and DBus APIs. Patch partially based on work by Simon Deziel. (LP: #1796911, LP: #1869024) * upstream-mr-424-kerberos-dot-dirs.patch: abstractions/kerberosclient: allow reading /etc/krb5.conf.d/ * upstream-mr-442-gnome-user-themes.patch: gnome abstraction: allow reading per-user themes from $XDG_DATA_HOME (Closes: #930031) * upstream-mr-443-ecryptfs-dirs.patch: abstractions/base: allow read access to top-level ecryptfs directories (LP: #1848919) * upstream-mr-445-uuidd-request.patch: abstractions/base: allow read access to /run/uuidd/request * upstream-mr-464-Mesa_i915_perf_interface.patch: let Mesa check if the kernel supports the i915 perf interface. Patch from Debian -- Jamie Strandboge Mon, 06 Apr 2020 17:47:20 + ** Changed in: apparmor (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in apparmor package in Ubuntu: Fix Released Status in zsys package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Released Status in zsys source package in Focal: Invalid Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
There is nothing to do on zsys's side. mount points are generated by the zfs generator and mount order is set by systemd. apparmor must wait until all its requirements are met to start which is what Jamie's fix does. Closing zsys task. ** Changed in: zsys (Ubuntu Focal) Importance: Critical => Undecided ** Changed in: zsys (Ubuntu Focal) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in apparmor package in Ubuntu: Fix Committed Status in zsys package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Committed Status in zsys source package in Focal: Invalid Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
Reassigning the snapd task to apparmor in Ubuntu since it has a patch to rc.apparmor.functions to look for /var/lib/snapd/apparmor/profiles but does not add it to RequiresMountsFor. ** Project changed: snapd => apparmor ** Changed in: apparmor Status: Confirmed => In Progress ** Changed in: apparmor Importance: Critical => Undecided ** Changed in: apparmor Status: In Progress => Invalid ** Also affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Changed in: apparmor (Ubuntu Focal) Status: New => In Progress ** Changed in: apparmor (Ubuntu Focal) Importance: Undecided => Critical ** Changed in: apparmor (Ubuntu Focal) Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in apparmor package in Ubuntu: In Progress Status in zsys package in Ubuntu: Confirmed Status in apparmor source package in Focal: In Progress Status in zsys source package in Focal: Confirmed Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
** Also affects: zsys (Ubuntu) Importance: Undecided Status: New ** Changed in: zsys (Ubuntu) Status: New => Confirmed ** Changed in: zsys (Ubuntu) Importance: Undecided => Critical ** Also affects: zsys (Ubuntu Focal) Importance: Critical Status: Confirmed ** Changed in: zsys (Ubuntu Focal) Milestone: None => ubuntu-20.04 ** Changed in: zsys (Ubuntu Focal) Assignee: (unassigned) => Jean-Baptiste Lallement (jibel) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded Status in snapd: Confirmed Status in zsys package in Ubuntu: Confirmed Status in zsys source package in Focal: Confirmed Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1871148/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
