Seth, the service starts fine if snapd is not installed and the
mountpoint is not present.
$ sudo systemctl status apparmor
● apparmor.service - Load AppArmor profiles
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor
preset: enabled)
Active: active (exited) since Wed 2020-04-08 07:05:57 CDT; 3min 9s ago
Docs: man:apparmor(7)
https://gitlab.com/apparmor/apparmor/wikis/home/
Process: 309 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited,
status=0/SUCCESS)
Main PID: 309 (code=exited, status=0/SUCCESS)
Apr 08 07:05:58 sec-focal-amd64 apparmor.systemd[309]: Restarting AppArmor
Apr 08 07:05:58 sec-focal-amd64 apparmor.systemd[309]: Reloading AppArmor
profiles
Apr 08 07:05:58 sec-focal-amd64 apparmor.systemd[320]: Skipping profile in
/etc/apparmor.d/disable: usr.bin.firefox
Apr 08 07:05:58 sec-focal-amd64 apparmor.systemd[325]: Skipping profile in
/etc/apparmor.d/disable: usr.sbin.rsyslogd
Warning: journal has been rotated since unit was started, output may be
incomplete.
The service is not delayed on boot:
$ 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 +183ms
└─local-fs.target @526ms
└─run-user-125-gvfs.mount @6.196s
└─run-user-125.mount @5.831s
└─local-fs-pre.target @526ms
└─keyboard-setup.service @195ms +330ms
└─systemd-journald.socket @173ms
└─system.slice @170ms
└─-.slice @170ms
Compare this with before snapd was removed:
$ 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 +278ms
└─local-fs.target @1.073s
└─run-user-125-gvfs.mount @10.509s
└─run-user-125.mount @9.900s
└─local-fs-pre.target @756ms
└─keyboard-setup.service @369ms +386ms
└─systemd-journald.socket @334ms
└─system.slice @329ms
└─-.slice @329ms
The systemd documentation
(https://www.freedesktop.org/software/systemd/man/systemd.unit.html)
say:
"RequiresMountsFor: Takes a space-separated list of absolute paths.
Automatically adds dependencies of type Requires= and After= for all
mount units required to access the specified path."
Furthermore, I read the systemd code and for each RequiresMountsFor
entry, it will start with the entry, then see if there are mount entries
for each path going up to '/', only adding the Requires and After if
there is a .mount unit (that it may have synthesized from /etc/fstab)
for this path. Eg:
snapd is not installed, systemd will:
* check if /var/lib/snapd/apparmor/profiles .mount entry exists. no, so do
nothing
* check if /var/lib/snapd/apparmor .mount entry exists. no, so do nothing
* check if /var/lib/snapd .mount entry exists. no, so do nothing
* check if /var/lib .mount entry exists. no, so do nothing
* check if /var .mount entry exists. no, so do nothing
* check if / .mount entry exists. yes, so add this (will be satisfied by
local-fs.target)
snapd is installed with no zfs-on-root, systemd will:
* check if /var/lib/snapd/apparmor/profiles .mount entry exists. no, so do
nothing
* check if /var/lib/snapd/apparmor .mount entry exists. no, so do nothing
* check if /var/lib/snapd .mount entry exists. no, so do nothing
* check if /var/lib .mount entry exists. no, so do nothing
* check if /var .mount entry exists. no, so do nothing
* check if / .mount entry exists. yes, so add this (will be satisfied by
local-fs.target)
snapd is installed with zfs-on-root, systemd will:
* check if /var/lib/snapd/apparmor/profiles .mount entry exists. no, so do
nothing
* check if /var/lib/snapd/apparmor .mount entry exists. no, so do nothing
* check if /var/lib/snapd .mount entry exists. no, so do nothing
* check if /var/lib .mount entry exists. yes, so add this
* check if /var .mount entry exists. no, so do nothing
* check if / .mount entry exists. yes, so add this (will be satisfied by
local-fs.target)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor 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
snap 2.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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
