failed upgrade from 2.1.0-1 to 2.1.1

[mbarbosa]

Hello,

I was informed that the "new version" of OJS was available that it would "good" to do the upgrade. Yay.

After reading the UPGRADE and INSTALL files, I figured it would be a
"piece of cake". Thank god for the cron job that backs up everything
every few days.

Anyway... here is what I did...

1. tried CLI to upgrade. For some reason it does not work...
even though if I type php at the prompt, I get into some
kind of intereactive mode with the php interpreter.

2. Tried the patch thing... I think it worked... but then when
upgrading the database, after a while, it failed claiming no
connection to the ojs database with ojs@localhost or something.

Time for more drastic measures...

3. tried the full source install (after all, that is the way I installed
the previous version a few months ago... or someone claims
it was me), brought the conf.inc.php file, the files directory,
changed the permissions to some files as directed in the
INSTALL file... changed the Installed from On to Off... and...
when upgrading the database, failed with the same error... hrmmm

so... I figured... do not panic... it is a weekend... not many people
will access the site... there is time to figure this out... lets roll back
to the previous version while nobody notices anything... ups...
the system complained about some fields not existing somewhere...
I figured that the update did something to the database... hrmmm

No problem... we have a backup... empty the database... reload
from mysqldumped file... no problem... try system... hrmmm...
still some problem with fiields or something... and I did not backup
the directory... grrrrr... ok... look for previous version source file...
decompress, bring over config.inc.php, files directory, change
permissions... try again... working! cool...

So... could anyone tell me...

1. what can I do to try to track the problem somewhere?
enable verbosity when attempting DB upgrade?
I know now the source install tries to work, but somewhere
it fails with the connection to ojs database with ojs@localhost...

2. Anything else I should look for?
Maybe some obscure security setting that seemed like a good
idea while installing its coming back to bite my behind. :S

Thanks in advance.

Marco

[asmecher]

Hi Marco,

I've never heard of a connection failure message appearing partway through the upgrade... Usually the upgrade process is very smooth, as advertised. I'd suggest enabling MySQL logging, trying the upgrade again (maybe not on a live deployment), and sending me the log or part of the log that shows where the error occurred. I'll see if I can determine what is happening. Have you altered OJS in any way?

It sounds like the first step of upgrading -- renewing the code -- is working fine, but with both upgrade techniques (entire source code and patch) the second stage isn't working.

Regards,
Alec Smecher
Open Journal Systems Team

[mbarbosa]

Hello Alec,

I just love it when the support personnel go like "gee, we never
encountered that before" Thanks for the reply...

I will schedule another upgrade attempt for this weekend
and my todo-list already has a few things in it...

1. enable MySQL Logging, as you suggested...
2. Mirroring the database so I do not work with the "working one"
3. Mirroring the OJS home dir, so I do not work with the "live one"
4. copying all the article files... (has to be done manually... too big)

if you think there is anything else I should enable, let me know...
so I can look it up in advance (I am not a genious ) I may
even postpone the upgrade for next weekend... since the priority
right now seems to be doing maintenance to other user's PCs...

Do you think I should try to enable to verbosity thing on PHP?
also... the limits for apache time out and... php I had moved to 3000...
should I increase them for the test?

thanks again.

[asmecher]

Hi Marco,

Yes, I'd suggest disabling the time limits for the purposes of the test. If you have SSH access to the server, I'd suggest using the command-line tool when upgrading large journals, as browsers can time-out even with time limits disabled.

Regards,
Alec Smecher
Open Journal Systems Team

[mbarbosa]

Hello Alec,

I checked the mysql docs, it seems the mysql database does
some sort of error logging... but I could not find any useful
messages in there. It only says when the server started.

anyway, I did a backup of the ojs dir, with the files dir, the
public dir, etc. Then I ungzipped the source for the 2.1.1. ojs
and copied the config.inc.php file, made sure the dirs had the
right permissions (cache, files... ), made a mirror of the database
with a different name, different user, changed the config.inc.php
file acordingly...

then I logged into this new install of the ojs system and it worked...
so then I moved the 2.1.1 to where this new ojs was located...
and changed the "installed" from on, to off... proceeded with the
database upgrade... and... it worked! no error... or anything...

??????

so, I went back to my live install of the 2.1.0-1 ojs system...
ungzipped the 2.1.1 src at the same level (same as 2 weeks ago)
copied files dir, config.inc.php (made sure permissiosn were ok)
and tried it again...

and again :

DB Error: Access denied for user 'ojs'@'localhost' to database 'ojs'

I go back to the upgrade link... click on it again... and it says that
there is duplicate something in the database...

so I recover the ojs database from backup...

check the /var/lib/mysql/log.err and... still unchanged...

hrmmm... maybe I am overlooking something...
the only difference was that the ojs was somewhere like...
http://www.cienciasmarinas.com/ojs211test when it worked...
and now it is where it was before... http://www.cienciasmarinas.com

any ideas?

[asmecher]

Hi Marco,

Are you sure that the new config.inc.php is correctly configured with your database connection parameters before you attempt the upgrade? If so, I'm still drawing a blank. I'd suggest configuring MySQL to temporarily enable verbose logging (i.e. all transactions), attempt the upgrade, and send me the resulting log file.

Regards,
Alec Smecher
Open Journal Systems Team

[mbarbosa]

Hello Alec,

Yes... parameters for database were fine!
I could log into the system and move around, view
the articles, etc... for both of the systems...
then I upgraded the copy (that I made with an old
back up of the database) and it worked fine...
but in the live one... it crashed... it seems I trashed the
database some how but it is now solved... was only
down for a couple of days while we got back on track

In any case... it seems that I am now an expert at
putting two instances of the OJS in the same server... *grin*
I just found out how to enable ultra-verbose logging in
the mysql database... though the manual is now very clear...
(out of frustation I just put the log=file line in all the
sectiosn... mysqld_safe, mysql.server and mysqld, because
I only had it in mysqld_safe before and it did not work,
though it was specified in the manual and I did not know
what was wrong...)

well, I will try another upgrade this weekend... but this
time I will use a fresh backup, will upgrade the mirror,
and when it works, I will put the upgraded system back
online... for some reason I am sure it will work on the
mirror, but not sure why it will not on the "live system".
Now that I figured out how to enable the log, maybe I
will try to upgrade the "live system" just to look at the
errors, out of curiosity... thanks for the feedback.

[asmecher]

Hi Marco,

One strange thing I have seen happen once or twice is that PHP's MySQL module sometimes confuses itself with persistent connections. This can cause OJS to try to use the wrong database connection occasionally. You can disable this feature for a slight performance cost in config.inc.php (turn the "persistent" option off).

Regards,
Alec Smecher
Open Journal Systems Team

[mbarbosa]

Hello!

Finally, I was able to do the upgrade. I did as the UPGRADE doc
suggests. Instead of upgrading the "live system" I made
a copy of everything (with a fresh mysqldump backup, instead
of an old one... like I did before) changed the config file...
and... I noticed the "public" directory was not writable...

I tried to figure out why... I had renamed it a while ago...
to something like publicold, and when I changed the installed
variable from on to off, it said it was not writable. In the
previous tries I did not scroll down to check the directories...
I checked the permissions, and they were fine... then I thought
of renaming the directory to public again, and it changed...
for some strange reason... (I double checked the config.inc.php
file, the name I had was correct all the time... when it was
named publicold, public, and I even tried with random names
which matched the actual directory name... but it did not
recognize the directory with anything else than public)

Anyway... then I continued with the upgrade, from the website...
it worked... as I expected...

Then I went back to the "live system" and after backing everything
up, I tried again, with the public directory renamed to public, and
it worked again! so maybe there is something wrong somewhere
that keeps the system from recognizing a public directory with
a different name... I was too lazy to try again with a public
directory with the publicold name... but I think that was the
only thing different. I might try it during the week just out
of curiosity, to see if the public directory name change makes
a difference.

anyway, thanks for the help. I was baffled.