A systemd timer separates the scheduling rule from the service that performs the work. The timer decides when to request activation; the service supplies the command, execution identity, environment, timeout, and result. This separation makes a maintenance job inspectable using normal unit tools. It does not turn a scheduled attempt into proof that a backup, cleanup, or report completed correctly. ...
A service package often needs a dedicated account before it can own files or run without root. systemd-sysusers describes that account and its groups in a small configuration file. Its central operation is creating missing identities and establishing requested memberships. It is not a general account migration engine, a directory creator, or a guarantee that automatically allocated numeric IDs match on every host. ...
Linger changes when an account’s systemd user manager is kept available. With lingering enabled, logind can start that manager at boot and retain it after the account’s login sessions end. This supports unattended work owned by a normal account. The flag controls manager lifetime; individual services still have their own activation, failure, shutdown, and installation rules. ...
systemd-timesyncd is a minimal SNTP client for synchronizing the local system clock against configured time sources. It can help keep certificate checks and wall-clock timestamps meaningful, but it does not provide an unconditional accuracy guarantee. Whether the daemon can run, whether it receives acceptable samples, and whether the system reports synchronization are separate facts to establish. ...
An environment file separates deployment values from the unit definition that describes process supervision. systemd reads the configured file before executing a service command and supplies those values in that process’s environment. Editing the file does not rewrite the environment of an already running process. A reload helper is another process, however, and can receive newer file values than the service’s existing main process. ...
A systemd user manager runs services on behalf of one account. Multiple login sessions for that account normally share the same manager, rather than each shell receiving a private service universe. User unit files can live under ~/.config/systemd/user, and systemctl --user addresses the user’s manager. This provides lifecycle management with the account’s authority, not automatic isolation from every shared system resource. ...
A read-only root filesystem prevents ordinary writes to the filesystem layer containing a service’s packaged code and configuration. Explicit mounts can still provide writable locations for runtime data. This reduces accidental modification and some persistence opportunities, but its boundary is filesystem mutation. It does not by itself remove process privileges, prevent reading available data, or block communication with other services. ...
A schedule must specify what time means. “At nine each morning in New York” refers to a civil-time calendar. “A quarter hour after this job finishes” refers to an elapsed interval and an event. systemd timers support both, but the two clocks and reference points have different behavior around time-zone changes, suspension, and periods when the timer is inactive. ...