I upgraded from rt-1.0.5 to 1.0.6, and now MySQL server won’t start.
Any clues?
TIA
cseward.vcf (341 Bytes)
MySQL is not running on your system - database list could not be
retrieved.
Stephen Hauskins wrote:
cseward.vcf (341 Bytes)
Yes, it’s in /etc/rc.d/init.d
When I cd’d to /etc/rc.d/init.d/ and type ./mysql start, MySQL gives me:
Starting mysql daemon with databases from /var/lib/mysql
But when I check the status of MySQL, it’s not running.
When looking at the httpd error log, I see the following:
[Mon Dec 4 14:40:19 2000][error][Client 192.X.X.X] Premature end of script
headers: /opt/rt/cgi/webrt.cgi
Mysql->connect(database=rt;host=localhost) failed: Access denied for user:
‘rt@localhost’(using password: YES) at /opt/rt/lib/rt/database.pm line 24.
I swear, all I did was un-tar rt and run “make upgrade” 
Stephen Hauskins wrote:
cseward.vcf (341 Bytes)
ps -ef…shows mysql listed 3 times
mysql.sock is in /var/lib/mysql
I ran make fixperms after the first time I couldn’t access webrt.
I’m also getting an ‘Access denied for user root’, not just for rt.
According to the rt readme file, ‘make upgrade’ doesn’t overwrite the user defined
settings.
I appreciate your patience.
Stephen Hauskins wrote:
cseward.vcf (341 Bytes)
It sounds like you may have gotten RT’s mysql password wrong in the
makefile when you upgraded.
-jOn Mon, Dec 04, 2000 at 01:50:29PM -0500, Christopher A. Seward Sr. wrote:
Yes, it’s in /etc/rc.d/init.d
When I cd’d to /etc/rc.d/init.d/ and type ./mysql start, MySQL gives me:
Starting mysql daemon with databases from /var/lib/mysql
But when I check the status of MySQL, it’s not running.When looking at the httpd error log, I see the following:
[Mon Dec 4 14:40:19 2000][error][Client 192.X.X.X] Premature end of script
headers: /opt/rt/cgi/webrt.cgi
Mysql->connect(database=rt;host=localhost) failed: Access denied for user:
‘rt@localhost’(using password: YES) at /opt/rt/lib/rt/database.pm line 24.I swear, all I did was un-tar rt and run “make upgrade”
Stephen Hauskins wrote:
You need to restart MySQL.
Where does the startup script live. usually in /etc/init.d and
called mysql…just start it up by issuing… ./mysql start
–
–MySQL is not running on your system - database list could not be
–retrieved.–
–Stephen Hauskins wrote:
→ Would be strange. Rt should not have anything to do with MySQL.
→
→ What is the error message from MySQL startup.
→
→ –
→ --I upgraded from rt-1.0.5 to 1.0.6, and now MySQL server won’t start.
→ --Any clues?
→ –
→ --TIA
jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
This is scary. I’m imagining tracerouting you and seeing links like “Route
84” and “Route 9, Exit 14”. Obviously, this is illness induced.
–Cana McCoy
You got it Jesse. I feel like an idiot, but now that it’s working…I am a happy
idiot.
Thanks to you both!
Jesse wrote:
cseward.vcf (341 Bytes)
Hi all,
I’m upgrading from rt-3.0.5 on RedHat 9 to 3.4.0rc6 on a new server.
Version info on the new server: Fedora Core 3, Postgres 7.4.6,
Apache 2.0.52, Perl 5.8.5, mod_perl 1.9916.
I’ll describe my problems first and anyone interested in helping
can read on for more details. Everything seems to be OK except
when I click a ticket, its history is blank. Another problem is
when I do a search, not all owners are listed and Nobody is listed
twice. Are these issues due to the problems shown below with the
database updates?
Upgrade steps:
- Dump old database with ‘pg_dumpall -U postgres > rt3-25jan05.bak’
- Restore database on new server with ‘psql -U postgres template1
< rt3.bak’. - Run make upgrade.
Make upgrade finishes with:
Congratulations. RT has been upgraded. You should now check-over
/opt/rt3/etc/RT_Config.pm for any necessary site customization.
Additionally, you should update RT’s system database objects by
running
ls etc/upgrade
For each item in that directory whose name is greater than
your previously installed RT version, run:
/opt/rt3/sbin/rt-setup-database --dba root --prompt-for-dba-
password --action schema --datadir etc/upgrade/
/opt/rt3/sbin/rt-setup-database --dba root --prompt-for-dba-
password --action acl --datadir etc/upgrade/
/opt/rt3/sbin/rt-setup-database --dba root --prompt-for-dba-
password --action insert --datadir etc/upgrade/
#ls etc/upgrade/
3.1.0 3.1.15 3.1.17 3.3.0 3.3.11
I get the following errors trying to do the updates:
/opt/rt3/sbin/rt-setup-database --dba postgres --action schema –
datadir etc/upgrade/3.1.0
Creating database schema.
Problem with statement:
CREATE SEQUENCE attributes_id_seq
ERROR: relation “attributes_id_seq” already exists at /opt/rt3/sbin/rt-
setup-database line 205.
/opt/rt3/sbin/rt-setup-database --dba postgres --action acl --datadir
etc/upgrade/3.1.0
Done setting up database ACLs.
/opt/rt3/sbin/rt-setup-database --dba postgres --action insert –
datadir etc/upgrade/3.1.0
Done setting up database content.
/opt/rt3/sbin/rt-setup-database --dba postgres --action schema –
datadir etc/upgrade/3.1.15
Creating database schema.
Couldn’t find schema file for Pg
/opt/rt3/sbin/rt-setup-database --dba postgres --action acl --datadir
etc/upgrade/3.1.15
Couldn’t find ACLS for Pg
/opt/rt3/sbin/rt-setup-database --dba postgres --action insert –
datadir etc/upgrade/3.1.15
Creating scrips…74.done.
Done setting up database content.
/opt/rt3/sbin/rt-setup-database --dba postgres --action schema –
datadir etc/upgrade/3.1.17
Creating database schema.
Couldn’t find schema file for Pg
/opt/rt3/sbin/rt-setup-database --dba postgres --action acl --datadir
etc/upgrade/3.1.17
Couldn’t find ACLS for Pg
/opt/rt3/sbin/rt-setup-database --dba postgres --action insert –
datadir etc/upgrade/3.1.17
Creating ScripActions…20.21.done.
Creating ScripConditions…11.done.
Done setting up database content.
/opt/rt3/sbin/rt-setup-database --dba postgres --action schema –
datadir etc/upgrade/3.3.0
Creating database schema.
Problem with statement:
drop index ticketcustomfieldvalues1
ERROR: index “ticketcustomfieldvalues1” does not exist
at /opt/rt3/sbin/rt-setup-database line 205.
/opt/rt3/sbin/rt-setup-database --dba postgres --action acl --datadir
etc/upgrade/3.3.0
DBD::Pg::st execute failed: ERROR: relation "objectcustomfieldvalues"
does not exist at /opt/rt3/sbin/rt-setup-database line 341.
Problem with statement:
GRANT SELECT, INSERT, UPDATE, DELETE ON objectcustomfieldvalues to rt;
ERROR: relation “objectcustomfieldvalues” does not exist
at /opt/rt3/sbin/rt-setup-database line 342.
/opt/rt3/sbin/rt-setup-database --dba postgres --action insert –
datadir etc/upgrade/3.3.0
Done setting up database content.
/opt/rt3/sbin/rt-setup-database --dba postgres --action schema –
datadir etc/upgrade/3.3.11
Creating database schema.
Problem with statement:
ALTER TABLE ObjectCustomFieldValues ADD COLUMN SortOrder INTEGER
ERROR: relation “objectcustomfieldvalues” does not exist
at /opt/rt3/sbin/rt-setup-database line 205.
/opt/rt3/sbin/rt-setup-database --dba postgres --action acl --datadir
etc/upgrade/3.3.11
Done setting up database ACLs.
/opt/rt3/sbin/rt-setup-database --dba postgres --action insert –
datadir etc/upgrade/3.3.11
Done setting up database content.
Thanks in advance,
Les
Hi all,
I’m upgrading from rt-3.0.5 on RedHat 9 to 3.4.0rc6 on a new server.
Version info on the new server: Fedora Core 3, Postgres 7.4.6,
Apache 2.0.52, Perl 5.8.5, mod_perl 1.9916.I’ll describe my problems first and anyone interested in helping
can read on for more details. Everything seems to be OK except
when I click a ticket, its history is blank. Another problem is
when I do a search, not all owners are listed and Nobody is listed
twice. Are these issues due to the problems shown below with the
database updates?
I think I’ve got it. After running ‘make upgrade’, when I run
/opt/rt3/sbin/rt-setup-database --dba postgres --action schema
-datadir etc/upgrade/3.3.0
It dies with an error to the effect of ‘index ticketcustomfieldvalues1
doesn’t exist’. So, the rest of the commands in that file fail, thus
some critical DB updates don’t happen.
Removing the following two lines;
drop index ticketcustomfieldvalues1;
drop index ticketcustomfieldvalues2;
from etc/upgrade/3.3.0/schema.Pg, allows it to complete successfully and
the history displays properly.
Is this a problem with my existing database missing these indexes or
does the 3.3.0/schema.Pg file need to be modified in the next RT
release?
Thanks,
Les
It dies with an error to the effect of ‘index ticketcustomfieldvalues1
doesn’t exist’. So, the rest of the commands in that file fail, thus
some critical DB updates don’t happen.Removing the following two lines;
drop index ticketcustomfieldvalues1;
drop index ticketcustomfieldvalues2;
from etc/upgrade/3.3.0/schema.Pg, allows it to complete successfully and
the history displays properly.Is this a problem with my existing database missing these indexes or
does the 3.3.0/schema.Pg file need to be modified in the next RT
release?
I’d thought we’d already caught that. Hm. perhaps only for mysql. Is
there a postgres syntax for "DROP index IF EXISTS?
It dies with an error to the effect of ‘index ticketcustomfieldvalues1
doesn’t exist’. So, the rest of the commands in that file fail, thus
some critical DB updates don’t happen.Removing the following two lines;
drop index ticketcustomfieldvalues1;
drop index ticketcustomfieldvalues2;
from etc/upgrade/3.3.0/schema.Pg, allows it to complete successfully and
the history displays properly.Is this a problem with my existing database missing these indexes or
does the 3.3.0/schema.Pg file need to be modified in the next RT
release?I’d thought we’d already caught that. Hm. perhaps only for mysql. Is
there a postgres syntax for "DROP index IF EXISTS?
I don’t know. I’m not a SQL guru by any stretch, but from the docs;
Synopsis
DROP INDEX name [, …] [ CASCADE | RESTRICT ]
Description
DROP INDEX drops an existing index from the database system. To execute
this command you must be the owner of the index.
Parameters
name
The name (optionally schema-qualified) of an index to remove.
CASCADE
Automatically drop objects that depend on the index.
RESTRICT
Refuse to drop the index if any objects depend on it. This is
the default.
I don’t know what schema-qualified means or if it would help, but that
is all I see that offers hope. Could ‘name’ be derived from a select
statement?
Thanks,
Les
I’d thought we’d already caught that. Hm. perhaps only for mysql. Is
there a postgres syntax for "DROP index IF EXISTS?
nope. perhaps you can do it inside a transaction to isolate any errors
with it?
or just ignore the error from it.