The server info command was fixed some time ago to have the correct status, but the server info --json output was not. They should not return the proper status now. I've checked server list and server list --json and they show proper status as well.

I've spent a bit of time playing around with this today, and I think it may be a WSL issue.

After putting in some systemOutput calls, I've found the isPortAvailable() call is always returning true, even when the server is running (ps -a shows me the process, and killing this process is the only way I've found the stop the service).

I've also found that netstat actually shows nothing in WSL, but if you run it from the windows command prompt, it does show the port as being in use.

I suspect https://github.com/Microsoft/WSL/issues/1554 is the WSL issue that is causing this, but I can't see any workaround.

No worries , just update whenever you get a chance. Since it's all just CFML, feel free to muck around in the code in your local CommandBox install to help troubleshoot If you change a CFC, just run the `reload` command from the shell and it will pick up the changes.

Just an FYI - I do plan on getting details to you. On the road for a while.

Hmm, I'm not really sure. None of the other WSL users have reported anything similar and I don't have Windows 10 to try it out myself.

If you can't stop the server but you're sure it's running, you'd need to do a kill after finding the PID. When you start a server, it binds to a "stop port" (which is different from the HTTP or HTTPS ports. You can see what the stop port for a given server is by running

The server process should be bound to that port on the same IP as the HTTP(S) ports which should show up with netstat. When CommandBox goes to check the status of a server, it attempt to bind to the stop port again and if it errors that the port is in use, the server is assumed to be running. If the binding is successful, it closes the connection and assumes the server wasn't running. This is a little wonky, but Java doesn't expose another easy method to simply check to see if a port is open or not.

So, all that said, if CommandBox tells you the server is already stopped, that means that one way or another CommandBox was able to bind to the port so it appeared to be open. Now, there are some wrinkles due to the rather horrible way Java forces me to go about this. If an exception is thrown while binding to the port, but the message is "Cannot assign requested address", CommandBox assumes the port is actually in use since that message usually happens when the user has messed up their host file entries and we don't want to confuse old, unused servers with no host entry and actually running. So, basically the only way to track down what's happening given the existence of several different scenarios would be to reproduce the issue and put some debugging code into the ServerService.cfc in CommandBox to see exactly what's going on. If you want to poke at it, check out the isPortAvailable() method in the server service.
https://github.com/Ortus-Solutions/commandbox/blob/development/src/cfml/system/services/ServerService.cfc#L1381-L1401
You can put in some systemOutput( 'debug message here', true ) calls to see what parts of the try/catch it's hitting. If that sounds like too much work, then I'm going to need to know how to reproduce and to get access to a Windows 10 machine somewhere to see it in action. This could quite possibly be due to some edge cases that are being handled differently in the networking stack over WSL but the code that's there now was sort of a trial-and-error approach to reverse engineer the kinds of exceptions that get thrown by Java and what they mean.

One thing I've considered doing to the isPortAvailable() method is to swap it out with an actual netstat call to see if the port is open. Given the variance of native networking binaries across different *nix distros, I'm not entirely sure if that would solve more problems than it caused