Closed luan122 closed 7 years ago
Hi, Glad you successfully achieved the upgrade. It is certainly a good thing to do.
I think the Ark console won't display useful stuff in it. I'd appreciate an Ark user to confirm this if possible.
Concerning the S_API_FAIl, it's a non-issue. https://github.com/GameServerManagers/LinuxGSM/wiki/FAQ#s_api-fail-steamapi_init-failed-steamapi_issteamrunning-failed
Exit code 0 means that the command worked as intended. In other terms, your install seems to be working properly. Is there any game log anywhere that would help diagnosing why it closes ?
@UltimateByte @luan122
«the Ark console won't display useful stuff in it» — I confirm this. Just a few rows of useless and uninformative crap.
why did @cedarlug changed the title of the issue since the problem started after I did the update in tmux was him with me when I did the update to say that w/o any evidence it isn't?
@Smile42RU yes because of it I didn't answered the question to @UltimateByte
@luan122 - Because your issue is with Ark, not tmux.
@luan122 Would you please post the output of "./arkserver details" to pastebin and reference the output?
@Smile42RU
@luan122 @cedarlug
I guess you can use the /arkserver pd
(post-details) now to simplify the process, and share us the link ! :p
@cedarlug I'm not sure his Ark closes after starting up. I think it's more of a listening issue.
@luan122 There is actually way too few info about your issue to diagnose the source of the problem, we need your server details. I'm also curious to know what ./arkserver monitor says after starting the server.
(Need to do "./arkserver uf" first, but then you can now do "./arkserver pd")
@luan122 Would you please issue ./arkserver uf ; ./arkserver pd
and post the link provided?
There we go, sorry for the delay to post it I got some problems and was close to give up but i'm back.
This is the link that pd gave me after start the server: http://hastebin.com/efafenehak
this is the link the pd gave me after using uf: http://hastebin.com/gixutecogi
I'm using tmux 2.4 (I installed it manually since "yum install" install 1.8
There is a new post details with more memory: http://hastebin.com/motikehopa
weird how PD shows it's online when it isn't
@luan122 Sorry, but it looks like hastebin isn't functioning the way it should.
Could you instead please run:
posttarget="http://pastebin.com" ./arkserver pd
which will post the output to pastebin (instead of hastebin).
there is: http://pastebin.com/zf5ZZ2pQ
The output to netstat -atunp | grep ShooterGame is null
CentOS. https://youtu.be/6TxL-xk0V14?t=2 😆
Can you please try to start your server with the debug command, and try to connect to it ? That way we can make sure 100% it's not a tmux issue. ./arkserver debug Make sure any instance or residual tmux session are closed.
This is the output of the debug:
4.5.1-0+UE4 7038 3077 402 6 [S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed. Setting breakpad minidump AppID = 346110
This is the output of netstat -atunp | grep ShooterGame:
udp 0 0 107.150.42.77:7779 0.0.0.0:* 17020/./ShooterGame udp 0 0 107.150.42.77:27015 0.0.0.0:* 17020/./ShooterGame
So if you start the server with debug, and input the netstat in another console, then it's finally listening ? If yes, means it's still a tmux issue.
Yes, and why is the shooter game using port 7779 instead 7778 that is in the configuration?
Some games use the upper port than what is set. It might just be normal. PS : The output of debug won't ever be relevant for Ark since the console isn't displaying anything except this steam api notice. The point to running debug in your case is to avoid using tmux for diagnose purpose.
Right, I rolledback Tmux to 1.8, looks like it is in use and when I use dt command shows the server is online (I'm using bRawsockets configuration as well)... Does 1.8 will impact anything in my server? Another question... All ports are open as you said in the Readme and anothers like:
7777:7778 26900:26905 27015:27020 27215
But the server doesn't appears in ark list or even in steam ark server list
1.8 is full of bugs. Maybe use a version known for working like 1.9 instead of 2.4.
Concerning good practice for ports, and accessibility issues, have a read at this, i just reworked it. https://github.com/GameServerManagers/LinuxGSM/wiki/Ports
This is really weird... I'm connected with RCON and connected in the server inserting the ip manually in my favorite servers so I think the ports aren't blocked in my server
Follow this procedure to check this out in a relevant way: https://github.com/GameServerManagers/LinuxGSM/wiki/Ports#diagnosing-server-accessibility
I got this from tcpdump:
82 17.102617800 99.64.176.253 -> 107.150.42.77 UDP 67 Source port: 61432 Destination port: 27015 83 17.114653271 107.150.42.77 -> 99.64.176.253 UDP 282 Source port: 27015 Destination port: 61432 84 17.299498490 189.78.9.171 -> 107.150.42.77 TCP 60 fj-hdnet > ssh [ACK] Seq=1 Ack=1745 Win=257 Len=0 85 17.447623557 189.78.9.171 -> 107.150.42.77 SSH 134 Encrypted request packet len=80 86 17.448008882 107.150.42.77 -> 189.78.9.171 SSH 150 Encrypted response packet len=96 87 17.636542995 189.78.9.171 -> 107.150.42.77 SSH 134 Encrypted request packet len=80 88 17.636917427 107.150.42.77 -> 189.78.9.171 SSH 150 Encrypted response packet len=96 89 17.644116162 107.150.42.77 -> 189.78.9.171 SSH 118 Encrypted response packet len=64 90 17.655760746 99.64.176.253 -> 107.150.42.77 UDP 60 Source port: 53766 Destination port: 27015 91 17.657215116 107.150.42.77 -> 99.64.176.253 UDP 51 Source port: 27015 Destination port: 53766 92 17.825386914 189.78.9.171 -> 107.150.42.77 SSH 134 Encrypted request packet len=80 93 17.825742250 107.150.42.77 -> 189.78.9.171 SSH 134 Encrypted response packet len=80 94 17.887092331 189.78.9.171 -> 107.150.42.77 TCP 60 fj-hdnet > ssh [ACK] Seq=1 Ack=1809 Win=256 Len=0 95 17.921925041 99.64.176.253 -> 107.150.42.77 UDP 60 Source port: 53766 Destination port: 27015 96 17.953256220 107.150.42.77 -> 99.64.176.253 UDP 456 Source port: 27015 Destination port: 53766 97 18.012094794 189.78.9.171 -> 107.150.42.77 SSH 134 Encrypted request packet len=80 98 18.012741221 107.150.42.77 -> 189.78.9.171 SSH 1494 Encrypted response packet len=1440 99 18.012913658 107.150.42.77 -> 189.78.9.171 SSH 406 Encrypted response packet len=352
And with netstat i got this:
netstat -atunp | grep ShooterGame udp 0 0 107.150.42.77:7777 0.0.0.0:* 28145/./ShooterGame udp 0 0 107.150.42.77:7778 0.0.0.0:* 28145/./ShooterGame udp 0 0 107.150.42.77:27015 0.0.0.0:* 28145/./ShooterGame
Ps.: I know I'm talking about different problems here, but would be nice if you help me to solve it, I'm sure it can help alot of people that has the same problems
To me it's clear that setting an x port will use this x port plus x+1 That's a common practice for servers, i would not worry about that.
However, your previous output was udp 0 0 107.150.42.77:7779 0.0.0.0:* 17020/./ShooterGame udp 0 0 107.150.42.77:27015 0.0.0.0:* 17020/./ShooterGame
So maybe, i say maybe, there is a residual process opened in this case ?
Hmmm, I enabled bRaw in my server now it's using 7777 and 7778 and the problems still here I also restarted it several times
Update on this ?
Closing no update
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Hello, I did the update of tmux following this guide: https://github.com/GameServerManagers/LinuxGSM/wiki/Tmux#upgrade-tmux-ubuntu
after it the command start in arkmanager isn't working, everytime I use it the server start to load and after a time it close shootergame proccess
those are my logs: log/console:
log/script