pidfile may cause the process to fail to start properly

[mengxunQAQ]

Steps to reproduce

• First, set a path as pidfile(e.g. /tmp/test.pid). Then start the process of gunicorn normally
• Close the process of gunicorn by kill -9 or shutdown hardware, the pid number in pidfile will be left
• After this, other process are pulled up, and the pid number is same as that in the pidifile by chance
• Finally, if we want pull up gunicorn again, the process of gunicorn will always exit

Cause of the problem

gunicorn/gunicorn/pidfile.py

Line 74 in a86ea1e

os.kill(wpid, 0)

Solution

• Ensure the process is not pulled up repeatedly by fcntl . It will cost some time to fix.
• Or just remove the logic that verifies pidfile. If the same configuration is used to pull up process repeatedly, port will conflict, verify pidfile is no need. And most people also only pull up a set of gunicorn.

[pajod]

/tmp/test.pid

On linux(-like) systems, this is not a good choice, given that any unprivileged user can write to the shared /tmp directory.

After this, other process are pulled up, and the pid number is same as that in the pidifile by chance

That chance is low, as long as the pid file resides in a directory not preserved across restarts (e.g. on a tmpfs mount at or below /run).

If the same configuration is used to pull up process repeatedly, port will conflict

Not necessarily. --bind=[::1]:0 is valid configuration and works.

[mengxunQAQ]

• /tmp/test.pid is just an example
• That chance is low. but if it happens, it can be very troublesome
• Whether the verification logic can be removed, this part can be guaranteed by the user himself in practice

[mengxunQAQ]

Plus, I've had this problem twice recently