mysqld draait, maar niet te stoppen

[Boudewijn]

Hoi,

Ik heb een mysql server op gentoo:

uname -a
Linux mail.<irrelevant>.nl 2.6.11-gentoo-r7 #3 SMP Thu Jun 9 22:01:38 CEST 2005 x86_64 AMD Opteron(tm) Processor 242 AuthenticAMD GNU/Linux

Het is zo dat ik mysql niet uit of aan kan zetten :

code:

mail boudewijn # /etc/init.d/mysql stop
 * Stopping mysqld ...                                                              [ !! ]
mail boudewijn # /etc/init.d/mysql start
 * WARNING:  "mysql" has already been started.
mail boudewijn # cat /var/log/mysql/mysql.err
050620 14:33:43  mysqld started
050620 14:33:43 Can't start server: Bind on TCP/IP port: Address already in use
050620 14:33:43 Do you already have another mysqld server running on port: 3306 ?
050620 14:33:43 Aborting

050620 14:33:43 /usr/sbin/mysqld: Shutdown Complete

050620 14:33:43  mysqld ended

mail boudewijn #      mail boudewijn # netstat  | grep sql
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock
unix  3      [ ]         STREAM     CONNECTING    0      /var/run/mysqld/mysqld.sock

Het is dus zo dat er gewoon nog iets draait ergens

Restart haalde niets uit...

Hoe kan ik dit netjes oplossen? Ook killal mysql helpt niet.
Heb ook al /usr/bin/mysql_install gedaan ....

[ShadowBumble]

killall -9 mysqld

al geprobeerd

niet goed gelezen dus.

[ Voor 126% gewijzigd door ShadowBumble op 20-06-2005 15:18 ]

[Osiris]

killall -9 proberen?

edit:

Spuit 11

[ Voor 35% gewijzigd door Osiris op 20-06-2005 15:17 ]

[Boudewijn]

net een killall -9 gedaan (ja nogmaals ) :

code:

mail boudewijn # killall -9 mysqld
mail boudewijn # killall -9 mysqld
mysqld: no process killed

het ziet ernaar uit dat er wat is afgeschoten de eerste keer .
Ik check de hele zaak maar weer eens, en wat schetst mijn verbazing: netstat | grep sql levert niets meer op

echter wil mysql zelf nog steeds niet veel:

code:

mail boudewijn # /etc/init.d/mysql start
 * WARNING:  "mysql" has already been started.
mail boudewijn # /etc/init.d/mysql stop
 * Stopping mysqld ...                                                              [ !! ]

In /var/log/messages staat niets relevants, net als in /var/log/mysql/mysql.err .


Nu heb ik (ja het is niet netjes) gewoon de executable aangeroepen van mysql:

code:

cd /usr ; /usr/bin/mysqld_safe
Starting mysqld daemon with databases from /var/lib/mysql

Nu geeft ps aux aan dat er wel een en ander draait (concurrent SSH sessie gestart):

code:

mail boudewijn # ps aux | grep sql
root      4010  0.0  0.0   8640  1276 pts/3    S+   15:23   0:00 /bin/sh /usr/bin/mysqld_safe
mysql     4045  0.0  0.3  56920  7120 pts/3    S+   15:23   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
mysql     4046  0.0  0.3  56920  7120 pts/3    S+   15:23   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
mysql     4047  0.0  0.3  56920  7120 pts/3    S+   15:23   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
mysql     4048  0.0  0.3  56920  7120 pts/3    S+   15:23   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
root      4085  0.0  0.0   2596   516 pts/4    S+   15:24   0:00 grep sql

En hij doet het weer, na nog 1 restart (wel vreemd zeg).
Heeft iemand een idee waar dit aan heeft gelegen? (restarten is niet lollig op een server, en zeker niet als er Linux opzit).

[irondog]

Heeft iemand een idee waar dit aan heeft gelegen? (restarten is niet lollig op een server, en zeker niet als er Linux opzit).

Ja, het niet goed op de hoogte zijn van de init scripts over de status van draaiende processen.

Je draait Gentoo. Wat je had kunnen doen is:

code:

/etc/init.d/mysql zap

Daarna staat mysql geregistreerd als een niet-lopend process. Daarna kun je het weer starten.

[Bergen]

BoudewijnLinux schreef op maandag 20 juni 2005 @ 15:26:
Heeft iemand een idee waar dit aan heeft gelegen?

Je kunt het init-script toch gewoon openen en kijken hoe het script erbij komt dat MySQL nog draait? Ik gok op een niet-verwijderd pid-bestand.

[ShadowBumble]

Bergen schreef op maandag 20 juni 2005 @ 15:50:
[...]
Je kunt het init-script toch gewoon openen en kijken hoe het script erbij komt dat MySQL nog draait? Ik gok op een niet-verwijderd pid-bestand.

stond ook al in zijn eerste post want zoals je ziet leest de netsta een file uit in /var/run/mysql ik vermoed dat het in werkelijkheid ghost connecties waren of stale files vandaar dat ze er na een reboot nog waren

[Boudewijn]

dit het initscript (althans relevante deel):

start() {
checkconfig || return 1
ebegin "Starting mysqld"
start-stop-daemon --start --quiet --exec /usr/bin/mysqld_safe \
--background -- >/dev/null 2>&1
eend $?
}


en ja daar word ik dan ook niet veel wijzer van.... je callt mysqld_safe met wat voor een daemon logische params...
en dat doe ik handmatig hierboven (lukte wel trouwens, en dit niet... vreemd).

ShadowBumble schreef op maandag 20 juni 2005 @ 15:52:
[...]


stond ook al in zijn eerste post want zoals je ziet leest de netsta een file uit in /var/run/mysql ik vermoed dat het in werkelijkheid ghost connecties waren of stale files vandaar dat ze er na een reboot nog waren

Ah ik ken dat nog niet, zal daar vanavond eens over inlezen. Dank je voor de suggestie!

[irondog]

Je kan jouw probleem gewoon reproduceren hoor.

code:

/etc/init.d/mysql start
killall -9 mysqld
ps auxw|grep mysqld # hee, mysql draait niet
/etc/init.d/mysql start # En toch kan ik het niet starten, rara hoe kan dat?
/etc/init.d/mysql zap
/etc/init.d/mysql start # Nu doet ie het wel weer.

[Boudewijn]

ah ok.

dat wist ik dus niet.
Weer wat bijgeleerd. dank je voor die zap truc!

[jant]

doe voortaan gewoon even:

code:

kill -9 `ps ax | grep mysqld | awk '{print $1}'`

Wedden dat mysqld de geest geeft ?

[Verwijderd]

jant schreef op maandag 20 juni 2005 @ 19:36:
doe voortaan gewoon even:

code:

kill -9 `ps ax | grep mysqld | awk '{print $1}'`

Wedden dat mysqld de geest geeft ?

Ik gebruik bijna nooit een kill -9, ik begin met een gewone kill, daarna neem ik zwaardere maatregelen, als het nodig is en als laatste een een kill -9.

Liever nog, gebruik ik een init script is, waar ik de deamon stop en start of restart.
.

[Boudewijn]

klopt

maar zoals je hier kunt zien ging dat niet.

Ik gebruik tussen init script en kill graag ook gewoon een directe aanroep

[kmf]

even een notitie. Niet te vaak gebruiken dat killall. Zou je niet leuk vinden als je met corrupte tables komt te zitten. Interesanter is uitvogelen waarom dat ding gecrasht was.

[Wolfboy]

Mysql liever niet killen en als je hem toch killt dan liever met kill ipv. killall, met killall haal je direct alle draaiende processen met een bepaalde naam weg, met kill alleen de desbetreffende processen (door het proces-id)

Tipje voor de volgende keer, tik eens "/etc/init.d/mysql" in, dan krijg je een flinke lading uitleg als het goed is

[kenneth]

En killall is niet standaard ... op sommige UNIX-systemen (AIX, HP-UX, Solaris) doet het letterlijk wat de naam zegt, de argumenten negerende

killall — kill all active processes

[Wolfboy]

kenneth schreef op dinsdag 21 juni 2005 @ 01:21:
En killall is niet standaard ... op sommige UNIX-systemen (AIX, HP-UX, Solaris) doet het letterlijk wat de naam zegt, de argumenten negerende

Daar heb ik ervaring mee ja, das wel ongeveer m'n grootste blunder met unix systemen geweest

Ik deed es "killall -h", het resultaat was iig niet wat ik verwacht had

[Boudewijn]

Wolfboy schreef op dinsdag 21 juni 2005 @ 14:50:
[...]
Daar heb ik ervaring mee ja, das wel ongeveer m'n grootste blunder met unix systemen geweest

Ik deed es "killall -h", het resultaat was iig niet wat ik verwacht had

totaal offtopic:

ik ook ooit op mijn ultra10 gedaan (staat nu gewoon gentoo op, dus geen gekke fratsen meer).

ontopic:

Tsja hoe kan ik het beste achterhalen waar hij op gecrasht is?
Idd is killall veel te lomp, ivm corrupte tables (MySQL is al zo lam als wat, wat dat betreft ...).

[ Voor 4% gewijzigd door Boudewijn op 22-06-2005 02:36 ]

[Bergen]

BoudewijnLinux schreef op woensdag 22 juni 2005 @ 02:36:
[...]

MySQL is al zo lam als wat, wat dat betreft ...

Is dat verbeterd in versie 5 van MySQL?

[Wolfboy]

BoudewijnLinux schreef op woensdag 22 juni 2005 @ 02:36:
Tsja hoe kan ik het beste achterhalen waar hij op gecrasht is?
Idd is killall veel te lomp, ivm corrupte tables (MySQL is al zo lam als wat, wat dat betreft ...).

Bijvoorbeeld: /var/log/mysql/mysqld.err

Btw, opzich kan je wel een kill(all) signaal geven maar geef dan geen kill/9 signaal maar een term/15 oid.
Dan heeft het programma tenminste de kans om zichzelf te sluiten.

BoudewijnLinux schreef op woensdag 22 juni 2005 @ 02:36:
ik ook ooit op mijn ultra10 gedaan (staat nu gewoon gentoo op, dus geen gekke fratsen meer).

Zeg dat maar niet te hard, ooit killall5 geprobeerd bij een Gentoo machine?

[ Voor 23% gewijzigd door Wolfboy op 22-06-2005 10:08 ]

[Boudewijn]

staat niets in.

Zoals je hebt kunnen zien in mijn startpost heb ik ook dat bestand al bekeken


killall5?

nope. Zal eens proberen op een testbox

[ Voor 25% gewijzigd door Boudewijn op 22-06-2005 12:03 ]

[Wolfboy]

BoudewijnLinux schreef op woensdag 22 juni 2005 @ 12:02:
staat niets in.

Zoals je hebt kunnen zien in mijn startpost heb ik ook dat bestand al bekeken

Oeps, over het hoofd gezien
Daar hoort het iig gewoon te staan

killall5?

nope. Zal eens proberen op een testbox

DESCRIPTION
killall5 is the SystemV killall command. It sends a signal to all processes except kernel threads and the processes in its own session, so it won't kill the shell that is running the
script it was called from. Its primary (only) use is in the rc scripts found in the /etc/init.d directory.

Niet zo dodelijk als killall op een unix systeem maar desondanks maak je mensen niet blij hiermee

[kenneth]

Wolfboy schreef op woensdag 22 juni 2005 @ 12:10:
Niet zo dodelijk als killall op een unix systeem maar desondanks maak je mensen niet blij hiermee

Ehm, het is de killall van een UNIX-systeem. Vandaar de naam, verwijzend naar de System V ( = 5 ) implementatie van UNIX.

[Wolfboy]

kenneth schreef op woensdag 22 juni 2005 @ 12:32:
[...]
Ehm, het is de killall van een UNIX-systeem. Vandaar de naam, verwijzend naar de System V ( = 5 ) implementatie van UNIX.

Je hebt gelijk, ik was wat in de war.
Bij deze uitleg staat dat je shell sessie niet vermoord wordt, khad het idee dat dat bij Unix wel het geval was, maar ik vergeet eventjes dat ik toen dus via ssh ingelogd was (en sshd dus uitgeschakeld werd)

Dan is ie idd hetzelfde