How to Fix Time Desync Between MU Online Servers

A MU Online server typically distributes its responsibilities across multiple processes — GameServer, ConnectServer, JoinServer, DataServer, and the MySQL/MariaDB database — which may run on the same machine or on different machines/VMs. When any of these components' clocks fall out of sync, even by a few seconds, confusing symptoms appear: automatic events firing at the wrong time, authentication sessions expiring earlier than expected, and logs with out-of-order timestamps that make any investigation harder. This tutorial explains how to diagnose the root cause of the desync and fix it permanently, with automatic synchronization via NTP and timezone adjustments across every layer of the server.

Common symptoms of time desync

Desync rarely shows up as an explicit error — it appears as strange, intermittent behavior. The most frequent signs include: Blood Castle or Devil Square opening minutes before or after the configured time, players getting disconnected with "session expired" shortly after logging in, time-based item cooldowns (for example, the use of certain consumables) clearing sooner than expected, and a discrepancy between the clock shown in the game client and the actual system time.

Where time is used within the server architecture

Diagnosing the root cause

The first step is isolating exactly where the deviation is. Run the time command on each machine/service involved and compare it against a reliable time source (a public NTP server, such as pool.ntp.org):

# Linux - check the current system time
date
timedatectl status

# Check whether the sync service is active
systemctl status systemd-timesyncd
# or, if using chrony
chronyc tracking

On Windows (common on MuEmu/IGCN-based MU servers):

w32tm /query /status
w32tm /query /peers

If the reported deviation (offset) is greater than a few seconds, or if the sync service is inactive, you've found the likely cause.

Fixing it with NTP on Linux

# Install chrony (recommended, more accurate than traditional ntpd)
sudo apt install chrony -y

# Configure trusted NTP servers in /etc/chrony/chrony.conf
# pool pool.ntp.org iburst
# pool a.ntp.br iburst
# pool b.ntp.br iburst

sudo systemctl enable chrony
sudo systemctl restart chrony

# Force immediate synchronization
sudo chronyc makestep

Using Brazilian NTP servers (a.ntp.br, b.ntp.br, maintained by the National Observatory) reduces synchronization latency for servers hosted in Brazil, compared to relying only on generic international pools.

Fixing it on Windows Server

# Configure the Windows Time service to use NTP
w32tm /config /manualpeerlist:"a.ntp.br,b.ntp.br,pool.ntp.org" /syncfromflags:manual /reliable:YES /update

# Restart the service
net stop w32time
net start w32time

# Force resynchronization
w32tm /resync /force

In environments with multiple Windows VMs on the same physical host (common in MU setups with separate GameServer, ConnectServer, and JoinServer), configure all of them to sync with the same NTP source — mixing different sources across VMs in the same cluster reintroduces small deviations, but enough to cause the symptoms described above.

Adjusting the application timezone

Beyond the system clock, check the timezone configured in each application. It's common for the GameServer to have a hardcoded timezone in its configuration (often UTC or GMT-3 for Brazilian servers) that needs to match the operating system's and database's timezone:

[Config]
TimeZone = America/Sao_Paulo

-- Check and adjust MySQL's timezone
SELECT @@global.time_zone, @@session.time_zone;
SET GLOBAL time_zone = '-03:00';

If the operating system is set to America/Sao_Paulo but MySQL is configured for UTC (+00:00), every timestamp written to the database will have a 3-hour offset relative to local time, producing exactly the "event at the wrong time" symptoms.

Validating the fix with a controlled test

1. After configuring NTP and the timezone across every component, restart GameServer, ConnectServer, JoinServer, and the database service.
2. Compare the time shown by date/w32tm /query /status on each machine — the difference between them should be under 1 second.
3. Set up a test automatic event (Devil Square, for example) to open in 5 minutes and confirm it fires at the exact time.
4. Check a new login record in the database and confirm the timestamp matches the actual time of the test.

Continuous monitoring to prevent recurrence

Time desync tends to gradually come back (drift) even after being fixed, especially on VMs with unstable hardware clocks. Set up a simple alert (a cron script or infrastructure monitoring) that periodically compares the system time against a reliable NTP source and notifies the team if the deviation exceeds a threshold (for example, 2 seconds), before the problem starts affecting players again.

Common errors and fixes

Time synchronization checklist

• Each component's time compared against a reliable NTP source.
• Sync service (chrony/NTP on Linux, w32time on Windows) active and set to start on boot.
• Timezone aligned across operating system, application (GameServer), and database.
• Controlled test of an automatic event confirming the correct time.
• All VMs/machines in the cluster syncing with the same NTP source.
• Continuous time deviation monitoring configured.

With time reliably synchronized across every component, it's worth reviewing the server's overall architecture to identify other weak points before they become incidents visible to players. Check out the MU Online server creation tutorial to review the fundamentals of the complete infrastructure.

Frequently asked questions