Using Supervisor to keep Ratchet-Application running

[André Wuttig]

I user supervisor to run our websocket-server. Everything works fine, since i want to restart the supervisor process.

I have the same supervisord.conf like here: http://socketo.me/docs/deploy

When i want to restart the single running process supervisord says:

supervisor> restart ratchet:Ratchet
ratchet:Ratchet: stopped
ratchet:Ratchet: ERROR (abnormal termination)


supervisor> status
ratchet:Ratchet                   FATAL      Exited too quickly (process log may have details)

error.log:
...
Could not bind to tcp://0.0.0.0:8080: Address already in use'
....

How to you tackle this problem, that the port (8080) is already in use?

Best Regards

André

[Chris Clark]

Hi

You can do one of two things. 

1. Change the port Ratchet is using for websocket connections (8080) 

2. Change whatever else is using port 8080

For 1 change the line $webSock->listen(8080, '0.0.0.0'); // Binding to 0.0.0.0 means remotes can connect
in /bin/push-server.php
to a different (available) port

For 2 try this out http://www.cyberciti.biz/faq/what-process-has-open-linux-port/

[mae...@abdoulaye.com]

The problem is that when supervisor stops your script, PHP itself is staying behind and keeps listening to the port. Another way has to be found to ensure that supervisor stops PHP itself which will stop your script anyway. Run the command...

netstat -ap

... see it yourself.

It's not just 8080. Even if you change the port, it will happen over and over.

[Abdoulaye Siby]

I have done more digging and I have discovered that the issue is in the value passed to the "command" option under the [program:yourprogramname] section of the supervisor configuration file.

The Ratchet deployment instructions suggest that we should use something like the following:

command = bash -c "ulimit -n 10000 && /usr/bin/php path/to/your/script"

That's what's causing PHP to hang and keep listening to the port. This makes is impossible to restart Ratchet from within the supervisorctl shell. It also makes it impossible for supervisor to restart you script gracefully after a crash. It will always with say that the address is already in use.

Now, try changing the command option to the following and you will see that it will work flawlessly (start ..., reread, restart all, reload, ...)

command = /usr/bin/php path/to/your/script

My analysis of the situation is that when you use bash -c "ulimit -n 10000 && /usr/bin/php path/to/your/script", then supervisor will not see PHP (and your script) has a child process to be supervised. Instead, it will see the bash command. Normally, since bash has started PHP, one might think that stopping bash should stop PHP. But I am now wondering what happens if that PHP script has the ability to fork.

The bottom line  is that we should find a way to be able to run the ulimit -n 10000, without using bash as main script.

Regards

Abdoulaye Siby

[Abdoulaye Siby]

Ok. I have found something else. I have added the following in my PHP script and executed it ...

echo `ulimit`;

The output was

unlimited

So in my case, there is really no need to set the ulimit to 10000 before running the script. I am content with "unlimited".

You can set the limits by editing the file at /etc/security/limits.conf

I hope this helps.

Regards.

Abdoulaye Siby

[joela...@gmail.com]

+1 for Abdoulaye, solved my problem too