Disable unnecessary services

Every active service uses memory, sometimes opens a port and adds attack surface. On a freshly installed VPS, several daemons are useless. Disabling them frees resources, but a mistake on SSH, networking or DNS resolution can cut your access. Inventory and verification matter more than speed.

Take inventory

systemctl list-units --type=service --state=running
systemctl list-unit-files --state=enabled
systemctl --failed
sudo ss -tulpn

The first command shows what runs now, the second what will start at boot. The lists differ: a service can be enabled but not running, or started manually without being enabled.

To understand a unit before touching it:

systemctl status name.service
systemctl cat name.service
systemctl list-dependencies --reverse name.service

list-dependencies --reverse shows what depends on the service. systemctl list-sockets reveals services started on demand by a socket, such as ssh.socket.

Decide what to disable

On a VPS, Bluetooth, printer and modem services are usually unnecessary. However, never disable a service you do not recognise without reading its description and dependencies. dbus and journald are structural: stopping them breaks part of the system.

Disable and mask

sudo systemctl disable --now name.service

--now stops the service immediately in addition to disabling it at boot. To prevent any start, even as a dependency:

sudo systemctl mask name.service
sudo systemctl unmask name.service

mask creates a link to /dev/null: it is stronger than disable. For a socket-activated service, disable the socket too:

sudo systemctl disable --now ssh.socket

Only do this if you know how SSH is started on your system.

Package updates can re-enable a service. Keep your changes in a text file and check after each major update.

Verify

systemctl is-enabled name.service
systemctl is-active name.service
systemctl --failed

is-enabled must answer disabled or masked, is-active must answer inactive. Reboot the VPS and take inventory again: that is the only test proving a service does not come back at boot. Then confirm SSH, networking and your application still work.

Best practices

• Keep an SSH session and the noVNC console open during the operation.
• Disable one service at a time, then test.
• Do not disable apt-daily or unattended-upgrades without deciding how security updates will be applied.
• Prefer disable over removing the package: reverting is easier.

free -h
systemctl list-units --type=service --state=running

Compare available memory before and after. A small gain does not justify risking a service whose role is unclear: when in doubt, leave it enabled.