suppressing db_update on Linux (Debian 7)
 

I mentioned this on IRC, but I rarely get to go on IRC and due to time differences had to go before I got a reply. And also, it's worth having any answer documented for others who may have the same issue.

Currently what is happening is that even after I run ./world manually and update the db, the script continues to run when I use my normal startup script (which runs ./world > /dev/null 2>&1 &)

I tried this: http://wiki.eqemulator.org/i?M=Pastebin&Paste=xRJzfmq2
by uncommenting
and conmmenting out as I'm guessing ./persist_world is a custom script I don't have, however this still runs the .pl file, which ends up using 100% CPU and spamming logs.

What I would like to do is adapt this:-
http://wiki.eqemulator.org/i?M=Pastebin&Paste=tiC4AqP8

Such that the db_update.pl file is either not called, or is automatically passed the "0" to exit.

One thing I did notice- it did seem to re-download the script every time- so perhaps I have a file system permission issue?

99% of the time I run world it would not be after recompiling/updating the source, so I'm quite happy to have to "opt in".

The only bump is in Linux and changing startup scripts.

It is downloading every time because I set it that way temporarily because the first version of the script didn't support updates of itself. In the future the script can detect if there is a newer version of the upgrade script available.

You only have issues of you have a DB update required. And if you update to my changes mentioned in the thread you should be fine as well.

I've made a promise that if there are issues with this that I would address any of them and I have

The related oddity with Linux I've found:

If you update the database outside of the updater (like when I update the source and the db updates at the same time when I need), the updater is out of sync with your already applied changes and will remain in the loop. The workaround I currently use is to manually run the updater through the terminal before I let my auto script run the server.

It's a really cool feature, it's just doing something odd on my setup which I am sure is specific to me, and I want to resolve it.

I'll double check that my local database version is higher than the binary version when I get home. IIRC it was 10000 which I thought was a suspiciously round number, so perhaps it was the db version update failed somehow.

It did run a few of the scripts and I must admit I didn't really search through for failures since my server was last updated pretty much just before the new feature was added. In fact, the version may well have been 1000 which may well be the default the first time you run?

It will start at the lowest number in the manifest and increase as changes are applied. It should be at 9059 currently.

Yep, I saw the binary version was that. Maybe I just need to re run the script in case my Mysql instance farted or something ;)

Re-ran it, and it worked.