Fixing issue where a server running in the background cannot be stopped #33
Conversation
|
@krmichelos could we just check if |
|
@sethvargo I did that at first but, if I read the puma code correctly, if the server isn't actively processing anything then that number will also be 0 which would make |
|
@krmichelos hrm. I really don't like this solution, but I also have nothing better to propose right now |
|
I agree. I really didn't care for it either. Without making a change in puma I couldn't think of anything better either. |
|
@sethvargo @jkeiser There is a problem with the running? method when the server is running on 0.0.0.0. I will look at it further and fix. I am also open to suggestions about a better way to determine if the server is running. |
|
If the server is on 0.0.0.0, we can always hit 127.0.0.1. I'm sad there's apparently no way to ask Puma if it's actually doing anything :( |
|
I wonder if there is a "listening" method or something ... |
|
I think we should open an issue on Puma and ask This message was sent from my mobile device. I apologize in advance for any typographical errors or autocorrections.
|
|
I opened an issue with puma. puma/puma#364 |
|
Puma said they would add an API for the status of a server. |
|
@jkeiser I think the changes made in a45e8fb continue to leave the API broken as nothing is enforcing the stop wait limit. It would be easy to fix by wrapping the existing code in a Timeout block. I started looking at making running? use the changes made in puma. However, the changes are in the 2.* line and chef-zero is locked on the 1.* line. Unfortunately, I don't have the time right now to ensure that chef-zero can work with puma 2.6. Also it looks like there are additional steps to get puma 2.* to install on windows: puma/puma#202 because of openssl. |
|
Oh heck. Yeah, we're using puma 1 specifically due to the Windows issues. |
|
@jkeiser is this still an issue with the switch to webrick? |
|
We still support puma, is just optional now. But since we no longer have to run on every platform, I bet we could use puma 2 now. |
|
This is fixed in #43 |
When the chef-zero server is being run in the background calling stop doesn't stop the server. While testing my changes I also noticed that the running? method was written in such a way that it would always return true. This is because the running method on the puma server is the number of spawned processes being processed so even if there aren't any being processed !!0 is still true. I didn't see anything publicly available in the puma server that indicated what its status is so I thought connecting to the server to ensure it responds was probably the best way to handle it.