Problems with "waiting for server to start authentication" and other strange issues...

[DangerRuss]

Alright so Im a newb at running a VDS this is my first one. I moved over from a gaming server with another provider. I run a fairly popular Dayz Mod server (Overwatch mod). Ive tried setting one up on this server 3-4 different ways now and I always seem to have this problem. About ~1 hour after a restart with a relatively full room (~50 people), new players who log in or die and try to rejoin get stuck at waiting for server to authenticate and then get kicked back to the lobby. Another strange bug that has been plaguing me across all of the builds is this bizarre message they will sometimes get before it kicks them back to the lobby that says "player already dead please rejoin." I have googled this until my fingers bleed and I can find nothing. The only thing I've found to resolve this issue is to delete the "alive" instance of that player from the database.

The server authentication time out seems to be related to the speed that the server communicates with the hive, and Im hoping this player died thing might be as well. All I really know is this server never had this problem before being set up on a VDS and it's literally killing the server. I'd hate to go back to my old host because their customer service is literally the worse I've ever experienced but I know at least the server worked.

Any helpful pointers or tips would be much appreciated. I've tried to toy around a little bit with the my.ini and a few other files but to no avail.

[Caliban55]

There could be a few reasons why this is happening (it would be helping if you would post your server RPT file and your basic.cfg file).

Did you check if your MySQL user has the required permissions to modify the MySQL table (alter, delete, drop, etc.)?
Where is the MySQL server hosted and how (should be on the same machine, MySQL community version, not XAMPP)?
What kind of VDS are you using? What are the server's computational cycles (is the server struggling to run the mission, having problems processing client data; in essence, is the server using up all of it's resources)?

There is a very old bug with Arma that results in player unit objects no longer registered correctly (Error: No unit). A server/mission restart is required.

[stickz]

Are the following options checked off?

[*] Exempt this server from being restarted for using 100% CPU
[*] Exempt this server from being restarted for using 1500 MB of memory

[DangerRuss]

There could be a few reasons why this is happening (it would be helping if you would post your server RPT file and your basic.cfg file).

I can post the basic.cfg although I dont think the server.rpt will be of any help because it doesn't seem to have any errors regarding this, only default errors that are always in the RPT when using Overwatch. I am also hosting an overwatch server with Vilayer using a managed gaming server and it has the same errors.

here is my basic.cfg

Code: Select all

MaxMsgSend=384;
MaxSizeGuaranteed=512;
MaxSizeNonguaranteed=256;
MinErrorToSendNear=0.039999999;
MinErrorToSend=0.0049999999;
MaxCustomFileSize=0;
Windowed=0;
adapter=-1;
3D_Performance=1;
Resolution_W=800;
Resolution_H=600;
Resolution_Bpp=32;
serverLongitude=2;
serverLatitude=49;
serverLongitudeAuto=2;
serverLatitudeAuto=49;
class sockets
{
	maxPacketSize=1400;
};

Did you check if your MySQL user has the required permissions to modify the MySQL table (alter, delete, drop, etc.)?
Where is the MySQL server hosted and how (should be on the same machine, MySQL community version, not XAMPP)?

The server is set up locally on the same machine. We set it up using XXAMP. Im logging in as a localhost with all of the database:hivemind and global privileges selected. I can make manual edits to the database. The database does other functions on its own just fine (respawning vehicles, showing dead instances of players, updating world coordinates, etc.) To be honest the database "stuff" is where Im in a bit over my head because I have zero experience with it.

What kind of VDS are you using? What are the server's computational cycles (is the server struggling to run the mission, having problems processing client data; in essence, is the server using up all of it's resources)?

Im using the unmanaged VDS option with the following specifications :
Four core
Four full, dedicated HT CPU cores (Nehalem or better)
4096 MB of RAM
400 GB of RAID-protected storage
16000 GB of bandwidth transfer

The server did not appear to be using 100% of it's resources. It was using about 2gb's of RAM and roughly ~50% cpu when the server was full.

Again the server seemed to run more or less fine for an hour or so. Then players would suddenly receive this player already dead bug which I could only fix by going into the database and setting their alive instance to zero. Then they could rejoin the server as a "fresh spawn" Then the other problem they might experience would be the server hung up on the "waiting for server to start authentication." and I would see this error in the RPT "ERROR: Cannot Sync Character as no characterID" BUT I still see that error on my other server from time to time and that runs fine and I never see the player already dead error. If from time to time players are stuck trying to get into the server, it is only a few people and not the entire server, and if they attempt to rejoin a few times they will eventually get in.

Are the following options checked off?

[*] Exempt this server from being restarted for using 100% CPU
[*] Exempt this server from being restarted for using 1500 MB of memory

I have no idea where these options are located...Im guessing somewhere in my control panel but I dont see them.

Going to include my.ini as well.

Code: Select all

# Example MySQL config file for small systems.
#
# This is for a system with little memory (<= 64M) where MySQL is only used
# from time to time and it's important that the mysqld daemon
# doesn't use much resources.
#
# MySQL programs look for option files in a set of
# locations which depend on the deployment platform.
# You can copy this option file to one of those
# locations. For information about these locations, see:
# http://dev.mysql.com/doc/mysql/en/option-files.html
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.

# The following options will be passed to all MySQL clients
[client]
#password	= password
port		= 3306
socket		= /tmp/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
event_scheduler=ON
port		= 3306
socket		= /tmp/mysql.sock
skip-external-locking
key_buffer_size = 1000MB
max_allowed_packet = 256M
table_open_cache = 12
sort_buffer_size = 512K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
net_buffer_length = 2K
thread_stack = 256K

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (using the "enable-named-pipe" option) will render mysqld useless!
# 
#skip-networking
server-id	= 1

# Uncomment the following if you want to log updates
#log-bin=mysql-bin

# binary logging format - mixed recommended
#binlog_format=mixed

# Causes updates to non-transactional engines using statement format to be
# written directly to binary log. Before using this option make sure that
# there are no dependencies between transactional and non-transactional
# tables such as in the statement INSERT INTO t_myisam SELECT * FROM
# t_innodb; otherwise, slaves may diverge from the master.
#binlog_direct_non_transactional_updates=TRUE

# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = ../data/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = ../data/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 1G
innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 250MB
innodb_log_buffer_size = 20M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer_size = 20M
sort_buffer_size = 20M

[mysqlhotcopy]
interactive-timeout

I've just about given up hope here. I've had to send the server community back to crappy Vilayer gaming server because the amount of problems I was experiencing here was unmanageable. Unfortunately the problems only arise when there are ~50 people on the server killing eachother over and over for an hour or more, so it's really hard to test.

[Caliban55]

Your basic.cfg is a bit off (not that it helps that much, but changing a few values might help - the main problem is the mission and player connections).

Try to change the following values:

Code: Select all

MinBandwidth=10485760;
MaxBandwidth=104857600;
MaxMsgSend=1024;
MaxSizeGuaranteed=1024;
MaxSizeNonguaranteed=512;
MinErrorToSend=0.001;
MinErrorToSendNear=0.01;

This won't do much, but might have some effects. My other recommendation would be to use regular server restarts, every 3 - 4 hours.

For the MySQL connection, it would be interesting what permissions and settings the user has that accesses the database (the assigned database user, which you defined in your Overwatch configuration).

You can disregard stickz's post, it is not relevant for this problem and has not effect (would only be usefull in a managed enviroment anyway and would then still have nothing to do with this problem).

[DangerRuss]

Your basic.cfg is a bit off (not that it helps that much, but changing a few values might help - the main problem is the mission and player connections).

Try to change the following values:

Code: Select all

MinBandwidth=10485760;
MaxBandwidth=104857600;
MaxMsgSend=1024;
MaxSizeGuaranteed=1024;
MaxSizeNonguaranteed=512;
MinErrorToSend=0.001;
MinErrorToSendNear=0.01;

This won't do much, but might have some effects. My other recommendation would be to use regular server restarts, every 3 - 4 hours.

For the MySQL connection, it would be interesting what permissions and settings the user has that accesses the database (the assigned database user, which you defined in your Overwatch configuration).

You can disregard stickz's post, it is not relevant for this problem and has not effect (would only be usefull in a managed enviroment anyway and would then still have nothing to do with this problem).

restarts are normally every 2 hours, I moved them down to 1.5 hours. But the problem happens sometimes immediately following a restart. As a matter of fact it seems to be worse immediately following a restart. The problem will arise about an hour in, but only affect some people. After a restart it's basically the entire server... and again it is fixable by simply deleting their alive instance in the database. So Im really stumped on that part.

I think unfortunately I just have to give up.

[Caliban55]

Try to limit the number of players to something between 25 - 30. 50 is a bit much for ArmA (or split the one 50 players server into two servers). Try to implement a lock command fot the server after a restart, so that the mission can complete it's init phase before clients connect (maybe 1 minute, BEC can be used to do this, or a logged in admin).

Please also check what privileges the user has that accesses the database (GRANT is a bit generic here...). Also check the munber of connections allowed per hour and the number of simultaneous connections. It is also a very bad idea to use XAMPP, use the MySQL community server instead, together with MySQL Workbench.

[DangerRuss]

Try to limit the number of players to something between 25 - 30. 50 is a bit much for ArmA (or split the one 50 players server into two servers). Try to implement a lock command fot the server after a restart, so that the mission can complete it's init phase before clients connect (maybe 1 minute, BEC can be used to do this, or a logged in admin).

Please also check what privileges the user has that accesses the database (GRANT is a bit generic here...). Also check the munber of connections allowed per hour and the number of simultaneous connections. It is also a very bad idea to use XAMPP, use the MySQL community server instead, together with MySQL Workbench.

I appreciate the advise but I've been running a 50 man Overwatch server for ~2+ years now. There's no way Im going to lessen that, there's really no point in running a server at that point.

Thanks for the help. Im just going to have to shut this server down and continue on with the Vilayer server. It would have been nice to run this here but unfortunately there are just too many maybe's and too much trial and error going into this when I already have a server thats running perfectly fine. My original intent was to move the Vilayer server community over to this server and shut that server down but I can see now that there is just too many problems. Thanks everyone for the support and words of wisdom. Perhaps I will rent a NFO server in the future for a different game that is less problematic.