A maintenance script that will run as a systemd service currently opens /var/log/maintenance.log itself, writes its own timestamps and truncates the file when it grows too large. What should a script run under systemd do with its output instead, and how does it mark one line as an error?

## The contract A process supervised by systemd is not expected to manage logging. Its standard output and standard error are connected to the journal by default, and every line written there becomes a journal entry. systemd attaches the metadata: the wall-clock and monotonic timestamps, the unit name, the PID, the UID, the boot ID, and more. A script that opens its own file and prefixes each line with a date is re-implementing all of that badly, and it is doing so in a place where the operator's tools cannot see it. The self-rotation is worse than redundant. Truncating a file the process still holds open is a classic way to lose data or leave a sparse file, and the journal already bounds its own disk usage without any help. So the script's logging layer collapses to `echo` and `printf`. ## Severity: the part that is not automatic The common assumption is that stdout means informational and stderr means error. systemd does not work that way — both streams are recorded at the same default priority, informational unless the unit says otherwise. A stack trace on stderr and a progress line on stdout land in the journal looking equally routine, which is why filtering by priority turns up nothing useful for scripts that never set one. The mechanism to set it is a log-level prefix: begin a line with a syslog priority in angle brackets and systemd strips it off and records that priority on the entry. The numbers are the syslog levels — `<0>` emergency through `<7>` debug — with the useful ones being `<3>` error, `<4>` warning and `<6>` info. This is enabled by default and controlled by the unit's `SyslogLevelPrefix=` setting, so a script can rely on it but should tolerate running outside systemd, where the prefix is just visible text. A small helper keeps the call sites clean: ```bash log_info() { printf '<6>%s\n' "$*"; } log_warn() { printf '<4>%s\n' "$*"; } log_error() { printf '<3>%s\n' "$*" >&2; } ``` The alternative, for one-off lines or for a script that also runs by hand, is to pipe through `systemd-cat`, which takes `-t` for a tag and `-p` for a priority and forwards what it reads into the journal. ## Line discipline Each line is one entry. That has two consequences worth designing around. Multi-line output fragments: a ten-line error report becomes ten entries, only the first of which carries your `<3>` prefix, and they can be interleaved with other output. Prefer one self-contained line per event, carrying the context that a reader needs, over a pretty multi-line block. If the payload is genuinely large — a diff, a failing command's full output — write it to a file and log the path. And because the destination is a pipe rather than a terminal, decoration aimed at humans is noise. Guard colour output on the stream actually being a terminal: ```bash if [[ -t 1 ]]; then red=$'\e[31m'; reset=$'\e[0m'; else red=; reset=; fi ``` Without that guard, escape sequences end up embedded in journal entries. ## Buffering The script's own `echo` writes are unbuffered, but the programs it calls are usually not. Many programs choose line buffering when stdout is a terminal and much larger block buffering when it is a pipe — which is exactly the situation under systemd. The visible effect is a long-running child whose output appears in the journal in bursts, or not at all if the process is killed before it flushes. When you need timely output from such a child, run it under `stdbuf -oL` to request line buffering, and be aware that this only works for programs that use the standard C library's default buffering rather than managing their own. ## When a file is genuinely required Sometimes an auditor or an existing shipper needs a plain file. That is a deployment decision expressed in the unit, not something the script should do to itself: the script keeps writing to stdout, and the unit directs that stream where the operator wants it. Keeping the script on the plain-stdout contract is what lets the same script run unchanged from a terminal, from a container, and from a service.