Ik heb momenteel een probleem met een website.
Die site is gisteren down gegaan.
En het lijkt op een MySQL-probleem.
Korte omschrijving situatie:
Ik huur een VPS(cloudbox) bij provider
Daarop heb ik een standaard LAMP-configuratie:
- linux 2.6.32 ; Centos 6.8 x64 (juli 2016)
- apache 2.4.23
- mysql 5.5.31
- php 5.6.28
En daarop draait een PHP-script wat ik heb gekocht.
Korte omschrijving probleem:
My site is down.
* ControlPanel site is not working
* PHPMyAdmin displays "phpMyAdmin - Error
* I can FTP the server; no storage problem or disk error
* I checked the site logs. No strange log info is seen in the logfile.
* DirectAdmin displays: Invalid login.
* commandline accessable with SSH/Putty
* commandline > service mysql status
displays: "mysql: unrecognized service"
* Commandline > service --status-all
displays: "MySQL is running, but PID file could not be found"
Iemand op dit forum die me wellicht hiermee kan helpen ?
Doe eens een ls -altr /var/run/mysqld/mysqld.pid om te kijken wat de rechten zijn van de file.
Je mag de pid file gewoon weggooien want MySQL maakt steeds een nieuwe aan tijdens starten van de deamon.
het lijkt me geen bug, dan zou je wel iets gevonden hebben daarover.
Verder is er ook nog een mysqld.sock of zoiets, ook die mag weg en wordt aangemaakt bij starten MySQL
Nadat je ze weggegooid check je ook nog even of er MySQL processen draaien: ps -ef |grep mysql
Deze processen kill je met -9 waarna vervolgens MySQL gestart kan worden. Doe geen restart maar gewoon een start. Check eventuele foutmeldingen kom daarmee hier terug
@Aad A
> ls -altr /var/run/mysqld/mysqld.pid
ls: cannot access /var/run/mysqld/mysqld.pid: No such file or directory
Ik heb die directory niet
en die file mysqld.pid komt nergens voor op mijn server.
> ps -ef |grep mysql
Als ik dat commando vaker uitvoer; krijg ik telkens een andere PID.
> ps -ef |grep mysql
root 31982 22687 0 19:08 pts/0 00:00:00 grep mysql
> ps -ef |grep mysql
root 31984 22687 0 19:08 pts/0 00:00:00 grep mysql
> ps -ef |grep mysql
root 32247 22687 0 19:09 pts/0 00:00:00 grep mysql
> kill -9 31982,31984,32247
bash: kill: 31982,31984,32247: arguments must be process or job IDs
[size=xsmall]Toevoeging op 07/11/2017 20:05:05:[/size]
- Ariën - op 07/11/2017 07:34:16
In my.cfg zal waarschijnlijk een verwijzing staan naar een niet bestaande pidfile.
* ik heb geen my.cfg gile
* ik heb geen mysql.cfg file
* ik heb wel een my.cnf file
/usr/local/directadmin/conf/
my.cnf ; dit bevat DA-username en DA-password
mysql.conf ; dit bevat DA-username en DA-password
Uit je ps -ef blijkt dat er geen MySQL processen achter gebleven/actief zijn. Op zich is dat goed.
Je vond namelijk alleen je eigen command met ps - ef
In een bestand my.cnf staan de verwijzingen naar de dir voor de pid en de socks file: Zie het voorbeeld hieronder:
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
In jouw geval is er kennelijk een directe link met DA en misschien moet MySQL deamon door DA opgestart worden omdat daar de file bekend is?
Hier houdt mijn kennis op, ik gebruik gelukkig geen tooling zoals DA, Plesk, PHPAdmin etc omdat dat doorgaans meer ellende op je systeem creeert dan gemak.
Zoek of je met "DA service manager" MySQL kan starten ipv service mysql start, want handmatig opstarten zal MySQL op zoek gaan naar de my.cnf in de /etc structuur niet in /usr/local/directadmin/conf/
Als je er echt niet uitkomt, ga niet verder prutsen, maar vraag je hosting. Eventueel kan je nog via een ticket bij DirectAdmin.com nog om hulp vragen.
Als noodmaatregel om MySQL server toch handmatig op te kunnen starten zou je een symbolic link kunnen maken zodat my.cnf ook in /etc/mysql lijkt te staan:
In een bestand my.cnf staan de verwijzingen naar de dir voor de pid en de socks file: Zie het voorbeeld hieronder:
Mijn file /usr/local/directadmin/conf/my.cnf ziet er heel anders uit:
[client]
user=da-admin
password=**********
De file is dus slechts 3 regels lang.
Dan is de vraag:
- is dit een probleem ?
- zo ja, Wat/wie moet deze file correct aanmaken ?
- Begrijp ik nu dat ik wellicht eerder een DirectAdmin probleem heb
(wat vervolgens mijn MySQL belemmert) ?
Vanuit het URL dat Arien geeft moet er dus daadwerkelijk een "gewone" /etc/my.cnf zijn. Dat is dus goed nieuws, gewoon zoals het hoort.
(op mijn servers is dat overigens /etc/mysql/my.cnf maar dat mag niet van DA)
Your my.cnf for the system will be at:
/etc/my.cnf
DirectAdmin does create a secondary my.cnf, but it's only used for the mysqldump calls. It's found at:
/usr/local/directadmin/conf/my.cnf
Conclusie: de ene is echt voor MySSQL deamon en de ander is gewoon voor DA om iets met MySQL te doen zoals backuppen en dergelijk: mysqldump calls. Dat impliceert dat 'service start mysql' ook gewoon zou moeten werken als er een my.cnf in /etc staat
Voorlopig dus my.cnf van een backup halen naar /etc zetten en MySQL starten! en meteen backup maken. Ga niet zelf een my.cnf in elkaar prutsen met mijn voorbeeld want dat kan desastreus zijn voor je wellicht nog aanwezige data.
Je hosting kon dus even dieper in je systeem kijken. Prima oplossing geweest.
Bedankt voor de terugkoppeling. Hopelijk was je laatste backup voldoende recent....
