Logging Q

[jdoran]

I'm running a fresh "git pull"/make clean under Linux.

I've been busy doing other things, and haven't had time to keep up with EQEMu, so please forgive me if I am missing something obvious.

The Wiki directs us to Google Drive for the current database
http://wiki.eqemulator.org/p?EQEmu_on_Debian_7_Virtualbox

The latest there is peqbeta_2015_08-12-02_01.

None of the files contain any mention of logsys, the Wiki says that settings are loaded from logsys_categories

(http://wiki.eqemulator.org/p?Logging_System_Overhaul)

I know that sometimes things get out of sync, but I am concerned that something might be missing.

OK, I do not see a logsys_categories table, but I do see that it was part of 2015_01_15_logsys_categories_table.sql which was required. I thought that database patching was automatic now. No such table exists in my database, but I can enter the world and log stuff (using the default settings).

Now I could manually source this, but I would like to check with folks first to make sure there isn't a larger problem. There are no local changes that I require, so the database can be wiped. But I need to make sure I understand how the patching works before I redo what I did earlier.

[Akkadius]

Linux setup really needs some attention. Windows is purely automated, I have it on my list to make Linux just as easy.

That is not the best source for the database and I'm not on my PC to give you the latest, but the automatic database versioning system is supposed to keep all schema updates up to date yes.

[jdoran]

Thanks. There is a newer database then, I assume.

Is there a way to force a database update? I have tried to change db_version's version from 1000 to 0 and restart everything. That didn't do anything. Make didn't do anything.

But if I have an old database, then I won't worry too much. I have other things to look at.

Zone is crashing on me (this is a stock git pull I believe -- stash then pull, make clean, make) Funny thing is that it won't crash under GDB. I unlimited the core dump size and have a real old-fashioned core dump. Something to do with bots. Time to research what is going on in that area.

[Akkadius]

I think a few other people were complaining of zone crashes with bots enabled, I'm not sure where they are in the process of troubleshooting as there are so many people that really care about them.

Have you been running option 3 on the auto db updater ?

[Uleat]

One of the things that needs to be done before installing/updating bots is to ensure that you have bot-enabled binaries in your server directory.

The update script will not invoke the update procedure if they are not there.

As well, you will need to manually run the script since we don't trigger updating when the script is called from world.exe.

[jdoran]

Well I have the following in my CMakeLists:
OPTION(EQEMU_ENABLE_BOTS "Enable Bots" ON)
The CMakeCache shows ENABLE_BOTS to be true.

Makefiles were regenerated, make clean followed by make was done. The update script (utils/scripts/eqemu_update.pl) still complains that binaries were not built with bots enabled.

I have not seen the auto-db updater for a very long time. I was looking for a way to enable it, but I guess I can just manually run it like I did for bots.

The crash was a bad "spells" pointer in BCSpells::Load. Until I can get the required DB updates done, I am not pursuing this. It might not be a real problem.

EDIT: Option 3 brought down a new manifest, and restarting the server loaded a new eqemu_update.pl -- That's it. No difference otherwise.

[Uleat]

Changing (C)Make isn't enough. You will need to recompile the binaries with gcc, or whatever program you linux guys use :P

The script should receive this value for properly complied binaries: https://github.com/EQEmu/Server/blob/master/common/version.h#L35

Otherwise, it returns '0'


Are you pressing '3' twice? The first time queues needed updates, and the second actually applies them.

[jdoran]

Um.... make does recompile everything. "make clean followed by make was done"
(Of course you Windows guys wouldn't know that... I forget these things)

[jdoran]

Oh, and yes I did hit 3 several times. And I restarted "world". Oddly enough the binary revision / local: ( / 1000). The database is reported as up to date.

[Akkadius]

Oh, and yes I did hit 3 several times. And I restarted "world". Oddly enough the binary revision / local: ( / 1000). The database is reported as up to date.

That means you're not getting a binary database version from world, the script runs world from command line, make sure you are running eqemu_update.pl from the context of the server directory with the world binary in it as well with proper permissions.

[jdoran]

Grr. I have my binaries in another directory. Guess I need to shuffle things around.

Guess I need to party like its 9097

EDIT: Back to the crash issue. I don't think it is related to my file paths. If I run zone under gdb, zone runs just fine. I can enter the world and all is well. If there was any problem with paths, I cannot believe that I could enter the world no matter whether gdb is running.

I saw something like this MANY years ago. I struggle to remember it. Hmm. Doesn't GDB set up some sort of chunk of memory where the data section is loaded and fill it with zeros? I think it did something to protect the code section against a program shotgunning memory.

[jdoran]

Found it. Shared memory needed to be rebuilt. I was going a bit nuts trying to figure out where "spells" was initialized.

I thought that eqlaunch actually launched the zones. But I'm not seeing any zone processes launched. I can manually launch them in th background and everything works ok.

[Akkadius]

Found it. Shared memory needed to be rebuilt. I was going a bit nuts trying to figure out where "spells" was initialized.

I thought that eqlaunch actually launched the zones. But I'm not seeing any zone processes launched. I can manually launch them in th background and everything works ok.

It does launch the zones, but you are probably running into a context issue again where the launcher also needs to run within the context of the server directory.

[jdoran]

You may be right. There was no context issue before (just to be clear). But this is different.

It would help if I had more debugging. I put a 3 in the appropriate fields for Launcher in logsys_categories. I'm not seeing anything. I added Log calls to eqlaunch similar to that for the loginserver. But nothing (nor do I see anything obviously corresponding to the Login_Server in the logsys_categories table.

In a pinch I guess I could live with just firing off 5 or 6 zones in the background.

[jdoran]

I'm not seeing anything sent to Logs::Launcher. I can send things to Logs::Login_Server

The ZoneLaunch constructor is never ran.

WorldServer OnConnected runs approx 1Hz

After everything starts up, I login and try to enter a zone. There are no "zone" processes, so that request fails. Nothing logged from the launcher :-(

Let me add: Manually starting zones works just fine. Players are able to zone in and change zones just fine. The launcher never does anything other than run OnConnected at 1Hz.

I'd feel a lot better if this wasn't happening, yet I do not see any indication that the launcher is *trying* to do anything. In particular no packets come into the worldserver.