In this lesson, you will learn how to create a custom systemd target to group together a specific set of maintenance or recovery services that you can trigger on demand.
The Concept of a Custom Target
While targets like multi-user.target or graphical.target represent standard operating states, you are not limited to them. You can define your own "virtual" milestones. A custom target acts as a synchronization point; by grouping services under one, you can start, stop, or isolate a specific set of maintenance tasks with a single command.
Building Your Maintenance Target
To create a custom target, you must define a unit file ending in .target. Let’s create one called maintenance.target.
- Create the Unit File:
Create the file
/etc/systemd/system/maintenance.target. It requires very little configuration:
[Unit]
Description=Custom Maintenance Mode
AllowIsolate=yes
The AllowIsolate=yes setting is crucial; it permits you to switch to this target exclusively, stopping all other services not required by it.
- Associate Services: Now, you need to tell your maintenance services to join this target. If you have a backup script service, modify its unit file to include:
[Install]
WantedBy=maintenance.target
- Triggering the Target: Once your services are linked to the target, you can initiate the maintenance state manually:
sudo systemctl isolate maintenance.target
Why Do This?
By creating a maintenance.target, you turn a scattered collection of "cleanup" or "recovery" tasks into a first-class system state. Instead of starting five different scripts individually, you isolate the system into a state where only the necessary maintenance utilities are running. This ensures that you don't accidentally leave a resource-heavy production service running while performing critical database repairs or disk snapshots. It turns complex orchestration into a simple state transition, keeping your system architecture clean and predictable.
Key Takeaway: A custom target allows you to group related services into a unique system state that can be activated atomically using systemctl isolate.