Taming Services and Startup Applications on elementary OS
elementary OS greets most users with a calm, uncluttered desktop — no notification flood, no spinning fans, no dozen icons competing in the dock. That quietness is engineered. Beneath Pantheon lies systemd, the same service manager that runs Ubuntu and most modern Linux distributions, plus a small collection of autostart hooks that quietly load your favourite tools when you log in. Learning to manage both layers gives you real control over how your machine behaves from the first press of the power button.
For anyone stepping over from Windows — and that includes plenty of Brisbane folks who migrated over the humid summer to escape bloatware-heavy laptops — the concept of a "service" can feel obscure. A service is a long-running background process managed by the operating system, started automatically at boot, and invisible until something goes wrong. Networking, Bluetooth pairing, printing, your screen brightness keys — every one depends on a service humming along. Knowing which ones run, which you actually need, and how to turn off the rest is the foundation of a snappier elementary OS install.
Startup applications are a slightly different beast. These are programs tied to your user session rather than the system itself, and they fire whenever you sign in. Some, like the wallpaper daemon or your cloud storage client, are useful every day. Others — old chat clients, a forgotten sync tool — quietly steal memory and CPU cycles on every reboot. Australians who split time between Melbourne's café culture and a home office know the value of a fast login, especially when tethering through a Telstra NBN connection that drops out at the worst possible moment.
This article walks through the practical toolkit for managing both system services and per-user startup programs on elementary OS. You will see how to inspect what is running, stop and disable what you do not need, add your own autostart entries, and roll things back when an experiment goes wrong. Nothing requires compiling from source, and most of it works on any supported release.
How systemd organises everything on elementary OS
elementary OS is built on Ubuntu, so it inherits systemd as the init system. When your machine finishes POST, systemd walks through a stack of target units — milestones that other units depend on. The graphical target only starts after networking, Bluetooth, and a handful of display services have reported success. Each service is described by a unit file under /lib/systemd/system (for packages you install) or /etc/systemd/system (for local overrides), carrying metadata about dependencies, restart behaviour, and the user it runs as.
To see what is currently running, open the Terminal from the dock or press Super + T, then type systemctl list-units --type=service --state=running. The columns are unit name, load time, current state, and a short description. Look for entries matching hardware and software you actually use. If you never print, the cups service is just sitting there. If your laptop has no fingerprint reader, fprintd consumes memory for nothing.
You can also list everything systemd would try to start at boot. systemctl list-unit-files --type=service --state=enabled shows the boot-time picture, with flags telling you whether each unit is enabled, disabled, or masked. This is the right command when auditing what runs by default, and a handful of entries usually stand out as candidates for review.
Turning off services you do not actually need
Disabling a service is easy; doing it safely takes a little care. systemctl disable servicename stops a unit from auto-starting at boot but leaves the running instance alone. systemctl stop servicename handles the immediate shutdown. Most people combine them into systemctl disable --now servicename, which does both at once. Common candidates include cups if you never print, bluetooth on machines without that radio, or avahi-daemon if you do not rely on network discovery.
Before pulling the trigger, check what depends on the service. systemctl list-dependencies servicename --reverse lists units that want it alive, so anything important surfaces immediately. The reverse tree is also useful when a service keeps restarting — a higher-level target may demand it even after you disabled the leaf, and the fix is to mask the upstream target.
Masking goes a step further than disabling. A masked unit cannot be started manually, accidentally, or by another service; it links the unit file to /dev/null, which makes launching it effectively impossible. This is overkill for most situations and risks leaving your system half-broken if you forget what you did. Reserve masking for daemons that keep respawning and causing trouble. A simple disable is almost always the right starting point.
Handling user-level autostart on login
Beyond systemd, elementary OS uses a lightweight mechanism for applications that should start when you sign in. The XDG Autostart specification defines a directory called .config/autostart inside your home folder, and any .desktop file placed there is launched at login by the Pantheon session. Many apps copy a .desktop file in automatically the first time they run, which is why your login starts to feel slower over the months you use a fresh install.
The graphical way to manage these entries is through System Settings, the cog icon in the wingpanel. Open it and look under the Applications tab; older releases call it Startup Applications. From there you can uncheck entries to stop them launching at login, add new ones, or simply hide items you do not want to think about. If a checkbox is greyed out, the .desktop file probably lives in /etc/xdg/autostart instead, meaning it was installed system-wide and needs root privileges to remove.
For terminal-oriented users, .config/autostart is straightforward to manage. Copy an existing .desktop file from /usr/share/applications or /etc/xdg/autostart into the local folder, then edit its Exec= line. Prefix it with sleep 5 if you want staggered startup, or set Hidden=true to keep the file on disk but skip the launch. This is the cleanest way to keep customisations portable between machines — when you reinstall or switch laptops, copy the directory across and your login-time tools come with you.
Working with the Pantheon Settings interface
Not everyone wants to live in the terminal. The wingpanel's System Settings panel covers startup applications, default apps for web browsing and email, notifications, and accessibility toggles that affect how the session starts. You will also find the Session Manager under the same panel, which lets you configure when notifications appear and how long they linger — indirectly influencing how much background work the desktop performs.
When experimenting with startup apps, the GUI has one quirk worth knowing. Toggling an entry in System Settings rewrites the .desktop file in .config/autostart with a Hidden=true or Hidden=false line. If you later edit that file by hand, the GUI reads your manual change and respects it on the next save. That round-trip behaviour can confuse newcomers who edit the file and assume their change was ignored — usually the issue is a typo in the Exec= line.
If you are hunting for an app to add to your autostart list and nothing obvious shows up in the system menus, the curated application guide on elementarynow is a sensible starting point. It collects well-behaved utilities tested on elementary OS specifically, saving you from trialling alternatives before finding one that fits the Pantheon aesthetic. Many ship with their own .desktop files, so a single drag-and-drop into your autostart folder makes them part of your login routine.
Building your own systemd user services
Systemd is not just for system-wide processes. It also manages a per-user instance that runs as soon as you log in and stays alive until you log out. This is where background tools that should follow your desktop session — syncing daemons, RSS readers, status bar widgets — belong. Unit files live under .config/systemd/user and follow the same syntax as their system counterparts. Write one, run systemctl --user daemon-reload, then enable and start it the same way you would a system service.
A simple user unit might launch a personal backup script every five minutes. The [Unit] section describes what it is, the [Service] section tells systemd the command and working directory, and the [Install] section names the target. Once enabled with systemctl --user enable mytool.service, it survives reboots because the user instance is wired into graphical.target by default. To remove it, disable and stop it the same way and delete the unit file.
The user service manager is also the right place for tray icons and background tools that complain when started too early. Because the user instance only starts after the session has settled, you avoid the race condition where a daemon tries to open a file or socket that does not yet exist. For tools that need network access, add After=network-online.target to ensure your broadband link has finished negotiating — particularly relevant on the more congested parts of the NBN where link negotiation can take a few extra seconds.
Spotting the impact and measuring improvements
It is one thing to disable a service or trim your autostart list; another to know whether any of it actually mattered. The classic tool for a quick before-and-after comparison is systemd-analyze, which reports how long boot took and which services contributed the most delay. systemd-analyze blame ranks every unit by start-up time in descending order, so worst offenders appear at the top. If a single service takes two seconds longer than everything else, you have just found a meaningful optimisation target.
You can also dig into resource usage. top and htop give a live view of CPU and memory consumption, while systemd-cgtop shows usage grouped by control group. Running these before and after your changes gives you a concrete number to point at, which matters when explaining to a partner why their laptop fan no longer sounds like a jet engine on take-off. In Perth, where summer afternoons regularly push temperatures past forty degrees, a cooler-running laptop is more than a quality-of-life improvement.
For startup applications, the easiest way to feel the difference is to enable bootchart or systemd-analyze plot, which generates a graphical timeline of the boot sequence. Even without charts, systemd-analyze critical-chain traces the longest dependency chain from the start target to the graphical target, helping you understand whether login speed is limited by a particular service or by the cumulative weight of many small ones. With that in hand, you can prioritise which tweaks will pay off most.
Restoring defaults when something goes wrong
Every system administrator has at some point disabled a service they later realised was essential. The fix is usually a single command away. systemctl enable --now servicename brings a previously disabled unit back into the boot sequence and starts it immediately. If you masked the service, unmask it first with systemctl unmask servicename, then re-enable and start it. Both commands are reversible and leave no permanent trace, so you can experiment freely as long as you remember the names of the units you touched.
For startup applications, the safety net is even simpler. If a hand-edited .desktop file prevents your session from launching cleanly, log into a TTY with Ctrl + Alt + F2, sign in, and rename the offending file from .config/autostart to broken.desktop. The session manager skips it on the next login, and you can fix the file at your leisure from the same text console. This is faster than reaching for a live USB and works reliably on every supported release.
The next step is yours: open a terminal, run systemctl list-unit-files --type=service --state=enabled, and make a short list of three services you suspect you do not need — then disable them one at a time, rebooting after each change to confirm nothing important has broken. Within an hour you will know exactly what your machine is doing at boot, and your login screen will feel noticeably faster on the very next restart.
