EssentialsX

EssentialsX

2M Downloads

AFK kicks player immediately after joining

Maxetto opened this issue · 12 comments

commented

Information

Full output of /ess version:

[12:13:41 INFO]: Server version: 1.8.8-R0.1-SNAPSHOT git-PaperSpigot-"4c7641d" (MC: 1.8.8)
[12:13:41 INFO]: EssentialsX version: 2.17.2.3
[12:13:41 INFO]: LuckPerms version: 5.0.72
[12:13:41 INFO]: Vault version: 1.5.6-b49
[12:13:41 INFO]: Citizens version: 2.0.16-SNAPSHOT (build 1308)
[12:13:41 INFO]: EssentialsXChat version: 2.17.2.3
[12:13:41 INFO]: EssentialsXSpawn version: 2.17.2.3

Server log:

[10:56:21] [Thread-375/INFO]: UUID of player BIGBOOM710 is dad5bb29-e2d5-43c4-89df-1b430193eed6
[10:56:21] [Server thread/INFO]: BIGBOOM710[/IP] logged in with entity id 87893 at ([Infected]411.0, 4.5, -128.0)
[10:56:21] [Server thread/INFO]: BIGBOOM710 lost connection: Sei stato cacciato per inattività oltre i 10 minuti.

EssentialsX config: https://gist.github.com/Maxetto/6631ead8db1e9fff51aa722fe274608e

Details

Description
Sometimes when a player joins the server it gets immediately kicked for AFK as set in the kick timeout, but it shouldn't.

Steps to reproduce
I believe after you have been AFK for 240 seconds, as set in the config, and you disconnect or get kicked by something, when you join back after 600 seconds it kicks you because it thinks you have been AFK in the server for that amount of time.

Expected behavior
No kick on join.

commented

Has anyone reproduced this? If not, closing soon 😄

commented

Well, pretty sure the issue has always been due to Daylight Saving.
As far as I understood "System.currentTimeMillis()" returns the current time in UTC, but if I change the current time (manually or automatically), then the timestamp also changes.

This created the issue above during that period of time changing (+1 hour at 2AM) and never happened twice to the same player because after then the timestamps would have been updated.

commented

You should never need to change the time for DST - that's, why timezones and offsets exist, the system time is number milliseconds since 1970 called unix time, this value adjusted by the offset to produce a locality-based time. When you actually change the System time you're changing the UNIX Time value. Set that value using an NTP server and never change it. Then if your region doesn't have a DST timezone just change the tzdata to the most appropriate value. To give you an example my Timezone is AEST. My locality is Qld - a locality that doesn't support Daylight savings - my server is located in Sydney and by default sets it zone to ADST (or AEST with daylight savings running OCT-MAR) I would change this to change the server time.

commented

Looking inside the userdata files, the user that got kicked in the logs doesn't have any "afk" entry, while others have "afk: false".

I believe then the player never went AFK so the value never got created thus no necessity to change it to false.
Yet he got kicked for AFK over 240 seconds.

commented

I have tried to reproduce this using the steps you provided and I do not seem to get kicked on join.

commented

I don't know that it necessarily means anything if they have afk: false vs not being present. I think the former may be if someone manually toggles their afk to false using /afk (although I may be wrong). Does this happen often for you? If you are able to reproduce it consistently, we should be able to as well, given the same setup.

commented

Users don't have permission for /afk, it happened 4 times in the last 2 days.
Just happened again

commented

OK, good to take note of that. Then this should be reproducible without commands.

commented

Maybe, although if that's the issue then it probably won't be happening to the same player twice.

commented

In fact, it never happened to the same player twice (yet)

commented

I was thinking what could have changed in a couple of days and I figured out we, in Italy, have moved to clock to CEST the 29 March and I haven't restarted the machine since.
Might it be related?

commented

It shouldn't affect this - as far as I can recall we use a timestamp which is independent of time zones.

This issue has been reported before but I don't think we were able to reproduce it back then either.