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