Please show a log of your make upgrade-database step
- 3.9.8
- 4.0.1
That’s definitely skipping steps.
It should read:
What does ls -l etc/upgrade/ in the directory where you’re running make
upgrade-database show?
ls -l etc/upgrade/4.0.0rc*/ would also be interesting.
-kevin
Thanks again Kevin,
OK - I’ll roll back and run the upgrade again from 3.8.4.
Do you have logs of the upgrade?
How do I enable/check logging for that?
Paul O’Rorke
Tracker Software Products
paul@tracker-software.com mailto:paul.ororke@tracker-software.comOn 8/2/2013 7:48 AM, Kevin Falcone wrote:
On Thu, Aug 01, 2013 at 12:40:44PM -0700, Paul O’Rorke wrote:
I don't remember skipping any errors during make upgrade-database. Here are the table descriptions you asked for. As you can see the Classes, Topics, Articles tables do exist.Do you have logs of the upgrade?
Hopefully you will be able to tell what I need to do to my DB to fix this...Really- you need to do another test upgrade and figure out what fails.
While I can tell you how to fix Users, I wouldn’t trust that other
parts of the upgrade didn’t fail.
Please show a log of your make upgrade-database step
- 3.9.8
- 4.0.1
That’s definitely skipping steps.
It should read:
- 3.9.8
- 4.0.0rc2
- 4.0.0rc4
- 4.0.0rc7
- 4.0.1
What does ls -l etc/upgrade/ in the directory where you’re running make
upgrade-database show?
~/src/rt-4.0.16$ ls -al etc/upgrade/
…
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.8.8
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.8.9
-rwxr-xr-- 1 root root 3169 Jul 30 14:37 3.8-branded-queues-extension
-rwxrwxr-x 1 iqbala iqbala 3179 Jul 29 19:02
3.8-branded-queues-extension.in
-rwxr-xr-- 1 root root 3203 Jul 30 14:37 3.8-ical-extension
-rw-rw-r-- 1 iqbala iqbala 3213 Jul 29 19:02 3.8-ical-extension.in
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.9.1
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.9.2
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.9.3
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.9.5
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.9.6
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.9.7
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 3.9.8
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.0rc2
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.0rc4
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.0rc7
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.1
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.12
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.13
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.3
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.4
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.6
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 4.0.9
…
ls -l etc/upgrade/4.0.0rc*/ would also be interesting.
~/src/rt-4.0.16$ ls -al etc/upgrade/4.0.0rc*
etc/upgrade/4.0.0rc2:
total 12
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 .
drwxrwxr-x 43 iqbala iqbala 4096 Jul 30 17:31 …
-rw-rw-r-- 1 iqbala iqbala 193 Jul 29 19:02 schema.mysql
etc/upgrade/4.0.0rc4:
total 20
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 .
drwxrwxr-x 43 iqbala iqbala 4096 Jul 30 17:31 …
-rw-rw-r-- 1 iqbala iqbala 48 Jul 29 19:02 schema.mysql
-rw-rw-r-- 1 iqbala iqbala 49 Jul 29 19:02 schema.Oracle
-rw-rw-r-- 1 iqbala iqbala 52 Jul 29 19:02 schema.Pg
etc/upgrade/4.0.0rc7:
total 12
drwxrwxr-x 2 iqbala iqbala 4096 Jul 29 19:02 .
drwxrwxr-x 43 iqbala iqbala 4096 Jul 30 17:31 …
-rw-rw-r-- 1 iqbala iqbala 630 Jul 29 19:02 content
~/src/rt-4.0.16$ cat etc/upgrade/4.0.0rc2/schema.mysql
DROP TABLE IF EXISTS sessions;
CREATE TABLE sessions (
id char(32) NOT NULL,
a_session LONGBLOB,
LastUpdated TIMESTAMP,
PRIMARY KEY (id)
) ENGINE=InnoDB CHARACTER SET ascii;
I am not sure why it is skipping then. Could it be because of the RTFM
errors? I do not use them and not planning to either.
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Please show a log of your make upgrade-database step
- 3.9.8
- 4.0.1
That’s definitely skipping steps.
It should read:
- 3.9.8
- 4.0.0rc2
- 4.0.0rc4
- 4.0.0rc7
- 4.0.1
Paul and Asif, you’ve helped uncover a regression in RT’s upgrade logic
beginning in 4.0.14. It only affects folks who are upgrading from an RT
3.8.x (or older) install to 4.0.14 or higher. If you’re upgrading from
4.0.0 or higher, you’re unaffected.
4.0.17 will be out shortly to correct this regression. Thanks for your
time spent debugging on the list.
Just a heads up that running the make upgrade-database on an upgrade
from 3.8.4 to 4.0.17 worked flawlessly once I successfully restored the
DB from mysqldump.
Thanks for the help and more importantly thanks for fixing that script.
Paul O’Rorke
Tracker Software Products
paul@tracker-software.com mailto:paul.ororke@tracker-software.comOn 8/2/2013 10:23 AM, Thomas Sibley wrote:
On 08/02/2013 10:04 AM, Kevin Falcone wrote:
On Fri, Aug 02, 2013 at 12:49:47PM -0400, Asif Iqbal wrote:
Please show a log of your make upgrade-database step * 3.9.8 * 4.0.1That’s definitely skipping steps.
It should read:
- 3.9.8
- 4.0.0rc2
- 4.0.0rc4
- 4.0.0rc7
- 4.0.1
Paul and Asif, you’ve helped uncover a regression in RT’s upgrade logic
beginning in 4.0.14. It only affects folks who are upgrading from an RT
3.8.x (or older) install to 4.0.14 or higher. If you’re upgrading from
4.0.0 or higher, you’re unaffected.4.0.17 will be out shortly to correct this regression. Thanks for your
time spent debugging on the list.
Thanks for all the support. I have a shiny new 4.0.17 ticking away
nicely. Very happy.
Paul O’Rorke
Tracker Software Products
paul@tracker-software.com mailto:paul.ororke@tracker-software.com
OK - a little premature.
After running for a few hours I rebooted my new RT and get a database
connect fail. For some reason it’s not trying to use a password in DBI
connect:
Aug 9 00:33:23 rt4 RT: DBI
connect('dbname=rtdb;host=localhost','rtuser',...) failed: Access
denied for user 'rtuser'@'localhost' (using password: NO) at
/usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
The database name, user and password are all correct in RT_SiteConfig.pm
and I can connect using those credentials from a shell on that box and
can access the right database.
Any suggestions why I’m seeing (using password: NO) in my logs? I get
something similar at startup/shutdown.
regards
Paul O’Rorke
Tracker Software Products
paul@tracker-software.com mailto:paul.ororke@tracker-software.comOn 8/8/2013 9:52 PM, Paul O’Rorke wrote:
Thanks for all the support. I have a shiny new 4.0.17 ticking away
nicely. Very happy.Paul O’Rorke
Tracker Software Products
paul@tracker-software.com mailto:paul.ororke@tracker-software.com
When I look at syslog I see the following during startup:
Aug 9 08:28:03 rt4 acpid: starting up with netlink and the input layer
Aug 9 08:28:03 rt4 acpid: 1 rule loaded
Aug 9 08:28:03 rt4 acpid: waiting for events: event logging is off
Aug 9 08:28:04 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t connect
to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:05 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t connect
to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:08 rt4 /usr/sbin/cron[2152]: (CRON) INFO (pidfile fd = 3)
Aug 9 08:28:08 rt4 /usr/sbin/cron[2172]: (CRON) STARTUP (fork ok)
Aug 9 08:28:08 rt4 /usr/sbin/cron[2172]: (CRON) INFO (Running @reboot jobs)
Aug 9 08:28:08 rt4 mysqld_safe: Starting mysqld daemon with databases
from /var/lib/mysql
Aug 9 08:28:08 rt4 mysqld: 130809 8:28:08 [Note] Plugin ‘FEDERATED’ is
disabled.
Aug 9 08:28:08 rt4 mysqld: 130809 8:28:08 InnoDB: The InnoDB memory
heap is disabled
Aug 9 08:28:08 rt4 mysqld: 130809 8:28:08 InnoDB: Mutexes and rw_locks
use GCC atomic builtins
Aug 9 08:28:08 rt4 mysqld: 130809 8:28:08 InnoDB: Compressed tables
use zlib 1.2.7
Aug 9 08:28:08 rt4 mysqld: 130809 8:28:08 InnoDB: Using Linux native AIO
Aug 9 08:28:08 rt4 mysqld: 130809 8:28:08 InnoDB: Initializing buffer
pool, size = 128.0M
Aug 9 08:28:08 rt4 mysqld: 130809 8:28:08 InnoDB: Completed
initialization of buffer pool
Aug 9 08:28:08 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t connect
to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:08 rt4 mysqld: 130809 8:28:08 InnoDB: highest supported
file format is Barracuda.
Aug 9 08:28:08 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t connect
to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:09 rt4 mysqld: 130809 8:28:09 InnoDB: Waiting for the
background threads to start
Aug 9 08:28:10 rt4 mysqld: 130809 8:28:10 InnoDB: 5.5.31 started; log
sequence number 2602152497
Aug 9 08:28:10 rt4 mysqld: 130809 8:28:10 [Note] Server hostname
(bind-address): ‘127.0.0.1’; port: 3306
Aug 9 08:28:10 rt4 mysqld: 130809 8:28:10 [Note] - ‘127.0.0.1’
resolves to ‘127.0.0.1’;
Aug 9 08:28:10 rt4 mysqld: 130809 8:28:10 [Note] Server socket created
on IP: ‘127.0.0.1’.
Aug 9 08:28:10 rt4 mysqld: 130809 8:28:10 [Note] Event Scheduler:
Loaded 0 events
Aug 9 08:28:10 rt4 mysqld: 130809 8:28:10 [Note] /usr/sbin/mysqld:
ready for connections.
Aug 9 08:28:10 rt4 mysqld: Version: ‘5.5.31-0+wheezy1’ socket:
‘/var/run/mysqld/mysqld.sock’ port: 3306 (Debian)
Aug 9 08:28:10 rt4 /etc/mysql/debian-start[2704]: Upgrading MySQL
tables if necessary.
Aug 9 08:28:10 rt4 /etc/mysql/debian-start[2708]:
/usr/bin/mysql_upgrade: the ‘–basedir’ option is always ignored
It almost looks like RT is trying to connect before MySQL is loaded.
Also - I find that the connection intermittently works then fails. One
minute I’m looking at my new RT tickets then on a page refresh I am back
to the RT setup screen because it thinks there is no database configured.
I’m at a loss here and really need to get this new install stable. Any
help is appreciated.
Paul O’Rorke
Tracker Software Products Canada LimitedOn 08/09/2013 12:54 AM, Paul O’Rorke wrote:
OK - a little premature.
After running for a few hours I rebooted my new RT and get a database
connect fail. For some reason it’s not trying to use a password in
DBI connect:Aug 9 00:33:23 rt4 RT: DBI connect('dbname=rtdb;host=localhost','rtuser',...) failed: Access denied for user 'rtuser'@'localhost' (using password: NO) at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105. (/usr/local/share/perl/5.14.2/Carp.pm:102)The database name, user and password are all correct in
RT_SiteConfig.pm and I can connect using those credentials from a
shell on that box and can access the right database.Any suggestions why I’m seeing (using password: NO) in my logs? I
get something similar at startup/shutdown.regards
Paul O’Rorke
Tracker Software Products
paul@tracker-software.com mailto:paul.ororke@tracker-software.comOn 8/8/2013 9:52 PM, Paul O’Rorke wrote:
Thanks for all the support. I have a shiny new 4.0.17 ticking away
nicely. Very happy.Paul O’Rorke
Tracker Software Products
paul@tracker-software.com mailto:paul.ororke@tracker-software.com
A little more information.
If I run through the setup screens that are presented because RT thinks
there is no initialised database I get my new RT with the theme and logo
etc but it flips between that and again going to the login screen. Of
course this overwrites my RT_SiteConfig.pm but I’m at a loss to
understand why this is not persistent. It keeps connecting to MySQL
then not.
Is there anything else I can provide that would help troubleshoot this?
Paul O�Rorke
Tracker Software Products
paul@tracker-software.com mailto:paul.ororke@tracker-software.com
When I look at syslog I see the following during startup:
Aug 9 08:28:04 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t connect
to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:05 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t connect
to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:08 rt4 mysqld_safe: Starting mysqld daemon with databases
from /var/lib/mysql
Just by looking at the log timestamps, your system is pretty clearly set
to start Apache (or whatever is serving RT) before mysql. This isn’t
RT’s fault, but simply the wrong startup ordering for your system. You
should change it so Apache/your webserver depends on mysql being started
first. How to do so depends on your distribution.
Thanks Thomas
Setting Apache to start after mysql seems to have done the trick.From: Thomas Sibley trs@bestpractical.com
Date:
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Migration Prep
When I look at syslog I see the following during startup:
Aug 9 08:28:04 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t connect
to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:05 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t connect
to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:08 rt4 mysqld_safe: Starting mysqld daemon with databases
from /var/lib/mysql
Just by looking at the log timestamps, your system is pretty clearly set
to start Apache (or whatever is serving RT) before mysql. This isn’t
RT’s fault, but simply the wrong startup ordering for your system. You
should change it so Apache/your webserver depends on mysql being started
first. How to do so depends on your distribution.
Similarly at our site: We observed issues (not just RT) when Apache was started before the Postgres server was ready. During certain testing, it might be necessary to manually restart Apache.
Jim-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Thomas Sibley
Sent: Friday, August 09, 2013 3:46 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Migration Prep
On 08/09/2013 06:36 AM, Paul O’Rorke wrote:
When I look at syslog I see the following during startup:
Aug 9 08:28:04 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t
connect to local MySQL server through socket
‘/var/run/mysqld/mysqld.sock’ (2) at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:05 rt4 RT: DBI
connect(‘dbname=rtdb;host=localhost’,‘rtuser’,…) failed: Can’t
connect to local MySQL server through socket
‘/var/run/mysqld/mysqld.sock’ (2) at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 105.
(/usr/local/share/perl/5.14.2/Carp.pm:102)
Aug 9 08:28:08 rt4 mysqld_safe: Starting mysqld daemon with databases
from /var/lib/mysql
Just by looking at the log timestamps, your system is pretty clearly set to start Apache (or whatever is serving RT) before mysql. This isn’t RT’s fault, but simply the wrong startup ordering for your system. You should change it so Apache/your webserver depends on mysql being started first. How to do so depends on your distribution.