In Ubuntu Server environments, snapd.apparmor.service is a critical systemd unit that acts as the bridge between the Snap package manager daemon (snapd) and the Linux kernel’s AppArmor security module. Its primary function is to compile and load the strict MAC (Mandatory Access Control) AppArmor profiles required to sandbox and isolate individual Snap applications. However, in heavily customized, minimal server deployments where the administrator has explicitly decided to purge the Snap ecosystem entirely in favor of traditional APT packages or Docker containers, this specific service often remains as a lingering, orphaned dependency. Attempting to start it on a system without Snap installed can lead to unnecessary boot delays and systemd journal errors.
This guide explains how to completely disable the snapd.apparmor.service in Ubuntu Server, ensuring a cleaner boot process on systems where Snap has been explicitly removed.
Stop and Mask the snapd.apparmor Service
If you have already removed the snapd package, this service may still attempt to execute during the boot sequence as systemd processes its cached dependency tree. We must explicitly mask the unit to prevent it from ever running.
- Log into your Ubuntu Server via SSH using an account with
sudoprivileges. - First, ensure the service is not currently running:
sudo systemctl stop snapd.apparmor.service - Next, disable the service to prevent it from hooking into the default boot sequence:
sudo systemctl disable snapd.apparmor.service - Finally, to guarantee that systemd completely ignores the unit and prevents any other dependent service from accidentally triggering it, mask it entirely:
sudo systemctl mask snapd.apparmor.service
Verify the Service Lockdown
By masking the service, you have instructed systemd to symlink the unit file to /dev/null, effectively neutralizing it. Systemd will immediately reject any manual or automated attempt to start the process.
To verify the lockdown is successful, run the following command to check the status of the service:
systemctl status snapd.apparmor.serviceThe output will clearly state that the service is masked. If you reboot the server and analyze the boot sequence using systemd-analyze blame, you will confirm that snapd.apparmor.service is no longer present, ensuring it consumes zero boot time and generates zero journal errors on your Snap-free server.