TurnKey Linux Virtual Appliance Library

Cannot connect to phpMyAdmin in Turnkey MySQL appliance

I have created a Tunkey MySQL instance on Amazon ec2 from the AWS marketplace. MySQL is running ok, I can connect to Webin on port 12321 and the shell on port 12320 but I cannot seem to connect to phpMyAdmin. I'm assuming its on port 12322 right?

The only thing I could think of was the security group but I checked that and it is allowing traffic through 12322 (plus I am using the same security group for a LAMP instance and phpMyAdmin is working on this instance).

I'm pretty hopeless at troubleshooting in Linux (hence my reason for using Turnkey!) so I would appreciate any help.

Thanks.

Chris Musty's picture

Uses SSL

Have you tried using SSL, although if you could connect to webmin you should know this.

You have the right port but I am not quite sure why you cant load up phpmyadmin.

Obvious questions - Are you are running LAMP, Joomla, Wordpress, drupal or other mysql based appliance? You connect with https://my.ip:12322?

Chris Musty

Director

Specialised Technologies

Hi Chris, Yes I am using SSL

Hi Chris,

Yes I am using SSL but it won't connect. It's the base Turnkey MySQL applicance (http://www.turnkeylinux.org/mysql) without any extras installed. I have used it before and phpMyAdmin normally just works straight away. I would start again only I have loaded my MySQL database with a lot of data and I don't really have the time to do that again.

Chris Musty's picture

Would need to see it myself

Would need to SSH in and see why for myself.

If you are comfortable you could do this and check out the logs...

Chris Musty

Director

Specialised Technologies

How would I find the logs?

Hi Chris,

I can SSH in, but which logs would I be looking for specifically? I can post them here.

Chris Musty's picture

Questions

How did you load the data into MySQL?

What does the browser present when you navigate to https://my.ip:12322 ?

Chris Musty

Director

Specialised Technologies

Hi Chris, I loaded to the

Hi Chris,

I loaded to the MySQL database with a PHP script.

The web page just gives the standard "This webpage is not available" message.

I Too have reproducible connection issues with phpmyadmin

Hi there. I have a similar problem, This is what I have done :

(on windows 7, 64 bit patched up to date)

1) create a turnkeylinux mysql virtual server inside virtualbox, checked that webmin etc. works just fine.

 

2) using mysql, import a gigantic database into said server (i assume this step can be omitted)

 

3) open chrome, type in the exact address shown in "turnkey linux configuration console" https://192.168.nn.nnn

 

This loads up the phpmysql user interface just fine in the browser, but there are problems running queries - try this :

1) type 192.168.nn.nnn in chrome

2) phpmysql shows a welcome screen and prompts me for username and password. I give root and the password i entered when the virtual linux was booted first time

3) phpmysql shows its ususal screen with a list of databases on the left. of important stuff i have : (sorry about the Danish)

 

MySQL

  • Server: Localhost via UNIX socket
  • Serverversion: 5.1.63-0ubuntu0.10.04.1
  • Protokolversion: 10
  • Bruger: root@localhost
  • MySQL Tegnsæt: UTF-8 Unicode (utf8)

Web server

  • lighttpd/1.4.26
  • MySQL klientversion: 5.1.63
  • PHP extension: mysql

phpMyAdmin

  • Versionsinformation: 3.3.2deb1ubuntu1

 

Okay now, to keep things simple, and to allow others to verify/duplicate my problems, i go to the mysql database by clicking "mysql" to the left

4) I am shown a list of tables, i select the table called user

5) I am shown a list of users

6) I press the Edit link in the top right corner of the screen, this will show an edit window with the text "SELECT * FROM `user`

now, i press "GO"

 

I would have expected a result from phpmyadmin with a list of users as before, but insted the browser shows "waiting for 192.168.nn.nnn" and nothing happenes. After a while i get this message in the right hand part of the main phpmyadmin user interface:

No data received

Unable to load the webpage because the server sent no data.

Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.

 

At this point i can click "user" in the left hand part, and immediatly get the record list of the user table

If i keep the window open and try to click go many time, it seems i get a correct response some times, but more than 50% of the time i get the above error.

 

The mysql server is at other times  (but of course not when I am testing this) responding fine to tons of inserts from a jdbc based source, and tons of read requests from  C# programs running through ODBC / Mysqlconnect. I am pretty sure the mysql server is running just fine using these kinds of connections.

 

I would love to get some pointers as to what to look for, (and do) to figure what the problem is.

Note that I can reproduce the error using databases and tables already inside the turnkeylinux server, when it is has been booted the first time.

 

The problem can also be reproduced from another pc on the same local network (running vista and chrome) and on this pc where the server is running, using internet explorer.

The VirtualBox this is running the mysql is configured with 2048MB RAM.

 

As the problem seems to only occour with phpmysql and not with ordinary connects, and only when phpmysql queries from another window, and only intermittently i suspect an error in the php or phpmysql install on the server - but I am not sure. I have totally turned off windows firewall, but that didn't change anything.

I would love if someone else were able to reproduce this, and also if someone would point me towards what log files (location and name) and settings to inspect

This helped a bit (php.ini change memory from 32 to 128M)

I searched the net for other ppl having a similar problem, and even though most hits were duds, this one had a useful tip way down the thread. http://drupal.org/node/1048140

So I located the php.ini file inside the server and changed the max. memory used by a script from 32M to 128M.

This *seems* to have fixed the problem with the small example, i get some weird pauses in replies but eventually the user list sems to pop up when i press GO.

The response time, though, indicates something else is wrong, as it differs from like 0.01 second to like 4 seconds (and 4 seconds is way too long to display 5 lines, it's my experience that phpmyadmin usually responds much faster)

 

With my own larger tables I still get the original error, but that might be a timeout issue, will try to increase the time php is allowed to run a script.

The error seems to be everywhere, also with queries that should respond within fractions of a second. In general clicking a table shows the first many of its records within tens of a second, but then clicking "edit" and "go"  (to edit the query and resend it unchanged) yields a looong pause and then the error with no data shown.  Sometimes, though the response comes back immediatly.

If i fire off a query where i seach a string from an indexed field the query usually won't return anything after a long while, but occasionally it will return within tens of a second with the correct result.

Seems to me something is wrong somewhere. Desperately need pointers as to what to look for. Especially location of log files that might show something useful

seems like it is a phpmyadmin problem of some sort.

I installed http://www.adminer.org/  and that one works totally snappy fine right out of the box, All I did was search for the location of the index.php file from phpmyadmin and then ftp the adminer php file to the same directory. adminer returns results in sub second speed where phpmyadmin takes 30 seconds or just times out.

as adminer also uses php, it is probably not a php problem, unless phpmyadmin do something really weird.

bug is still there, altohugh adminer works better

I still have this problem. My best guess is some kind of trouble with the default settings of php and mysql. Sometimes when I do something super simple in adminer, the browser just waits and waits and then ends up showing the ERR_ message quoted in my post a few posts back.

Thus, the problem persists with both phpmyadmin and with adminer. It persists on both the databases shipped with mysql and my own databases, it shows up in internet explorer as well as chrome (although IE does not show an error, it just waits forever or shows a blank screen after a long while).

I am not that used to fine-tuning php or mysql, and would love to have some pointers as to what changes might fix this problem.

My guess is that somehow the response from mysql never makes it back to the browser. Not sure if it is php<->mysql or php<->webserver or browser<->php or browser<->webserver that is broken.

As the problem does not seem to be very common on the net, it might in fact be some kind of setup with the webserver?

The mysql database, by the way, works just fine also under heavy load, when accessed via odbc and jdbc. It is the brower based tools that doesn't work well.

I am wondering what to try next. I guess the most productive next step is for me to download the original turnkey mysql machine, and find an easy way for that one to produce the error, with no changes made to it, then post again. In that case it should be relatively easy for others to replicate the error.

Running on windows 7 64 bit, with a virtualbox'ed turnkeylinux mysql appliance more or less out of the box. Accessing phpmysql and adminer through google chrome (ver 21.0.1180.89)

Will try with a new debian V 12 build and report back

While I've been struggling with this, turnkey made a major shift to new versions, I will try and move my servers to the new versions and see if the problem do not disappear by itself.

With the current version 12 turnkey linux appliance all works

I have installed a version 12 turnkey linux mysql appliance, and applied all the changes i had made to the original version 11 that had problems.

I am not able to reproduce the error, so anyone else have similar problems, do a mysqldump, install a new debian based version 12 server, edit any config files etc. Restore your data and the bug will be gone.

I will restore my main database (pretty large, 1.2 billion records myisam) over the weekend, will only post back if something catastrophic happens.

WARNING: version 12 now runs mysqloptimize daily via cron.daily

I think this might have been added by the debian folks, but anyways, the new mysql appliance has a change that is potentially dangerous for heavy users of mysql.

 

the old appliance did not run mysqloptimize, but the new one does. daily.

 

In my setup, mysql optimize takes about 1 day 6 hours to run on the largest table, and when it is running the table is locked. This means that my server does not work at all, it just has a few mysql optimize table processes waiting for the oldest one to finish, the main table is eternally locked up.

 

The solution is just to comment out the call in the script /etc/cron.daily/mysqloptimize

 

If You have any tables that are extremely large and take a lot of time to optimize, You might consider not optimizing them daily to reduce downtime. The table I have that takes a long time is about 100 GB when mysqldump'ed and has a little over 1000 million records.

This post just a warning that with release 12, compared to release 11, the default behavior has changed to automatically optimize all tables once a day.

the user responsible for the optimiziation is debian-sys-maint  this user also automatically repairs broken tables and updates tables and stuff, when mysql is restarted.

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account, used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <strike> <caption>

More information about formatting options

Leave this field empty. It's part of a security mechanism.
(Dear spammers: moderators are notified of all new posts. Spam is deleted immediately)