Ashita keeps asking me for my username and password

[AlexandreCA]

I affirm:

• I understand that if I do not agree to the following points by completing the checkboxes my issue will be ignored.
• I have read and understood the Contributing Guide and the Code of Conduct.
• I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated.

OS / platform the server is running (if known)

Ubuntu

Branch affected by issue

base

Steps to reproduce

Nothing special to do. Since 3 server updates. Ashita keeps asking me for my username and password. If I update the database by doing an express update. This fixes the problem temporarily.

[github-actions]

✨ Thanks for the report! ✨

This is a friendly automated reminder that the maintainers won't look at your report until you've properly completed all of the checkboxes in the pre-filled template.

[WinterSolstice8]

You need to use xiloader from here. the builtin xiloader from Ashita doesn't support the TLS connection yet
https://github.com/LandSandBoat/xiloader/releases

Edit: I see you are actually using the right one, I made an assumption based on the title, sorry

[WinterSolstice8]

I don't see why updating the DB could fix your problem, are there any errors in xi_connect?

[AlexandreCA]

Exactly none. I came across this fix unexpectedly. I don't know why it does this. The guy who calls himself General on the Discord would have heard/seen this problem from someone else. Not knowing where it could come from or how to cause it, I unfortunately can't say more.

[FFXILevelDown]

This is General, We ran into this issue yesterday where I had to repeatedly update someone's password in sql. Once I set the password in sql, he could log in, if we tried to reset the password thru Ashita, it would register the change but would state it is an invalid login / password and I would have to reset it in sql again. Work has had me tied up so I haven't looked into the issue yet past experiencing the issue. Since I haven't had time to look into it to provide my own data, I suggested he open an issue with his findings.

[WinterSolstice8]

I have a fix that prevents password changing not working. Thanks for the tip. I don't know if this solves OPs issue though.

[AlexandreCA]

I am currently applying the update. I will follow up in a few days to say whether or not things have been fixed or not.

EDIT: I'm starting to see things more clearly. After a restart of the VM, the problem is resolved only for a while. Like, 24 hours later, the problem comes back.

[StabbyCutyou]

I'm not sure if this is the same problem, but I just ran into a similar issue with a fresh private server where, after some amount of uptime (12+ hours), it wasn't accepting my username/password through xiloader. I just came here to see if anyone else had reported db connection management issues with xi_connect.

I noticed in the logs I was getting errors such as "[connect][error] (conn=1326) Server has gone away (operator():183)"

I checked mariadb, and it was up and healthy (so it seemed), but noticed in their logs I had seen a lot of aborted connections with multiple errors like:

"Aborted connection 107 to db: 'XXX' user: 'XXX' host: 'XXX' (Got an error reading communication packets)"

Then finally, I saw one error with:

"Aborted connection 1326 to db: 'XXX' user: 'XXX' host: 'XXX' (Got timeout reading communication packets)"

This implied to me that xi_connect was potentially keeping a bad connection held somewhere. I restarted xi_connect, and the problem went away. I'm wondering if there is something with xi_connect where it does not know to repair the connection on error.

Important to note - I did not restart any of the other processes, including map, so I assume they must be handling connections differently.

I'm running the code as of commit 667027d, on ubuntu 24.04, and my app/db servers are distinct hardware (so not running the all-in-one local setup).

[WinterSolstice8]

Interesting. Do you ever put that machine into sleep mode?

[StabbyCutyou]

It might have gone to sleep, I'd have to look, but monitorix would imply that it had been running the whole night without any interruption, i can look more into it though. It's totally possible the db server went to sleep or there was a network fart or something, but it's also entirely possible that if xi_connect was running for 12+ hours, depending on how the connection read timeouts are configured, it literally did just timeout (although i'd assume i'd get a different error, but, i only spent 5 seconds looking before giving it a process-roll and then moving on). Also, my ssh connections to both my app and db server never severed - so i'd assume neither went to sleep.

Alexandres problem seems to be that connect is trying to start up when something else (prior instance of connect?) is already bound to that port, just by guessing at that error - probably a "ps aux | grep connect" might reveal something there.

I can make a distinct issue for the db connection handling issue though as it sounds different from what folks are experiencing here.

[cocosolos]

I've been testing some unrelated stuff and have possibly run into this issue.

[12/14/24 05:31:12:257][connect][error] view_session: Account 1000 has incorrect client version: got 302409xx_x, expected 302410xx_x (view_session::read_func:311)
[12/14/24 05:31:15:778][connect][info] data_session: zoneid:(174), zoneip:(127.0.0.1), zoneport:(54230) for char:(1) (data_session::read_func:302)
[12/14/24 05:31:15:846][connect][info] data_session: client 127.0.0.1 finished work with lobbyview (data_session::read_func:463)
[12/14/24 05:49:03:793][connect][error] view_session: Account 1000 has incorrect client version: got 302409xx_x, expected 302410xx_x (view_session::read_func:311)
[12/14/24 05:49:08:725][connect][info] data_session: zoneid:(174), zoneip:(127.0.0.1), zoneport:(54230) for char:(1) (data_session::read_func:302)
[12/14/24 05:49:08:791][connect][info] data_session: client 127.0.0.1 finished work with lobbyview (data_session::read_func:463)
[12/14/24 06:54:04:999][connect][error] view_session: Account 1000 has incorrect client version: got 302409xx_x, expected 302410xx_x (view_session::read_func:311)
[12/15/24 01:39:28:849][connect][error] Query Failed: SELECT accid FROM chars WHERE charid = 1 AND charname = 'Test' LIMIT 1 (db::queryStr::<lambda_1>::operator ():182)
[12/15/24 01:39:28:849][connect][error] (conn=5798) Server has gone away (db::queryStr::<lambda_1>::operator ():183)
[12/15/24 01:39:28:849][connect][error] Account ID 1000 tried to select a character id with a mismatched character name. (view_session::read_func:69)
[12/15/24 01:39:44:024][connect][error] view_session: Account 1000 has incorrect client version: got 302409xx_x, expected 302410xx_x (view_session::read_func:311)
[12/15/24 01:39:44:028][connect][error] The file handle supplied is not valid. (handler_session::do_write::<lambda_1>::operator ():89)
[12/15/24 14:08:00:891][connect][error] Query Failed: SELECT accounts.password FROM accounts WHERE accounts.login = 'test' (db::queryStr::<lambda_1>::operator ():182)
[12/15/24 14:08:00:891][connect][error] (conn=5798) Server has gone away (db::queryStr::<lambda_1>::operator ():183)
[12/15/24 14:08:00:891][connect][error] Query Failed: SELECT PASSWORD('pass') (db::queryStr::<lambda_1>::operator ():182)
[12/15/24 14:08:00:891][connect][error] (conn=5798) Server has gone away (db::queryStr::<lambda_1>::operator ():183)
[12/15/24 14:08:00:891][connect][error] Query Failed: SELECT accounts.id, accounts.status FROM accounts WHERE accounts.login = 'test' (db::queryStr::<lambda_1>::operator ():182)
[12/15/24 14:08:00:891][connect][error] (conn=5798) Server has gone away (db::queryStr::<lambda_1>::operator ():183)

Note the password ('pass' in this case) is being printed to the log.

I'm pretty frequently closing and recompiling the map server, which kicks me back to the login screen and I just reselect my character and login. If I leave my client sitting on the character select screen (or POL error message when getting DC'd) then come back later and start the server, I get this issue. No sleep mode, MariaDB issues, etc.

[WinterSolstice8]

Hmm. I'm not seeing the pinging the db heartbeat I expect. Maybe it broke (or wasn't implemented?) will take a look when I get home

[cocosolos]

Interestingly, I'm not experiencing this issue with my Linux server, though the map servers are up the whole time there.

[StabbyCutyou]

Those look similar to my errors.

Was wondering if the db had closed the connection and then the connect process wasn't thinking to check/repair (alluding to the lack of ping/hb that Winter mentions)

[AlexandreCA]

It might have gone to sleep, I'd have to look, but monitorix would imply that it had been running the whole night without any interruption, i can look more into it though. It's totally possible the db server went to sleep or there was a network fart or something, but it's also entirely possible that if xi_connect was running for 12+ hours, depending on how the connection read timeouts are configured, it literally did just timeout (although i'd assume i'd get a different error, but, i only spent 5 seconds looking before giving it a process-roll and then moving on). Also, my ssh connections to both my app and db server never severed - so i'd assume neither went to sleep.

Alexandres problem seems to be that connect is trying to start up when something else (prior instance of connect?) is already bound to that port, just by guessing at that error - probably a "ps aux | grep connect" might reveal something there.

I can make a distinct issue for the db connection handling issue though as it sounds different from what folks are experiencing here.

I will try this command once I get home but the problem you describe is exactly what I'm experiencing.

EDIT:

[StabbyCutyou]

@AlexandreCA apologies, I might have been a bit unclear - The screenshot you posted indicated that something running on your system already had bound to the port xi_connect is configured to use. My theory was that you could see if you already had an older process for xi_connect up and running.

So if you keep getting that error, it's possible your existing process is still up and needs to be terminated or killed to then bring up the fresh copy from your screenshot. That would potentially be the first line in the screenshot you posted.

You can also see which process is listening on which port by running either:
sudo lsof -nP -iTCP -sTCP:LISTEN
or
sudo netstat -ntlp

But neither of these will "fix" your problem, just trying to guide you to figuring out which process is already listening on the default port for xi_connect. (Also worth nothing in either of those two commands, you'll likely see xi_connect show up a few times as it seems to listen on more than 1 port - that appears to be normal)

It's probably worth looking into creating service files to manage running them so you don't need to manage it yourself. The guide in the wiki on managing your server has examples, although it's pretty straight forward to roll your own if you're familiar with them.

[WinterSolstice8]

It looks like xi_connect is missing a heartbeat to the sql server which xi_map doesn't have. World doesn't need it because map pings world occasionally and it hits the DB so it has a heartbeat of it's own in effect

I also concur that I dont see this issue on linux, i will see about making an update to xi_connect to add this sql heartbeat/ping

[StabbyCutyou]

I am definitely seeing it on Linux fwiw (Ubuntu 24.04), it happened again last night. If there is anything specific I can monitor for that would help, let me know!

…

On Mon, Dec 16, 2024, 13:21 WinterSolstice8 ***@***.***> wrote: It looks like xi_connect is missing a heartbeat to the sql server which xi_map doesn't have. World doesn't need it because map pings world occasionally and it hits the DB so it has a heartbeat of it's own in effect I also concur that I dont see this issue on linux, i will see about making an update to xi_connect to add this sql heartbeat/ping — Reply to this email directly, view it on GitHub <#6518 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALVGKQB7K3F4SKEBYLQAH32F4K33AVCNFSM6AAAAABTQUITNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBWGMZTIMZUHE> . You are receiving this because you commented.Message ID: ***@***.***>

[cocosolos]

Oh, yeah, actually I'm getting it on Debian as well. IDK what I was looking at before but I was mistaken.

[WinterSolstice8]

I made a PR that might fix it. Apparently the sql ping was being done in the task manager which wasn't hooked up at all in xi_connect. I suppose that might be a memory leak fix too...?

[StabbyCutyou]

Link to PR for the curious #6564

[zach2good]

I'm going to merge this PR in a little while: #6568

It looks like the underlying library we use for handling SQL connections doesn't actually reconnect() like it should if a connection is invalid, so I'm doing it manually. Initial results look promising but would very much like to hear if this helps. (This entirely removes the need for the heartbeat task to exist)

[StabbyCutyou]

I think at this point this issue might be considered resolved with the latest changes to the db connection logic - I haven't seen this come back in days now.

[AlexandreCA]

having hardware problems with my server, I cannot personally confirm if the problem is resolved in my case but if others no longer encounter problems, it is certainly resolved, indeed