Problem Updating to 6.0.22

[dvanderhoof]

In process of updating from 5 to 6.0.22 on recently-updated Ubuntu 18.0.4; following instructions at https://doc.otrs.com/doc/manual/admin/6 ... ating.html. All is good through step 3. When I run DBUpdate-to-6.pl, the first 3 checks complete; the database version check fails: DBI connect('database=otrs;host=localhost;','otrs', . . .) failed: Can't connect to local MySQL server through socket 'var/run/mysqld/mysqld.sock' (2) at /opt/otrs/Kernel/System/DB.pm line 208. Checking the socket path mysqld does not exist at var/run/.

This would seem to indicate that MySQL is not installed; however, when I run otrs.Check the result for DB shows MySQL is OK:

<snip>

^[[33m^[[0m o DBD::MySQL...……………….^[[32mok^[[0m (v4.046)

</snip>

Does this indicate the DB needs to be re-installed? What does this mean for tables from OTRS 5? Should I fall back to that version and start the update over?

Thanks for any advice.

[root]

Hi Doug,

I suggest that MySQL is simply not running. The output from otrs.CheckModules.pl is only checking if the Perl DBD driver is installed.

What is the output of the command

Code: Select all

systemctl status mysql.service

- Roy

[dvanderhoof]

Output from systemctl status MySQL.service is 'Unit MySQL.service could not be found.'

[root]

Hi Doug,

Please check with the exact command I gave you (lowercase). If it's the same result I guess the database is not installed.

- Roy

[dvanderhoof]

Yeah, I did . . . forum is auto-formatiing my text

On further review . . . dpkg --get-selections | grep MySQL returns (among other items):

libmysqlclient16 deinstall
libmysqlclient18:amd64 deinstall
MySQL-server-5.1 deInstall

From the Man pages, I get that this means these are marked for removal. Possibly a process that happened during the Ubuntu upgrades?

So, do I simply re-install mysql-server or purge and install? If I purge does, it only impact system files or will it also remove items stored in /var/lib/mysql/otrs, for example?

Thanks.

[dvanderhoof]

I was able to successfully complete the update through Step 7 and was able to start services. However, I was unable to connect to the interface. While troubleshooting one (or more) of the changes caused the Apache server to halt and attempts to restart fail. Reviewing both the syslog and Apache error log have not been helpful. Complicating this is that, when we first started using OTRS in 2009-10 timeframe, we created 2 instances to both our IT support and facility maintenance. Since then the facility maintenance instance is no longer in use so I suspect this is part of what's causing the problem with getting things running.

Since we've been off-line now for almost 2 weeks, I'm wondering if I wouldn't be better to uninstall, remove the relics and re-install. If I go this route, would it be just a matter of backing up the database (tables are already upgraded) and config.pm? Any other files that I need to retain? Is there a better, cost-effective approach?

TIA,

Doug

[root]

Doug,

When you finished step 7 is usually done. Everything you mentioned might be only related to the webserver. I think uninstalling is no option. What happened to the other instance (facility mgmt)?

- Roy

[mmpl]

What result after running this command?

Code: Select all

mysql -u root -p

Have you had no problem installing the libc6-dev and libdatetime-perl packages?
I had to remove the package

Code: Select all

apt-get purge libc6-dev

and reinstall:

Code: Select all

apt-get install libc6-dev

because after executing the command:

Code: Select all

apt-get update

I had a problem with MySQL (Debian upgrade MySQL to 5.8x):
Can't connect to local MySQL server through socket 'var/run/mysqld/mysqld.sock'

[dvanderhoof]

mmpl,

Thanks for the comments. The current issue is related to the apache2 server looking for a secondary instance during startup; it doesn't appear to be related to the database itself.

Roy,

You are correct . . . I grepped for otrs2 over the weekend and believe I found the culprit(s) hiding in mods-available with otrs.conf and perl.load. I commented out the lines in both files and was able to successfully start apache.

Whew! Now on to find the next problem