Support listen to specify sock file

[LeiZhang-Hunter]

I thought of a solution to solve the php-fpm -F problem

1. Remove libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM);

2. Add pid lock to protect the uniqueness of the process, so that the startup process will not be restarted repeatedly

3. Fix the pid file location

After adding these three items, I solved this problem

[jmjoy]

Will this result in the forked agent process still existing when php-fpm is exited normally?

[LeiZhang-Hunter]

Will this result in the forked agent process still existing when php-fpm is exited normally?

Added linux file lock, which solves the problem of repeated fork process; if the process is running, the same process will not be started again due to the file lock. The specific design idea comes from APUE

[LeiZhang-Hunter]

Will this result in the forked agent process still existing when php-fpm is exited normally?

This perfectly solves the problem of repeated startup of multiple processes

[jmjoy]

Sounds good! Let me try try.

[jmjoy]

For php-fpm -F problem, I think Remove libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM); is not good. Although it is guaranteed that there is only one worker process, the worker process cannot be stopped by stopping php-fpm, and it will remain on the OS. This is not a good solution and cannot solve the problem of php-fpm daemon mode well. In fact, I want to make an standalone worker binary program to solve this problem later.

For reload php-fpm problem, because it is guaranteed that there is only one worker process, so there can be only one socket file, rather than creating socket files with random names. It can solve the problem well.

[LeiZhang-Hunter]

For php-fpm -F problem, I think Remove libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM); is not good. Although it is guaranteed that there is only one worker process, the worker process cannot be stopped by stopping php-fpm, and it will remain on the OS. This is not a good solution and cannot solve the problem of php-fpm daemon mode well. In fact, I want to make an standalone worker binary program to solve this problem later.

For reload php-fpm problem, because it is guaranteed that there is only one worker process, so there can be only one socket file, rather than creating socket files with random names. It can solve the problem well.

Nginx does not set the libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM) option. The user can write a script to stop the agent instead of following the PHP life cycle. Otherwise, if php-fpm does not add -F, the agent process will automatically exit. The user should decide whether to exit the agent, not php-fpm.

[LeiZhang-Hunter]

For php-fpm -F problem, I think Remove libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM); is not good. Although it is guaranteed that there is only one worker process, the worker process cannot be stopped by stopping php-fpm, and it will remain on the OS. This is not a good solution and cannot solve the problem of php-fpm daemon mode well. In fact, I want to make an standalone worker binary program to solve this problem later.

For reload php-fpm problem, because it is guaranteed that there is only one worker process, so there can be only one socket file, rather than creating socket files with random names. It can solve the problem well.

libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM) I think this option is not suitable here. The user should decide to stop the agent, not php-fpm, which will cause accidental killing in daemon mode.

[LeiZhang-Hunter]

• libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM);

libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM);

For php-fpm -F problem, I think Remove libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM); is not good. Although it is guaranteed that there is only one worker process, the worker process cannot be stopped by stopping php-fpm, and it will remain on the OS. This is not a good solution and cannot solve the problem of php-fpm daemon mode well. In fact, I want to make an standalone worker binary program to solve this problem later.

For reload php-fpm problem, because it is guaranteed that there is only one worker process, so there can be only one socket file, rather than creating socket files with random names. It can solve the problem well.

libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM);
This option will cause users to add the -F option. I think it should not change the user's usage habits.

[jmjoy]

1. Nginx can handle the master process TERM signal, but php extension can't.
2. Most current Linux distributions have systemd built in. You can use systemd to host php-fpm without using daemon mode. If you don't have systemd, you can also use supervisord.
3. The user can write a script to stop the agent instead of following the PHP life cycle., which is not a good user experience.

[LeiZhang-Hunter]

• Nginx can handle the master process TERM signal, but php extension can't.
• Most current Linux distributions have systemd built in. You can use systemd to host php-fpm without using daemon mode. If you don't have systemd, you can also use supervisord.
• The user can write a script to stop the agent instead of following the PHP life cycle., which is not a good user experience.

1. Nginx can handle the master process TERM signal, but php extension can't.
2. Most current Linux distributions have systemd built in. You can use systemd to host php-fpm without using daemon mode. If you don't have systemd, you can also use supervisord.
3. The user can write a script to stop the agent instead of following the PHP life cycle., which is not a good user experience.

If the user being installed does not use systemd, we should not ask the user to modify the deployment method. We should let the user read the pid through the pid file and then send the SIGTERM signal by himself.

[LeiZhang-Hunter]

For php-fpm -F problem, I think Remove libc::prctl (libc::PR_SET_PDEATHSIG, libc::SIGTERM); is not good. Although it is guaranteed that there is only one worker process, the worker process cannot be stopped by stopping php-fpm, and it will remain on the OS. This is not a good solution and cannot solve the problem of php-fpm daemon mode well. In fact, I want to make an standalone worker binary program to solve this problem later.

For reload php-fpm problem, because it is guaranteed that there is only one worker process, so there can be only one socket file, rather than creating socket files with random names. It can solve the problem well.

Has this discussion reached a conclusion?

[wu-sheng]

Is this going to work? I can see it id stale for weeks.