In Ubuntu Server environments utilizing the Snap package manager, the snapd.seeded.service is a specific systemd unit that runs early in the boot process. Its sole purpose is to ensure that the initial set of “seeded” snaps (the core snaps included by default in the Ubuntu installation image) are properly initialized and available before the system fully boots. However, in heavily optimized, minimal, or strictly controlled server deployments where the administrator has explicitly removed all Snap packages and the snapd daemon entirely (often to rely exclusively on APT for dependency management), this lingering service can cause boot delays or unnecessary log warnings as it attempts to execute its seeding routine in a vacuum.
This guide explains how to completely disable the snapd.seeded.service daemon in Ubuntu Server, ensuring a cleaner boot process on systems where Snap has been purged.
Stop and Mask the snapd.seeded Daemon
If you have already removed the snapd package, this service may still be present as an orphaned unit. We must explicitly mask it to prevent systemd from ever attempting to run it.
- Log into your Ubuntu Server via SSH using an account with
sudoprivileges. - First, ensure the service is not currently running (though it typically only runs at boot):
sudo systemctl stop snapd.seeded.service - Next, disable the service to prevent it from hooking into the boot sequence:
sudo systemctl disable snapd.seeded.service - Finally, to guarantee that systemd completely ignores the unit and prevents any other dependent service from triggering it, mask it entirely:
sudo systemctl mask snapd.seeded.service
Verify the Service Lockdown
By masking the service, you have instructed systemd to symlink the unit file to /dev/null. The systemd manager will immediately reject any attempt to start it.
To verify the lockdown is successful, run the following command to check the status of the service:
systemctl status snapd.seeded.serviceThe output will clearly state that the service is masked. If you reboot the server and check the systemd boot analysis (systemd-analyze blame), you will confirm that snapd.seeded.service is no longer consuming any boot time or appearing in the execution chain. You have successfully cleaned up this lingering Snap dependency.