Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emperor Mode: Unix socket not removed on termination #69

Closed
nileshgr opened this issue Nov 29, 2012 · 2 comments
Closed

Emperor Mode: Unix socket not removed on termination #69

nileshgr opened this issue Nov 29, 2012 · 2 comments

Comments

@nileshgr
Copy link

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:

[uwsgi]
plugins = php54
uid = nginx
gid = nginx
processes = 15
cheap = true
socket = /tmp/php.sock
php-allowed-docroot=/var/www
php-allowed-ext=php
php-index=index.php
idle = 5
chdir=/var/www

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.

@unbit
Copy link
Owner

unbit commented Nov 29, 2012

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

@nileshgr
Copy link
Author

Weird. I'm not able to reproduce the issue now. Looks like a false alarm. (Didn't add vacuum = true).

But the file is not removed on shutdown. The bind socket error disappeared, though. vacuum = true removes it as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants