systemd unit files carry suffixes such as .service, .socket, .timer, .mount, .path, .slice and .scope. What does that suffix determine, and what kind of object does each of those unit types manage?
answer
- the suffix is not decoration
- each type manages a different object
- some are written, some are generated
- cgroup branches versus adopted processes
- only [Unit] and [Install] are generic
basics
~20 sThe suffix is the unit type: .service supervises a process, .socket owns a listening socket, .timer carries a schedule, .mount a mount point, .path watches files, .slice groups processes for resource control, and .scope adopts processes started outside systemd.
solid answer
~50 sThe suffix is not decoration — it selects the unit type, which decides what systemd manages and which type-specific section the file may contain. A `.service` supervises a process and uses `[Service]`. A `.socket` owns a listening socket. A `.timer` carries a schedule. A `.mount` describes a mount point, and `.automount` mounts it on first access. A `.swap` manages a swap device. A `.path` watches filesystem paths and activates another unit when they change. A `.device` mirrors a device that udev has exposed. A `.target` is a synchronisation and grouping point with no process of its own. A `.slice` is a branch of the cgroup tree where resource limits are applied, and a `.scope` is a cgroup for processes systemd did not fork itself, such as a login session. Only `[Unit]` and `[Install]` are generic across all of them.
code
bash · 2 linessystemctl list-units --type=service,socket,timer,mount,path,slice,scope --all
systemd-escape -p /var/loggo deeper
Be able to name the common suffixes and say in one line what each manages, and recognise that the suffix, not the contents, decides the unit type.
Explain which sections each type allows, that mount unit names are escaped paths, and which units are generated rather than authored — fstab-derived mounts, udev-derived devices, runtime scopes.
Show the modelling judgement: choosing a timer-activated service over cron, a socket-activated service for a rarely used daemon, or a dedicated slice so limits apply to a group of jobs rather than one process.
Own the convention across a fleet: which workloads are modelled as units at all versus handed to an orchestrator, and how a slice hierarchy is laid out so resource policy is expressed once instead of copied into every unit.
## The suffix is the type systemd does not manage "services"; it manages *units*, and the file name's suffix says which kind. That choice determines three things: what real object the unit stands for, which type-specific configuration section the file may contain (`[Service]`, `[Socket]`, `[Timer]`, `[Mount]`, `[Path]`, `[Slice]`, and so on), and how the unit comes into being — some types you author on disk, others systemd creates for you. Two sections are generic to every type: `[Unit]`, which carries the description and the relationships to other units, and `[Install]`, which is read only when the unit is enabled or disabled. ## The types you write by hand **`.service`** — the common case. It supervises one or more processes. The `[Service]` section says how to launch them and under what identity. **`.socket`** — systemd owns the listening socket itself and hands it to a service. Because the socket exists before the service does, connections are accepted from the moment boot reaches that point. **`.timer`** — a schedule that activates another unit, taking the place a cron entry would occupy. **`.path`** — watches one or more filesystem paths and activates another unit when a watched path appears or changes; it is built on inotify. **`.mount`** — a mount point. The unit name is the mount path with `/` replaced by `-` and escaped, so `/var/log` becomes `var-log.mount`; `systemd-escape -p /var/log` performs that translation for you. `.automount` creates a kernel autofs point at the same location and only activates the matching `.mount` when something touches the path. **`.target`** — a unit with no process at all. It exists purely as something other units can attach themselves to and as a name you can reach for, which is what makes it the grouping mechanism the boot process is built out of. **`.slice`** — a node in the cgroup hierarchy. Slices form a tree (`-.slice` at the root, then `system.slice`, `user.slice`, `machine.slice`), and units are placed into one so that resource controls apply to a whole group. On a current distribution this maps onto cgroup v2's unified hierarchy. ## The types systemd creates for you **`.device`** — for each device udev has tagged for systemd, a device unit appears automatically. You do not usually author these files, though a drop-in can attach settings to one. They let a unit be ordered after a piece of hardware actually showing up. **`.swap`** — one per active swap device or file; typically generated from `/etc/fstab` rather than hand-written, exactly as mount units usually are. **`.scope`** — a cgroup for processes systemd did **not** fork. When you log in, `systemd-logind` registers your session's processes as something like `session-3.scope`; a container runtime registers a container's processes the same way. A scope has no `ExecStart=`, because the processes already exist; it exists so that they can still be grouped, limited, and killed as a unit. That last distinction is the one candidates most often miss: a service is *started by* systemd, a scope is *adopted by* systemd, and both end up as cgroups underneath a slice. ## Generated units A third category is neither hand-written nor kernel-driven: generators. `systemd-fstab-generator` reads `/etc/fstab` at every boot and writes `.mount` and `.swap` units into a runtime directory; other generators translate legacy init scripts or kernel command-line options. This is why `systemctl list-units --type=mount` on a normal host shows many mount units nobody wrote. ``` systemctl list-units --type=mount systemctl list-unit-files --type=timer systemctl status session-3.scope ``` ## Why an interviewer cares Knowing the type list is only half the point. The other half is modelling: a periodic job can be a service triggered by a timer instead of a cron entry; a rarely used daemon can be a service fronted by a socket so it starts on first connection; a noisy batch job can be placed in its own slice so its resource limits are enforced against a group rather than a single process. Someone who knows only `.service` will reach for a shell loop or a cron entry where the platform already has an object for it.
- Which unit types do you generally not write by hand, and where do those units come from?`.device` units appear automatically for devices udev has tagged for systemd. `.scope` units are created at runtime when something registers already-running processes — a login session via systemd-logind, or a container runtime. `.mount` and `.swap` units are usually produced by systemd-fstab-generator from /etc/fstab at each boot. You author `.service`, `.socket`, `.timer`, `.path`, `.target` and `.slice`.
- What is the difference between a .mount unit and an .automount unit?A `.mount` unit describes the mount itself — the device, the mount point, the filesystem type and options — and activating it performs the mount. An `.automount` unit installs a kernel autofs point at the same path and activates the matching `.mount` only when a process first touches it. That defers a slow or unreliable mount, such as a network filesystem, until something actually needs it.
- Why does a .scope unit have no ExecStart=?Because the processes already exist. A scope is registered for processes systemd did not fork — a login session, a container's payload — so there is nothing to launch. It exists to place those processes in a cgroup so they can be grouped, resource-limited and terminated together, which is the same machinery a service gets after systemd has forked it.
saying these in an interview costs you the question
- The suffix is only a naming convention, systemd ignores it
- Everything systemd manages is a service unit
- You have to write a .device unit for every disk
- A .slice unit starts a process of its own
- A .scope is just another word for a .service