Operations and Deployment
Services, targets, and package state
systemd manages services and boot state. Know the difference between a unit being active now and enabled at boot: systemctl start runs it, systemctl enable creates the boot-time links, and systemctl enable --now does both. systemctl status and journalctl -u name -b are your first diagnostic pair. Targets group units; multi-user.target and graphical.target are common defaults. Use systemctl get-default, set-default, and isolate carefully because isolation changes the running set of units. After editing a unit file, run systemctl daemon-reload before restarting the service. Masking a unit is stronger than disabling: it prevents both manual and dependency starts.
Package work belongs here too. Know your distribution's tool: apt with update refreshing metadata and upgrade installing updates, or dnf/yum with check-update, update, and install. Scheduled operations use cron or systemd timers; timers need both a .timer and usually a .service unit.
Traps are common: is-active is not is-enabled; disabling a service does not stop it; daemon-reload is required after unit edits; and a failed unit may be masked or blocked by a dependency. Do not assume a package is installed because a command exists on your practice host.
Worked rule of thumb: deploy a custom service by placing foo.service in /etc/systemd/system/, running systemctl daemon-reload, then systemctl enable --now foo, and confirming with systemctl status foo plus journalctl -u foo -b. If it fails at boot but works manually, inspect dependencies, paths, and the unit's After=/Wants= relationships.