3 ms·

That's still not good enough. pids wrap and eventually it could point to something valid, especially on a busy system. systemd uses linux cgroups so that it k

That's still not good enough. pids wrap and eventually it could point to something valid, especially on a busy system. systemd uses linux cgroups so that it knows exactly which pids belong to the group. 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.

cesarb 5y ago
> 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/45497f4d3b212307569fc06bdab6a35a3e2dab07 https://github.com/systemd/systemd/commit/45497f4d3b21230756...
lmm 5y ago
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.
- fullstop 5y ago
  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/
capitainenemo 5y ago
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.
- fullstop 5y ago
  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. :-)

cesarb 5y ago

> 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/45497f4d3b212307569fc06bdab6a35a3e2dab07 https://github.com/systemd/systemd/commit/45497f4d3b21230756...

lmm 5y ago

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.

fullstop 5y ago
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/

capitainenemo 5y ago

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.

fullstop 5y ago
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. :-)