You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Take a serious note on the socket parameter, it's a Unix socket and not a TCP socket.
When I start uwsgi, no troubles. It works.
The problem comes when SIGQUIT is issued to the parent process.
It doesn't remove the Unix socket (viz /tmp/php.sock) on termination.
This problem doesn't occur when using TCP sockets obviously, because no process is listening on the TCP socket.
The disadvantage of the Unix socket not being removed is, when you restart, say you made some changes to the startup parameters, the socket has to be removed manually or uwsgi fails to start the vassal because the socket is already bound!
It starts throwing errors of socket is already bound and throttles the vassal. When you remove the socket file manually (with or without terminating uwsgi parent process), everything is back to normal.
The text was updated successfully, but these errors were encountered:
uWSGI removes the unix sockets it find when it starts, so you should not experience that behaviour.
By the way, it could be caused by something else, can you send logs (those generated during instance quit/respawn) too ?
If you want to force the removal of the unix socket file, you can add vacuum = true to the vassal config, but if it works there is defintely something wrong in the socket initialization code that must be fixed
I'm running uwsgi 1.4.2 in emperor mode.
/usr/bin/uwsgi --emperor /etc/uwsgi.d --daemonize /dev/null --disable-logging --lazy --protocol uwsgi --pidfile /var/run/uwsgi/uwsgi.pid
And this is the PHP Vassal config:
Take a serious note on the socket parameter, it's a Unix socket and not a TCP socket.
When I start uwsgi, no troubles. It works.
The problem comes when SIGQUIT is issued to the parent process.
It doesn't remove the Unix socket (viz /tmp/php.sock) on termination.
This problem doesn't occur when using TCP sockets obviously, because no process is listening on the TCP socket.
The disadvantage of the Unix socket not being removed is, when you restart, say you made some changes to the startup parameters, the socket has to be removed manually or uwsgi fails to start the vassal because the socket is already bound!
It starts throwing errors of socket is already bound and throttles the vassal. When you remove the socket file manually (with or without terminating uwsgi parent process), everything is back to normal.
The text was updated successfully, but these errors were encountered: