You are here
Jeremy Davis - Sun, 2011/07/10 - 14:09
I'm just finalising my SimpleInvoices TKLPatch. It works, just need to test the bundled patch on a clean ISO. That is where my problem has occurred.
Based on Core with a patch that installs MySQL it will happily alow root to create DB without requiring a password during patching. But when I try the same thing on TKL LAMP it errors:
mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Anyone got any ideas?
Forum:
Doh...! MySQL needs to be running!
Easy fixed, just started MySQL before running any MySQL commands
Obvioulsy if you install MySQL it will be running.
Strange behaviour...
It almost worked once (MySQL started and it created the database but then loading the data to the database failed). But now eveytime MySQL fails to start. It doesn't give any error message.
If I reboot the host appliance that I'm patching on (Adrian's TKLDevEnv running under KVM on ProxmoxVE) then MySQL will start once for one session. Any ideas on how this could be done without rebooting?
Same problem here ...
I think I encountered the same problem while working on a Drupal 7 patch. First time the patch was run, MySQL started and ran okay, but every attempt thereafter it fails at the beginning where MySQL is started. I ran tklpatch-extract-iso and tklpatch-chroot without running any of my patch scripts but found the same behavior.
I think it has something to do with `local diversion of /sbin/initctl to /sbin/initctl.distrib'. Each time it failed, my conf script had exited with an error and exited the chroot leaving MySQL running. If I deleted the .cdroot and .rootfs files and started over, then following attempts will fail at starting MySQL. However, if I use tklpatch-chroot to enter the chroot shell and then 'stop mysql'. I can then exit the chroot and delete the files without needing to reboot. I hope this is enough of a clue to find and fix the problem. Perhaps just stopping MySQL before exiting the chroot would be sufficient.
Information is free, knowledge is acquired, but wisdom is earned.
Ideally you need to stop MySQL from your patch
But as you say if the patch throws an error and exits prematurely, doing that is easier said than done. I guess what we probably need is a code snippet for patches that traps errors so that any services started by a patch are stopped prior to exiting. TBH though, as TKLPatch is a development tool, documenting the issue and providing a workaround is probably the best we can hope for at the moment.
Obviously it'd be great to make it as user friendly as possible (and have TKLPatch handle all this stuff) but it's probably unrealistic at this point.
My best guess is that MySQL
My best guess is that MySQL has an open socket in the chroot that is left running when the error occurs and TKLPatch exits. Not sure if there is any simple way for the exit routine to check for open sockets and either close them, or issue a warning.
Information is free, knowledge is acquired, but wisdom is earned.
I think you're right
But as I said above, an error trap should be able to at least warn of this issue and exit while still in the chroot (at the very least) allowing you to manually stop the service, exit and try again. Exactly what this code looks like though I don't know. I know it's theoretically possible, I just don't know how to do it. When I first discovered error trapping I had a bit of a play with it but was unable to get it to work as I wanted it to. I'm sure if I had persevered then I could've worked it out, but it was unnessessary for my purposes at the time so I wandered off to something else. If you are keen I'm sure you could do some research online and develop a code snippit that would do it.
If you do, please post back as others may be interested and perhaps even the devs may want to include it in the example patches that TKLPatch produces, or at least document it somewhere.
DB not closed properly
I have a sort of smilar issue where an application I am developing will return "Cannot connect to DB" at what was seemingly random intervals.
It turned out to be PHPMyAdmin. If I did not logout before 24 minutes it would not close the DB connection correctly and cause the DB to not accept the connection and stranger than that it stopped any networking access to the server until I typed "/etc/init.d/networking" restart or "restart networking" on 10.04+ I think.
Is your server actually running or is it just blocking connections because the connection wasn't closed properly? Which might be hard to track down.
Chris Musty
Director
Specialised Technologies
Add new comment