systemd Restart=on-failure write deduplication on CentOS

Answer

No. systemd has no unit-file directive or environment variable that tells ExecStart it is starting after a failure. Restart=on-failure only controls whether systemd spawns the process again; it does not record whether writes completed before termination, nor can it suppress duplicate writes on restart. Deduplication must live in the application or an external state layer. The core restart behavior is the same on CentOS 7 with systemd 219 and CentOS Stream 9 with systemd 252, but restart throttling differs between those releases.

Confirmed facts vs. likely explanation

Confirmed: systemd restarts the unit based on exit code and Restart= policy. The restarted process receives no intrinsic restart-cause marker. Unit files cannot inspect prior write completion.

Likely explanation: If your service performs non-idempotent writes, such as appending to a file or incrementing a counter, a crash after the write but before a clean stop can cause that write to repeat when systemd starts the process again. systemd cannot prevent this because it supervises processes, not application data.

Steps for this case

1. Confirm the systemd release on the host:

systemctl --version

Use the output to determine whether you are on systemd 219 (CentOS 7) or 252+ (CentOS Stream 9).

1. Wrap ExecStart with a script that checks a state file before performing the write. Example:

#!/bin/sh
STATE=/var/lib/myservice/last-write.state
if [ -f "$STATE" ]; then
  exec /usr/sbin/myservice --skip-recovery
fi
exec /usr/sbin/myservice

Update the unit file with systemctl edit --full myservice and point ExecStart at the wrapper. Have the application or wrapper update the state file only after a write is durably complete.

1. Set restart throttling appropriate to the release. On systemd 219, StartLimitIntervalSec and StartLimitBurst use older semantics; on 252, verify current values because behavior can differ under rapid successive failures.

Version assumptions

This answer assumes root or sudo access and that you control the unit file. It assumes systemd 219 on CentOS 7 and systemd 252 on CentOS Stream 9. Exact differences in signal handling and unit parsing between those releases should be treated as unverified until confirmed on the target host.

Verification

• systemctl status myservice to confirm restart count and exit code.
• journalctl -u myservice -n 50 --no-pager to observe crash and restart sequencing.
• Test in a non-production environment: force a controlled process crash, restart the service, and confirm whether the wrapper skips or repeats the write.

Missing diagnostic detail: do the writes target a filesystem path you can guard with a state file, or an external database? This determines whether a wrapper-script approach is sufficient or whether transactional idempotency must be handled inside the application or database layer.