Wait... how would pid wrapping impact anything at all unless the process died and the pid file was stale (which is usually a fairly unusual circumstance - I've had it happen maybe a dozen times over the last couple of decades). And I guess if you have stuff surprise dying without any of the usual cleanup, you have a pretty serious situation in general. Maybe need a process monitor service just for that :)

I was focusing on the "surprise startup" scenario where it would all get wiped and reset.

As with anything else, your chances increase with the number of processes you have running.

If it blindly reads the pid and sends a kill signal, your odds are pretty good with a limit of 32K pids on a busy system. If it confirms that the process name matches an expected value, you have less of a chance.. but if your process name is bash, java, or python, maybe not as good as you would hope.

I don't have things crashing a lot, but it's naive to pretend that it never happens. It could result in two things: the rc system telling me that everything is fine or the rc system sending signals to some unrelated, poor, unsuspecting, processes.

I don't need a process monitor just for that. I have systemd. :-)

> The defaults have surely changed over the years, but pid_max used to be ~32K by default. On the system I'm typing this comment on, /proc/sys/kernel/pid_max is set to 4194304.

The commit which changed the defaults is this one: https://github.com/systemd/systemd/commit/45497f4d3b21230756...

How does systemd make sure it never reuses a cgroup, OOI? If you're worried about PIDs wrapping, surely that applies to anything randomly-generated as well.

It's derived from the service name, which is guaranteed to be unique. It's similar to how names need to be unique in /etc/init.d/