Puncte:0

Jurnalul MySQL se umple cu „informații de stare” nedorite la repornirea serverului din cauza SIGHUP

drapel dj

Acest lucru mă chinuie de ceva vreme, așa că este timpul să întreb.

MySQL error_log se umple cu „Informații de stare” atunci când serverul repornește din cauza SUPRAȚI. Iată un link care descrie comportamentul: Răspunsul serverului MySQL la semnalele SIGHUP

Înțeleg ce se întâmplă, dar nu știu cum să o repar.

Am un script care controlează pornirea/oprirea mysqld: /etc/init.d/mysql

Și aici este fișierul mysql-helpers sursă la care face referire scriptul init.d.

Nu găsesc de unde vine SIGHUP-ul? Sau poate vine de la sistemul de operare? Debian 10.

Editați | ×

Face repornirea serviciului mysql sau Stop nu produce niciodată intrarea suplimentară în jurnal, deci poate că are ceva de-a face cu procesul de închidere în timpul repornirii serverului | Nu înțeleg suficient SIGHUP pentru a determina dacă sunt pe drumul cel bun sau nu.

drapel us
Vă rugăm să adăugați detalii despre sistemul dvs. de operare. Este apelat init.d-script-ul dvs. în timpul unei închideri ordonate a sistemului?
Jeff avatar
drapel dj
Sistemul de operare este Debian 10 Buster cu kernel implicit. Scriptul init.d este apelat în timpul `shutdown -r now` sau `shutdown -h now`. Nu sunt sigur dacă este o oprire „ordonată” sau nu.
Cameron Kerr avatar
drapel id
Este acesta un VM sau o mașină fizică? Întreb doar pentru că (mulți) ani în urmă am întâlnit o problemă în care o mulțime de SIGHUP s-a datorat memoriei defectuoase, așa că a face un test de memorie poate fi util.... dar asta dacă cu siguranță mă strâng de paie. În primul rând, aș începe să văd ce mai rulează pe cutie. Orice monitorizare / metrici / management de configurare?
Cameron Kerr avatar
drapel id
SIGHUP este trimis la MySQL atunci când faceți lucruri precum fluxul de tabele de grant sau jurnalele... comportamentul pe care îl vedeți se datorează unor instrumente precum logrotate? Există ceva ciudat pe tabelul mysql.users etc.? Ce puteți determina în funcție de momentul în care are loc activitatea?
Jeff avatar
drapel dj
@CameronKerr Mașina este un VM. Nu rulează niciun software de monitorizare. Singurul lucru la care mă pot gândi este, eventual, înlocuirea lui `killall` cu `mysqladmin shutdown` în scriptul /etc/init.d/mysql. Nu sunt sigur însă. Cu toate acestea, este util să știi *când* SIGHUP este trimis către mysqld. Între timp, orice alte sugestii sunt mai mult decât binevenite.
drapel us
dacă în timpul închiderii init.d-script-ul dumneavoastră nu este rulat, toate procesele rămase (inclusiv mysql) vor primi un SIGHUP urmat de SIGKILL, miroase ca și cum asta se întâmplă acolo.
Jeff avatar
drapel dj
@Nils Comentariul tău s-a dovedit a fi răspunsul corect. Dacă doriți să postați un răspuns, îl voi marca drept corect. Soluția finală s-a dovedit a fi schimbarea scriptului de pornire/oprire de la sysvinit la systemd.
Puncte:0
drapel us

Dacă în timpul închiderii init.d-script-ul dvs. nu este rulat, toate procesele rămase (inclusiv mysql) vor primi un SIGHUP urmat de SIGKILL, miroase ca și cum asta se întâmplă acolo.

Jeff avatar
drapel dj
Exact asta se întâmpla. Am trecut de la init.d la systemd și acum totul este de piersici.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.