sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
Done and committed.
Here's my simplified understanding of the stuff.
1. In Unix, everything is a file and everything a process deals with are file descriptors.
2. fork() takes the current process, clones it including all memory and file descriptors it is holding, and resumes execution of the original and clone as if the fork() call just returned. The return value of fork() indicates whether you're in the clone, the original (in which case it also is the clone's PID) or whether the fork failed.
3. C++ static objects, such as our networking system holding the sockets (which are naturally file descriptors), are cleaned up in functions registered over the on_exit() mechanism.
4. execve replaces your entire process with a new process (kinda, you get to keep your PID, it's more like a data and code transplantation into your process), initialized from an executable file or script. On success, execve never returns, because there is nothing it could return to. All memory is lost, but file descriptors are NORMALLY retained; that is important because standard input, output and error are also file descriptors and you want the surrogate process to inherit those.
To launch a script, we fork() then execve() the script. On success, the script therefore inherits all sockets (4), but never closes them because it would not know how. Therefore, when the main program closes the main socket, it's not really closed because those things apparently are reference counted and the script process still holds a reference, therefore reopening a new one on the same port fails.
Solution: Have the socket closed before execve(). Luckily, we don't have to do that manually, you can set a flag on every file descriptor marking it for closing on execve(). Even more conveniently, the socket creation function socket() accepts a flag that does just that.
On script launch failure, execve() does return, we call exit() to terminate the cloned process (we're after the fork, still). Which triggers a regular shutdown, including the registered on_exit() functions, thus shutting down the network system. It can't do damage to the original process, but it still prints the shutdown messages to stdout and may send messages to connected clients. To prevent that, we now simply call the other function _exit(), which does everything exit() does, minus the on_exit() functions.
Here's my simplified understanding of the stuff.
1. In Unix, everything is a file and everything a process deals with are file descriptors.
2. fork() takes the current process, clones it including all memory and file descriptors it is holding, and resumes execution of the original and clone as if the fork() call just returned. The return value of fork() indicates whether you're in the clone, the original (in which case it also is the clone's PID) or whether the fork failed.
3. C++ static objects, such as our networking system holding the sockets (which are naturally file descriptors), are cleaned up in functions registered over the on_exit() mechanism.
4. execve replaces your entire process with a new process (kinda, you get to keep your PID, it's more like a data and code transplantation into your process), initialized from an executable file or script. On success, execve never returns, because there is nothing it could return to. All memory is lost, but file descriptors are NORMALLY retained; that is important because standard input, output and error are also file descriptors and you want the surrogate process to inherit those.
To launch a script, we fork() then execve() the script. On success, the script therefore inherits all sockets (4), but never closes them because it would not know how. Therefore, when the main program closes the main socket, it's not really closed because those things apparently are reference counted and the script process still holds a reference, therefore reopening a new one on the same port fails.
Solution: Have the socket closed before execve(). Luckily, we don't have to do that manually, you can set a flag on every file descriptor marking it for closing on execve(). Even more conveniently, the socket creation function socket() accepts a flag that does just that.
On script launch failure, execve() does return, we call exit() to terminate the cloned process (we're after the fork, still). Which triggers a regular shutdown, including the registered on_exit() functions, thus shutting down the network system. It can't do damage to the original process, but it still prints the shutdown messages to stdout and may send messages to connected clients. To prevent that, we now simply call the other function _exit(), which does everything exit() does, minus the on_exit() functions.
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
wow thats amazing , well done
I would have never got there .. well maybe given enough time and an infinite number of monkeys
which source code should I download ? thanks
I would have never got there .. well maybe given enough time and an infinite number of monkeys
which source code should I download ? thanks
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
If you really want a download, go here:
http://download.armagetronad.org/blog/2 ... pha_z2036/
However, from the raspi thread, you're using lp:~armagetronad-ap/armagetronad/0.2.9-armagetronad-sty+ct+ap, right? That has the fix in it already (thanks, Nelg!), just do a 'bzr pull'.
http://download.armagetronad.org/blog/2 ... pha_z2036/
However, from the raspi thread, you're using lp:~armagetronad-ap/armagetronad/0.2.9-armagetronad-sty+ct+ap, right? That has the fix in it already (thanks, Nelg!), just do a 'bzr pull'.
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
im using your 0.2.8-armagetronad-sty+ct build which shows as 0.2.9-sty+ct_alpha_z2161_20200410 on the server
i will be rebuilding my server on a spare i3 laptop motherboard from my parts bin because that old pi really cant handle a lot of spawned zones without the cpu load going crazy and the pings going through the roof
I cant thank you enough for your amazing effort to fix this issue
i will be rebuilding my server on a spare i3 laptop motherboard from my parts bin because that old pi really cant handle a lot of spawned zones without the cpu load going crazy and the pings going through the roof
I cant thank you enough for your amazing effort to fix this issue
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
I downloaded the source from the link but im unable to test it because theres no delay_command which I use to check for the problem /admin delay_command +0 spawn_script loop.sh
I did change the exit(1) to _exit(1) in my build and tried it but the ports still got messed up
could you let me know if there are any other changes i need to make ? thanks
heres the code i use to break the ports
I did change the exit(1) to _exit(1) in my build and tried it but the ports still got messed up
could you let me know if there are any other changes i need to make ? thanks
heres the code i use to break the ports
Code: Select all
#!/bin/bash
# loop.sh kills the server port when all players leave
while true;
do
echo "console_message infinite loop"
sleep 1
done
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
I just tried it again by using spawn_script loop.sh directly from the server screen and it worked thanks z-man
now Ive got to move these changes into my build once I work out where they all are
is there a way to find out what lines of which files have been altered ?
now Ive got to move these changes into my build once I work out where they all are
is there a way to find out what lines of which files have been altered ?
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
Yes; you can go to the web interface on launchpad (https://bazaar.launchpad.net/~armagetro ... ision/1560) or gitlab (https://gitlab.com/armagetronad/armaget ... 255e742865). Locally, both git and bzr have the -p option to their history inspecting functions that also show you changes.
Of course, you really should not transfer these changes at all by hand. You should have been working on a clone of the git or bzr repository and now just merge from the upstream source. If you intend to work with these sources for a longer time, anyway; for quick hacks, do whatever works for you.
Of course, you really should not transfer these changes at all by hand. You should have been working on a clone of the git or bzr repository and now just merge from the upstream source. If you intend to work with these sources for a longer time, anyway; for quick hacks, do whatever works for you.
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
I make changes by hand because I have no idea how merge works
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
With bzr/brz you should just be able to `bzr merge <branch>` assuming there are no conflicts or changes in the branch (well you can --force)
Never a guarantee conflicts won't happen. Also I find it unlikely sty+ct will be getting any changes any time soon other than occasional merges from mainline, but I think merging then pulling any new changes later could potentially cause conflicts. Maybe I'm just paranoid of conflicts after having* to resolve a bunch though
* Well okay, I did it on my own free time when I had a bunch of time to waste. Close enough!
Code: Select all
$ bzr branch lp:armagetronad/0.2.8
Never a guarantee conflicts won't happen. Also I find it unlikely sty+ct will be getting any changes any time soon other than occasional merges from mainline, but I think merging then pulling any new changes later could potentially cause conflicts. Maybe I'm just paranoid of conflicts after having* to resolve a bunch though
* Well okay, I did it on my own free time when I had a bunch of time to waste. Close enough!
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
thanks for the info, I will try that next time
this time I did the patch by hand and it was the change to nSocket that I was missing. its working great now and I can continue with the scripted games I started a while back. I cant wait to get battlezone working
thanks again everyone for the help
this time I did the patch by hand and it was the change to nSocket that I was missing. its working great now and I can continue with the scripted games I started a while back. I cant wait to get battlezone working
thanks again everyone for the help
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
im back sorry
ive noticed something strange
if I manually spawn_script from server console or in game admin and issue exit to reboot server everything is fine scripts and killed server shuts down and my server restarts (its in a while true loop)
but if I put spawn script in autoexec.cfg and then later reboot server with exit the script doesnt get killed and after the reboot theres 2 copies of the script running and my cpu core hits 100%
this is causing an issue because im spawning a script that displays the won matches and after dedicated idle time (set at 24 hours) the server reboots and this is happening in all my servers so I end up with 2 sometimes more copies of the scripts running in all 10 servers and cpu shows crazy usage
any ideas ?
ive noticed something strange
if I manually spawn_script from server console or in game admin and issue exit to reboot server everything is fine scripts and killed server shuts down and my server restarts (its in a while true loop)
but if I put spawn script in autoexec.cfg and then later reboot server with exit the script doesnt get killed and after the reboot theres 2 copies of the script running and my cpu core hits 100%
this is causing an issue because im spawning a script that displays the won matches and after dedicated idle time (set at 24 hours) the server reboots and this is happening in all my servers so I end up with 2 sometimes more copies of the scripts running in all 10 servers and cpu shows crazy usage
any ideas ?
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
I can't explain the difference depending on how you spawn the scripts. But this may be the cause of a runaway 100% CPU script: We do not actively KILL scripts, that could potentially do horrible things if your script is in the process of updating a database or file. We merely close their input stream. So your script needs error handling in the input parsing; if there is nothing more to read, it needs to quit. In bash, a simple
does the trick.
Edit: Oh, just the same as over there, then.
Code: Select all
while read line; do
.. do processing on "${line}"
done
Edit: Oh, just the same as over there, then.
[SOLVED] Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
yeah sorry i wasnt sure why it was happening but it was due to lack of knowledge on my part
thanks again for the help
my bad for posting twice
thanks again for the help
my bad for posting twice
Re: sn_SetNetState: Unable to open accept socket on desired port xxxx, Trying next ports...
Nah, no worries. My bad for not reading the rest of the forums before positing.