Fix #3383 we should not exit when the process represented by pid is running

[mengxunQAQ]

• Many software also have a pidfile, eg NGINX., but it does not exit just because the process number in the pidfile is running; it merely writes a new pid to the file
• Whether to run repeatedly or not can be guaranteed by the user themselves

[pajod]

The user can also guarantee to not place the PIDfile on persistent storage. This could be a documentation change only, while keeping the helpful (and, except in cases of rare pid recycling, generally the result of a clear mistake) error.

Side note: Anyone not interested in the old behavior is probably better served by running an init that remembers what processes it started (such as systemd) and never care about pid files ever again.

[benoitc]

I don't understand what this issue is about. Please clarify the context when this jhappen. and when/what to reproduce.

[mengxunQAQ]

I don't understand what this issue is about. Please clarify the context when this jhappen. and when/what to reproduce.

If the device restarts or the process is unexpectedly terminated, the PID recorded in the pid file may be taken by another process, which can prevent Gunicorn from ever starting.

In other words, the problem will occur as long as two conditions are met:

• Gunicorn did not properly clean up the PID file.

• During the interval when Gunicorn restarts, another process happens to use the same PID.

[mengxunQAQ]

I don't understand what this issue is about. Please clarify the context when this jhappen. and when/what to reproduce.

To reproduce the issue, you can set the number in the PID file to 1, and then Gunicorn will never be able to restart.

[benoitc]

why would you do that though. Notmlally the pid file should be properly cleadned during shutdown.

[mengxunQAQ]

why would you do that though. Notmlally the pid file should be properly cleadned during shutdown.

We cannot assume that a process will always receive proper termination or restart notifications.
In cases such as a device power-off, system reboot, or when the system kills the process due to high memory pressure, the process cannot be able to perform normal cleanup operations and thus fail to remove its PID file.
This can lead to conflicts.

[adk-swisstopo]

I believe the concern is valid (there is no way for gunicorn to ensure it will always clean up its own pid file) and it is possible for the pid to be reused. I also understand the current behaviour can prevent accidentally starting gunicorn twice. The proposed change removes that safety.

I think we can get the best of both worlds by having gunicorn overwrite the pid file if it does not have permissions to send a signal to the process associated to the pid (i.e. errno == EPERM) and keep the existing behaviour otherwise (i.e. die if there is a process associated to the pid and it is running as the current user). This means pid reuse by the same user after an abnormal termination of gunicorn will still prevent gunicorn from starting but that is much less likely.