0

I am trying to set up a staging server on a VM on my local PC. Ubuntu 10.4.2 LTS 64 bit server is installed. I have another VM on the same machine running as a full time server, so I set-up port-forwarding on the router to send ssh on 3060 and http on 3050 to this VM's internal IP address (192.68.1.13). I am working on a rails 3 app and I use deprec and capistrano to automate the install and deploy.

As a first step, I got the process working over prt 3060 for ssh, but I left apache on port 80. This worked nicely when I pointed the browser at 192.168.1.13. I then added the 'Listen 3050' line to my /etc/apache2/ports.conf file:

Listen 80
Listen 3050

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

After restarting the VM, the web page just gave the rails error message after trying to reconnect with the browser. Checking production.log showed the following error:

Mysql2::Error (Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)):

Some good tips [here][1] helped me realize that the mysql server was not running.

I then ran:

sudo mysqld -verbose

which showed me that there was an unknown optoin 'skip-bdb' causing mysql to crash.

Checking my.conf showed that this option was being set there. I commented it out and then i could successfully start mysqld. The rails app was working again as well.

Can anyone help me to find out why adding the one line to /etc/apache2/ports.conf caused mysql to barf on this option? Also, with deprec, you have the chance to set-up the apache-vhost file locally and upload it when you deploy. If I added *:3050 there, it also prevented mysql from starting during the automatic deploy, crashing the whole install. I guess the problems are related.

Thanks, Jon

0

The Apache issue and the MySQL issue aren't directly related. The skip-bdb in your file was probably an typo'd attempt to enter skip-ndb, which is a valid config option.

Somewhere along the line, the my.cnf file was modified with the bad config (is your automated deploy overwriting this file with the invalid setting? That would explain why your deploy fails, too), but the issue didn't occur until the service was restarted when you rebooted for the Apache change, making the issues appear to be related.

Find where the bad setting came from, and fix it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.