PDA

View Full Version : server move and zone not starting


jdoran
01-29-2016, 09:01 PM
Hello again. Things have been really busy, and I've only been able to get back to eqemu stuff this week.

I've been running a server on my home linux box, but decided it was time to move into my lab with a better network connection. That's not important, but it explains why I'm doing a reinstall.

The new server is built from git, PEQ database from August installed.
Clients are able to login and create characters, but cannot enter the world. There are no zone servers.

Eqlaunch is running, and isn't logging a thing.

I manually fired up zone, and it exits without any error. I ran it under gdb and just saw an exit with status 1. So no crash.


[Zone Server] Loading server configuration..
[Zone Server] Connecting to MySQL...
[Zone Server] CURRENT_VERSION: 1.1.3
[Zone Server] Mapping Incoming Opcodes
[Zone Server] Loading Variables
[Zone Server] Loading zone names
[Zone Server] Loading items
[Zone Server] Loading npc faction lists
[Inferior 1 (process 62319) exited with code 01]


I'm at a loss right now, and figure that someone else might have an idea before I come up with anything. I would sure appreciate suggestions on what I've missed.

This is running under Fedora 20.

Shin Noir
01-29-2016, 10:13 PM
if zone/world is up, char can get to char select, but can't connect to zone,
likely port problem (typically firewall settings too secure, i'd open things up TEMPORARILY and see if it magically fixes things)

jdoran
01-30-2016, 12:30 AM
Stopped firewall but didn't change anything. The zone process will not stick around. Normally zone just waits for a connection, but it is exiting.

I am current on SQL I believe.

Uleat
01-30-2016, 02:50 PM
https://github.com/EQEmu/Server/blob/master/zone/net.cpp#L261


Looking at the process, the message is pushed before the action.

If the action fails, there is another message that reports the failure and aborts the process.


Since you're not getting the "Loading loot tables" message, I would look for a failure in the database.LoadNPCFactionLists(hotfix_name) call.

jdoran
01-30-2016, 06:40 PM
Thanks will look into it. When I get a moment figure I will set a breakpoint in exit and grab the stack trace.

Uleat
01-30-2016, 07:23 PM
For ref: https://github.com/EQEmu/Server/blob/master/common/shareddb.cpp#L1213


Looks like you should be getting 3 messages on a failure:

Log.Out(Logs::General, Logs::Zone_Server, "Loading npc faction lists");
Log.Out(Logs::General, Logs::Error, "Error Loading npc factions: %s", ex.what());
Log.Out(Logs::General, Logs::Error, "Loading npcs faction lists FAILED!");


Pretty sure General/Error should be defaulted to console and file outputs.

If you're not getting those..it may be in the assignment of nullptr to the unique_ptrs in the pre-try/catch code..or, for some reason, it's crashing harder that the error
handler can handle...


Doing some minor searches on the unique_ptr hypothesis..not catching too many direct results.


EDIT: Try deleting all of the files in your 'shared' directory and re-run shared_memory.exe to see if that helps.

Does this error occur every time?

jdoran
02-01-2016, 03:06 AM
Thanks for that last suggestion. Remaking shared memory will allow zone to stay running. I see activity from the world server (up to "Processing connection") but there are no zone processes. I recall in the past that there would be around 5 zone processes created at server launch. Eqlaunch says nothing. It is sitting the the main loop with an empty zone list.

Trying to enter the world results in "that zone isn't available".

Manually launching zone used to work, so I fired up one. There was only one line of output when a character tried to enter the world:

[Zone Server] Time Broadcast Packet: EQTime [01:43 am]

It just sat there and eventually timed out. Stopping the firewall had no effect.


Oh, and yes the error occurs every time.

The last thing logged by the world server is a message saying that I passed the banned ip check. Processing connection.


Oh and one more random piece of info: I suspect some sort of database issue. I'm using the PEQ database 8/2015, and I manually added all sql in the utils/sql/git/required with a later date. But I'm not seeing logsys categories which was from 1/2015.

Uleat
02-01-2016, 01:55 PM
The eqemu_update.pl script checks for all versioned sql updates.


Even though EQEmu and PEQ are coops in this venture..there's no guarantee that either's implementation will be 100% of what the other's is - Bots and Mercs, for example.

jdoran
02-01-2016, 02:53 PM
That makes sense. I suppose the PEQ database did not roll in the
schema changes, and I manually sourced sql which was more recent.

Which database should I be using? I have so many notes from the last time that I did this that they are not helping.

I'm not looking for anything fancy, just plain vanilla.

Uleat
02-01-2016, 03:25 PM
The 'PEQ database 8/2015' should be fine (I think... There was an anomalous dump out there at one point..but, I believe it was older than this one.)


I know that Akkadius has gone to pain-staking lengths to ensure that the update process works and is as simple as humanly possible :)

jdoran
02-01-2016, 04:27 PM
Well that was the version I was using. I think I'll reload all of the tables and see if that helps. There was that shared memory issue before, and I'm not entirely sure that it wouldn't impact the database load. Worst case it leaves me where I am.

I also want to say thanks for taking the time to discuss this. I really appreciate not being left to my own devices. Stepping through the zone loader in the debugger would prob have been my next step.

jdoran
02-29-2016, 11:30 AM
I'm not seeing 2015_01_15_logsys_categories_table.sql's contents rolled into PEQ Beta 2015-08-12-02_01.

I assumed that I did not need to go back and load the older required files.

eqemu_update.pl does not pull in the logsys categories when I manually select option 3 (DB Schema).

I don't have a lot of time to work on this right now, but I do return to it now and then. I never had database issues in the past.