[BUG] Minor - soldatserver.pid erased and serverscript restart (bash script)

[poutch]

Hi, 2 little bugs :

First one : if you have a server started and try to start it again, soldatserver.pid will be erased (even though soldat server is still on with the same pid)

in the bash script "serverscript" for linux users : considering restart, you should add a sleep between the stop and start else the server won t restart (at least on my box and on many others i guess) because it s too fast and script think that the server is still started. I changed it to that for it to work :

;;
        restart)
                $0 stop && sleep 2 && $0 start || exit 1
;;

[EnEsCe]

If you restart the server or start a second copy, the PID will change...

[chrisgbk]

If you restart the server or start a second copy, the PID will change...

As he said; if you attempt to start a second instance of the server, even though the port is in use and the process will terminate, it still writes the PID information and deletes it as part of the startup and shutdown process.

I guess you could put a workaround to check if the current PID still belongs to a running process and avoid trying to start the server in this case. (Referring to the script only)

[FliesLikeABrick]

If you restart the server or start a second copy, the PID will change...

I've had the problem that the original poster is talking about too.  I've talked to chris and maybe you about this.  If you stop/start the server, a significant portion of the time soldatserver.pid doesn't come back.   I don't know whether it has to happen in rapid succession or not.

I suspect that the shutting down server might somehow be delayed in deleting the pid file, so it deletes the one created by the new server instance?  Maybe put a check in the server to only delete the PID file on shutdown if it actually contains the PID of the server that is shutting down?

[chrisgbk]

If you restart the server or start a second copy, the PID will change...

I've had the problem that the original poster is talking about too. I've talked to chris and maybe you about this. If you stop/start the server, a significant portion of the time soldatserver.pid doesn't come back. I don't know whether it has to happen in rapid succession or not.

I suspect that the shutting down server might somehow be delayed in deleting the pid file, so it deletes the one created by the new server instance? Maybe put a check in the server to only delete the PID file on shutdown if it actually contains the PID of the server that is shutting down?

That introduces another layer of issues; it's a race condition, which is what I believe it to be now. What if the second server is unable to open the file because the first is in the process of deleting it? What if the second server has opened the file, but not yet written anything, and the first server reads the file in? What if the first server reads the file in, then the second server writes to it, then the first deletes it because it already read and verified it? Theres no way to guarantee the order operations will happen and how the scheduler will schedule the processes time.

What you should do is design the system you use so it delays starting a second instance of the server until the first has fully shut down, ie: read the PID file, enter a loop that checks the process to see if it's still active, if it exceeds a certain time force kill it, then start a new instance. Then, either: the PID file was cleaned up properly, or the process was forcefully killed and it still exists, and was overwritten (you could also, if you force kill the server, clean the PID yourself).

[poutch]

If you restart the server or start a second copy, the PID will change...

The sleep that i added correct my problems for the bash script when u do "./serverscript restart"

About the second problem that i was talking about, when u have a server started and try to start it again doing "./soldatserver -d", it will not shutdown the process and the old pid is still running (there is no "second copy", which is good). I checked carefully and the pid isn't changed (ps -x) so the old process wasn t terminated and a new process wasn t created. BUT ./logs/soldatprocess.pid got erased by that manipulation even though the server is still running with its first (and only) pid. That 's not a big trouble, i changed the bashscript a bit so that when u do "serverscript start" it will not work if a server is allready started (as it is on the soldat release now, it will still try to start a new server instance and thus erase the soldatprocess.pid file.

BTW this is not really important but can matter when u are doing some status checking on several servers, etc.

[chrisgbk]

If you restart the server or start a second copy, the PID will change...

The sleep that i added correct my problems for the bash script when u do "./serverscript restart"

About the second problem that i was talking about, when u have a server started and try to start it again doing "./soldatserver -d", it will not shutdown the process and the old pid is still running (there is no "second copy", which is good). I checked carefully and the pid isn't changed (ps -x) so the old process wasn t terminated and a new process wasn t created. BUT ./logs/soldatprocess.pid got erased by that manipulation even though the server is still running with its first (and only) pid. That 's not a big trouble, i changed the bashscript a bit so that when u do "serverscript start" it will not work if a server is allready started (as it is on the soldat release now, it will still try to start a new server instance and thus erase the soldatprocess.pid file.

BTW this is not really important but can matter when u are doing some status checking on several servers, etc.

What he meant, is not that the PID of the running server will change; it's that the second instance you attempt to start will start, write it's own PID, detect that the ports are in use, and shutdown immediately, in the timespan of about 1 second.