Code change:
Apparmour service doesn't reload correctly after a system switch. Steps to reproduce the behavior: anything in config with apparmor enabled nixos-rebuild switch error of apparmor service failing to restart No error, apparmor starting as it should Here my service log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm encountering the exact same error here.
Same issue here
Same for the issues after . However do a after that just fine.
Someone once told me that the state of AA in NixOS wasn't great. But I don't know first hand. Could be wrong. I lack any knowledge at all to even figure out the root cause of the issue. :/
AA seems to work fine in general. Just the service restart after a nixos-rebuild doesn't work.
Tested just now on nixos-23.11. AppArmor service restarts without any issues after nixos-rebuild. I think this issue is resolved.
Reopening this issue as unresolved. Currently on 24.05.. and this issue seems to be persisting after a nixos-rebuild: reloading the following units: apparmor.service, dbus.service Job for apparmor.service failed. See "systemctl status apparmor.service" and "journalctl -xeu apparmor.service" for details.
I did some more investigation on this. I have one system with a custom apparmor profile and another system with no profiles. On the system I have with a custom apparmor profile, nixos-rebuild works fine. On the other system without any apparmor profiles, nixos-rebuild fails with the message in this bug report. After nixos-rebuild, journalctl reports: In I tried running "sudo aa-remove-unknown" from zsh: The error message matches what is in the system log. I think this may be related to the aa-remove-unknown step.
As a workaround, adding this to appears to work: After this, the first nixos-rebuild switch will still cause the issue (because the profile is not installed yet). But on the second and subsequent nixos-rebuilds, there is no error message on my system. Can someone else try it and see if it works on their system too? If so, it may help to figure out the proper solution.
I tried it and it actually rebuilds without error the first time too. Hopefully that helps you or someone else figure out a permanent fix! Many thanks.
From my side the issue seems to be be fixed with the merged fixes. So I will close the issue.
If anyone wants to track the merger of the fix :

Related discussion:
text: <ins> commit 166afaf144d6473464975438353257359dd51708 Author: Andreas Wiese <andreas.wiese@kernkonzept.com> Date:   Thu Feb 1 11:35:02 2024 +0100 aa-remove-unknown: fix readability check This check is intended for ensuring that the profiles file can actually be opened.  The *actual* check is performed by the shell, not the read utility, which won't even be executed if the input redirection (and hence the test) fails. If the test succeeds, though, using `read` here might actually jeopardize the test result if there are no profiles loaded and the file is empty. This commit fixes that case by simply using `true` instead of `read`. diff --git a/utils/aa-remove-unknown b/utils/aa-remove-unknown index 0e00d6a0..3351feef 100755 --- a/utils/aa-remove-unknown +++ b/utils/aa-remove-unknown @@ -63,7 +63,7 @@ fi # We have to do this check because error checking awk's getline() below is # tricky and, as is, results in an infinite loop when apparmorfs returns an # error from open(). -if ! IFS= read -r _ < "$PROFILES" ; then +if ! true < "$PROFILES" ; then echo "ERROR: Unable to read apparmorfs profiles file" 1>&2 exit 1 elif [ ! -w "$REMOVE" ] ; then </ins>