Maybe there’s a better way but to work around this pesky problem I’ve the
recipe add a ‘finish’ file to kill merb:
exec kill -9
lsof -i :<%= node[:chef][:server_port] %> -t
exec kill -9
lsof -i :<%= node[:chef][:webui_port] %> -t
Make sure it’s chmodded to 755
On Fri, Jul 16, 2010 at 8:56 AM, Joshua Timberman email@example.com:
On Jul 16, 2010, at 9:31 AM, Ringo De Smet wrote:
On 16 July 2010 17:10, Joe Williams firstname.lastname@example.org wrote:
This is generally because something is already listening on the port.
Try “lsof -nP | grep LISTEN” and kill the pid that’s listening on the port.
To that end has anyone noticed this happening when starting/stopping
with runit? I’ve seen a couple times where this happens on a runit restart.
Tnx. I did “sv stop chef-XXX” for several chef subsystems before the
upgrade of the gems, but as you mentioned, some of the services didn’t
stop at all. All OK now after a real restart.
When started by runit, the chef-server and chef-server-webui services spawn
merb master processes, which in turn start the merb workers (which by
default are ‘thin’ web servers).
The merb master doesn’t always stop/start/restart the workers properly,
related to a way that merb does its own internal process handling. If you
send an ‘int’ signal, a la:
sudo sv int chef-server
It should behave properly for restarting the Chef Server. If you need to
ensure a full stop before restarting such as when doing an upgrade, then you
may need to check for running ‘merb’ processes and kill them.
Joshua Timberman, Senior Solutions Engineer
C: 720.334.RUBY E: email@example.com