Since `needrestart` 3.4 (2019-02, Debian #898818) removed its
`systemd-journald`
exclusion, a glibc security upgrade makes `needrestart` restart
`cron.service` and
`systemd-journald.service` **in the same `systemctl restart` transaction**.
Units
without ordering dependencies are scheduled in parallel, so cron is
sometimes started
shortly before journald is torn down.
Per `systemd-journald.service(8)`, tearing down journald terminates the
stdout/stderr
stream connections of other services, and writes to them then raise `EPIPE`
and
deliver `SIGPIPE`. systemd turns SIGPIPE off for services by default, but
`cron.service` explicitly opts out via `IgnoreSIGPIPE=false` (Debian
#756047), so cron
is one of the very few services that can actually be killed this way.
`systemd.service(5)` defines termination by SIGPIPE as a *clean exit*.
Therefore the
existing `Restart=on-failure` does **not** fire for what is arguably cron's
most likely
cause of death. cron stays dead indefinitely, and the only trace is
`cron.service: Deactivated successfully.`, which reads as a deliberate stop.
### Observed impact
On a production host, cron died this way and stayed dead for 52 hours. All
cron jobs
silently stopped. Nothing in the logs suggested a fault.
```
$ systemctl status cron
Active: inactive (dead) since Sat 2026-09-12 06:56:21 CST
Duration: 26ms
Process: 692120 ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS
(code=killed, signal=PIPE)
$ systemctl show cron
Restart=on-failure IgnoreSIGPIPE=no SuccessExitStatus=
Result=success NRestarts=0
```
Note `Result=success` and `NRestarts=0`: systemd recorded the SIGPIPE death
as a
successful exit, so the restart policy never engaged.
### Timeline (journalctl -o short-precise, verbatim)
```
06:56:21.426212 systemd[1]: Stopping cron.service...
06:56:21.436137 systemd[1]: Started cron.service
06:56:21.447148 systemd[1]: Stopping systemd-journald.service...
06:56:21.447565 systemd-journald[4011866]: Journal stopped
06:56:21.551893 systemd[1]: cron.service: Deactivated successfully.
06:56:21.553009 systemd-journald[692139]: Journal started
```
There are **no `cron[...]` log lines at all** for the start at `.436137`. A
healthy
cron start writes `(CRON) INFO (pidfile fd = 3)` within 1–3 ms. It never
got that far.
### Why it is a race, not a certainty
The same host survived this six other times. The discriminator is whether
cron manages
its first stdout write before journald goes away:
| date | cron's first log write | journald teardown | outcome |
|---|---|---|---|
| 07-25 | +0.928 ms | +2.987 ms | survived |
| 07-29 | +2.192 ms | +18.246 ms | survived |
| 09-12 | never happened | +11.428 ms | **killed** |
The `needrestart` command that triggered it:
```
systemctl restart chrony.service cron.service multipathd.service
polkit.service
rsyslog.service ssh.service systemd-journald.service
systemd-networkd.service
systemd-resolved.service systemd-udevd.service tuned.service
udisks2.service
```
### Suggested fix
```ini
[Service]
RestartForceExitStatus=SIGPIPE
```
`RestartForceExitStatus=` accepts termination signal names. This forces a
restart only
for SIGPIPE and changes the behaviour of no other exit path, leaving
`Restart=on-failure`, `IgnoreSIGPIPE=false` and `KillMode=process`
untouched.
### Not Ubuntu-specific
The defect is in the Debian packaging; Ubuntu carries no delta for it.
Verified
against sources.debian.org:
```
version suite Restart IgnoreSIGPIPE
RestartForceExitStatus
3.0pl1-209 forky (testing), sid on-failure false absent
3.0pl1-197 trixie (stable) on-failure false absent
```
Both current stable and unstable are affected.
Ubuntu does carry one unrelated delta: `ExecStart` is
`/usr/sbin/cron -f -P $EXTRA_OPTS`, one `-P` more than Debian's. The
`systemctl show`
output quoted above is therefore from an Ubuntu host; the three directives
at issue
are identical in Debian.
### Related
Debian #1100685 / needrestart #340 describes a different failure path with
the same
set of components: repeated restarts across unattended-upgrades' minimal
steps
exhausting `StartLimitBurst`, after which systemd stops the unit without
starting it
(that report killed sshd, and notes "it still may kill `cron` that way").
This bug is a separate mechanism: a single SIGPIPE, `Result=success`,
`NRestarts=0`.
### Environment
Observed on Ubuntu; the Debian unit files were verified separately (see
above).
- Ubuntu 24.04.3 LTS, systemd 255.4-1ubuntu8.17
- cron 3.0pl1-184ubuntu2
- needrestart 3.6-7ubuntu4.5 (config unmodified; `dpkg --verify` clean)
- Alibaba Cloud ECS, 2 vCPU, KVM
---
Best regards,
Qiangning Hong