Dovecot Patch einspielen ?

O

Olli2k

Member
Servus,
ich habe auf meiner alten Debian 9 Kiste einen schlimmen Fehler begannen, der mich aktuell an den Rand der Verzweiflung treibt. Offensichtlich sorgt Dovecot aufgrund eines double MySQL close dafür, dass mein Server alle 5 Minuten bis 6 Stunden einfriert.

Es gibt auch offensichtlich einen Patch dafür:

Der ist aber schon älter und wird offensichtlich nicht implementiert.

Mein aktueller Fehler ist einer wiederkehrende Mischung aus:
kernel: [ 5591.234017] traps: auth[30478] general protection ip:7f364ed47b74 sp:7ffebdf5f960 error:0 in libmariadb.so.3[7f364ed3b000+21000]
dovecot: auth-worker: Fatal: master: service(auth-worker): child 30478 killed with signal 11 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps)

Irgendwann geht der auth Prozess auf 100 und die Kiste reagiert nicht mehr. Dann hilft nur ein hardreset. Mit viel Geduld ist zwar ein SSH Login möglich, aber service Befhele stoßen nur auf:
Failed to retrieve unit state: Die Wartezeit für die Verbindung ist abgelaufen
Failed to stop sinusbot.service: Die Wartezeit für die Verbindung ist abgelaufen


Und ein Shutdown Befehl gibt nicht mal eine Ausgabe.

Das das ganze am Dovecot liegt, vermute ich auch nur, aber ich finde nicht anderes, was auf einen Fehler hinweist.

Ich dachte eigentlich ich könnte das Problem aussitzen, bis es ein Dovecot Package Update gibt, aber das scheint wohl nicht zu passieren. So genau kenne ich mich auch nicht mit den freezes von Testing releases aus und das Problem scheint wohl nicht immer zwangsläufig zum freeze zu führen.

Warum ich den Thread aber eigentlich aufmache:
Ich habe bisher noch nie ein patch eingespielt, was ich mit dem Ding da oben aber gerne machen würde. Bis auf ein paar für mich kryptische Hinweise, habe ich von Google auch nicht viel erfahren, bis auf das ich das Paket wohl manuell kompilieren muss. Da ist meine Erfahrung aber eher dünn und wenn auch nur mit Tutorials, was ja dann keien große Schwierigkeit darstellt, aber jetzt.. sieht es halt etwas anders aus.

Ein Downgrade kann ich wegen dem MariaDB Upgrade auch nicht in Betracht ziehen, die Situation ist also gerade ziemlich bescheiden. Selbst ein Serverumzug geht nicht, da zum erstellen von Backups die Kiste einfach nicht lange genug online ist.

Bin für jeden Ratschlag zu einer Vorgehensweise dankbar.
 
T

Till

Administrator
Was mich jetzt ertsmal wundert warum Du den fehler überhaupt hast, ich habe auch einige Debian Server mit Dovecot und kenne veiel Kunden die Debian 9 mit Dovecot einsetzen und kein Server friert ein. Hast Du Dovecot oder mariaDB aus anderen Quellen installiert und nicht die Original pakete von Debian?
 
O

Olli2k

Member
Hi Till, also zunächst mal ist der Fehler erst seit dem Upgrade auf Buster und ob es Dovecot ist kann ich auch nicht mit Sicherheit sagen. Im log finden sich aber entweder die Dovecot Fehler beim Freeze oder ISPCONFIG Cronlogs. Was ich auch noch für möglich halte ist, dass eventuell die Sury PHP Versionen von Stretch dafür verantwortlich sein könnten. Soweit ich mich da eingelsen habe, wird es kein Buster PHP 5.6 und 7.0 seitens Sury geben. Memcached hatte auch einige Fehler im Syslog, habe ich aber deinstalliert. Danach dachte ich schon, es lag daran, weil die Kiste dann mal über 12 Stunden lief, aber am nächsten Morgen war dann doch wieder ein Hard Reset angesagt.

Auf Dovecot bin ich eigentlich gekommen, weil es anfangs hin und wieder noch möglich war, direkt nach dem Freeze service Befhele in der Shell abzusetzen. Ein Dovecot restart sorgte dann dafür, dass sich der Freeze aufhob. Aber ob jetzt irgendetwas anderes den Auth Prozess in die Knie zwingt kann ich momentan nicht erkennen. Alle Indikatoren habe ich jetzt aber genannt.

Die Folgen sind natürlich fatal, vorgestern ist der Freeze bei einem Letsencrypt Cert Update passiert, danach ging dann gar nichts mehr.. Zumindest beim Apache2.

P.S.: Mir ist gerade aufgefallen, dass ich den schlimmen Fehler im 1. Beitrag gar nicht ausformuliert habe: Upgrade auf Testing (Buster)
 
T

Till

Administrator
Zitat von Olli2k:
P.S.: Mir ist gerade aufgefallen, dass ich den schlimmen Fehler im 1. Beitrag gar nicht ausformuliert habe: Upgrade auf Testing (Buster)
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Ok, das erklärt es. Buster setze ich noch nirgends ein und habe ISPConfig bislang auch noch nicht darauf getestet. Hast Du mal versucht Munin und Monit zu installieren, bei total vermurksten systemen kann man wenigstens teilweise wieder Stabilität erreichen wenn man die Prozesse automatisch überwacht mit monit und sofort killed bevor es ausufert. Das ist natürlich keine langfristige Lösung, schafft aber ggf., erstmal Luft zum nachdenken. Und Munin charts können helfen um zu sehen was da genau aus dem Ruder läuft.
 
O

Olli2k

Member
Glaub mir das Upgrade ist zu meinem absolutem Horror geworden.. Passiert mir bestimmt nie wieder..

Danke für den Tip, probiere ich natürlich.
 
O

Olli2k

Member
Ich habe jetzt munin und monit installiert.

Dabei habe ich mich an dein Tutorial gehalten:

Server Monitoring with Munin and Monit on Debian

This tutorial shows you how to use Munin and Monit to monitor your Debian Jessie server. Munin creates graphs from the collected data and Monit surveys services like ...
www.howtoforge.com

Allerdings habe ich beim Apache monit.pem key folgendes Problem:
openssl gendh 1024 >> /var/certs/monit.pem
Invalid command 'gendh'; type "help" for a list.

Apache Überwachung habe ich daher vorerst aktiviert, aber sonst alles andere aus der Beispiel Config aktiviert. Server ist jetzt ne Stunde ab, obwohl es seitens Monit keine Aktivitäten bis auf den Start gab. Durchschnittliche Uptime der letzten 3 Tage war eher so 5 Minuten.

Allerdings habe ich auch wieder eine IPSConfig Installation gemacht (reconfigure Services), letztes mal lief er danach auch fast 12 Stunden. Bin auf jeden Fall gespannt, ob es brauchbare Informationen gibt.
 
florian030

florian030

Well-Known Member
Das dürfte wohl daran liegen, dass das Tutoril nicht zu Deinem OS passt :)
Code: 
openssl dhparam -out /var/certs/monit.pem -2 1024
 
O

Olli2k

Member
Danke Florian. Dachte ich mir, allerdings hatte ich mir schon mit der pure-ftp.pem Datei geholfen. Das hatte auch geklappt.
Der Erfolg ist allerdings auch mit Monit und Munin ausgeblieben. Das System ist weiterhin extrem instabil. Zwar veschickt Monit reichlich Warnungen, aber mehr auch nicht. Entweder sind die definierten Regeln nicht ausreichend oder der schuldige Service wird nicht überwacht.

Auth Prozess geht im Top auf 100 und irgendwann ist dann Ende. Ich habe zwar schon etwas gesucht, allerdings war die Suche bisher erfolglos, welchen Service muss man für den auth Prozess neustarten?
 
Zuletzt bearbeitet:
O

Olli2k

Member
Gerade noch etwas gefunden, im Kernel Log wird bei einem Freeze folgendes angegeben:

Mar 18 16:51:42 isp3 kernel: [ 1934.578239] INFO: task md2_raid1:263 blocked for more than 120 seconds.
Mar 18 16:51:42 isp3 kernel: [ 1934.578305] Not tainted 4.19.0-2-amd64 #1 Debian 4.19.16-1
Mar 18 16:51:42 isp3 kernel: [ 1934.578363] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Danach folgt dann die gleiche Meldung für alle Prozesse apache2, dovecot etc.

@isp3 ~ # sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200

SInd ie Einstellungen so ok? Oder könnte das vielleicht doch defekte Hardware sein, die nur unglücklicherweise zum Upgradezeitpunkt den Geist aufgegeben hat?
 
O

Olli2k

Member
Code: 
martctl -a /dev/sdb


=== START OF INFORMATION SECTION ===
Model Family:     Toshiba 3.5" DT01ACA... Desktop HDD
Device Model:     TOSHIBA DT01ACA300
Serial Number:    534SUW3GS
LU WWN Device Id: 5 000039 ff4cad5aa
Firmware Version: MX6OABB0
User Capacity:    3.000.592.982.016 bytes [3,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Mon Mar 18 17:39:06 2019 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (23082) seconds.

gekürzt..

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_                                                         FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -                                                                0
  2 Throughput_Performance  0x0005   140   140   054    Pre-fail  Offline      -                                                                69
  3 Spin_Up_Time            0x0007   138   138   024    Pre-fail  Always       -                                                                398 (Average 435)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -                                                                28
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -                                                                0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -                                                                0
  8 Seek_Time_Performance   0x0005   124   124   020    Pre-fail  Offline      -                                                                33
  9 Power_On_Hours          0x0012   094   094   000    Old_age   Always       -                                                                44653
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -                                                                0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -                                                                14
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -                                                                149
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -                                                                149
194 Temperature_Celsius     0x0002   187   187   000    Old_age   Always       -                                                                32 (Min/Max 23/57)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -                                                                0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -                                                                0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -                                                                0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -                                                                0

SMART Error Log Version: 1
ATA Error Count: 21 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 21 occurred at disk power-on lifetime: 44324 hours (1846 days + 20 hours)
  When the command that caused the error occurred, the device was active or idle                                                         .

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 18 68 20 d9 09  Error: UNC at LBA = 0x09d92068 = 165224552

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 80 30 80 2e d9 40 00   4d+00:59:51.091  READ FPDMA QUEUED
  60 80 28 00 2e d9 40 00   4d+00:59:51.091  READ FPDMA QUEUED
  60 80 20 80 2d d9 40 00   4d+00:59:51.090  READ FPDMA QUEUED
  60 80 18 00 2d d9 40 00   4d+00:59:51.090  READ FPDMA QUEUED
  60 80 10 80 2c d9 40 00   4d+00:59:51.090  READ FPDMA QUEUED

Error 20 occurred at disk power-on lifetime: 44324 hours (1846 days + 20 hours)
  When the command that caused the error occurred, the device was active or idle                                                         .

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 48 b8 87 99 09  Error: UNC at LBA = 0x099987b8 = 161056696

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 80 00 00 92 99 40 00   4d+00:46:29.790  READ FPDMA QUEUED
  60 00 f0 00 8c 99 40 00   4d+00:46:29.790  READ FPDMA QUEUED
  60 00 e8 00 87 99 40 00   4d+00:46:29.790  READ FPDMA QUEUED
  61 05 e0 10 10 10 40 00   4d+00:46:29.790  WRITE FPDMA QUEUED
  ea 00 00 00 00 00 a0 00   4d+00:46:29.790  FLUSH CACHE EXT

gekürzt wegen 10k zeichen..


SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA                                                         _of_first_error
# 1  Extended offline    Completed without error       00%     37397         -
# 2  Extended offline    Completed without error       00%     37379         -
# 3  Extended offline    Completed without error       00%     36922         -
# 4  Extended offline    Completed without error       00%     36904         -
# 5  Extended offline    Completed without error       00%     35513         -
# 6  Extended offline    Completed without error       00%     35495         -
# 7  Extended offline    Completed without error       00%     32783         -
# 8  Extended offline    Completed without error       00%     32765         -
# 9  Extended offline    Completed without error       00%     32748         -
#10  Short offline       Completed without error       00%     32738         -
#11  Extended offline    Completed without error       00%       104         -
#12  Extended offline    Completed without error       00%         6         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Sind die UNC at LBA Hardwaredefekte oder defekte Daten aufgrund der ganzen Freezes?
 
O

Olli2k

Member
Also die Kiste ist "stabil".
Erste erhebliche Verbesserung habe ich mit den Einstellungen:

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
in /etc/sysctl.conf erreicht.

Damit haben die System Freezes aufgehört, zumindest bis jetzt.
Und letztendlich wurde in testing der dovecot bug gefixt, nachdem er als release critical eingestuft wurde, ging es dann doch fix.

Zufrieden bin ich mit dem System jetzt immer noch nicht, da rund laufen irgendwie anders ist. PHP FPM macht Probleme und der Apache streikt auch ab und an. Hier verrichtet aber Monit gute Deinste und die Ausfälle werden automatisch durch Restarts behoben.

Ich vermute das dafür die Sury PHP Stretch Pakete verantwortlich sind. Aktuell wird unter Buster nur 7.3 unterstützt. Sury bietet offiziell 7.2 und 7.1 für Buster an. Die Ankündigung es würde kein 5.6 und 7.0 für Buster geben wurde aber auch schon in einem Ticket getätigt. Da ich aber noch alte Stretch Pakete installiert habe, kann ich mir gut vorstellen, dass es hier eine Problemursache liegen könnte. Sowohl 7.0 als auch 5.6 laufen aktuell und sind mir auch sehr wichtig. Daher blicke ich gerade nicht sehr optimitisch in meine Debian Zukunft :(.

Bezüglich der Festplatten werde ich aber dennoch den Support kontaktieren und diese mal wechseln lassen.

Vielen Dank für alle Tipps die ich hier erhalten habe!
 
T

Till

Administrator
Mit Debian Zukunft hat das meines Erachtens nicht viel zu tun, alle neuen Distributionen werden PHP 7.3 haben, nicht nur Debian.

Das Problem ist einfach dass es immer noch viele Websites gibt, die nicht PHP 7.3 kompatibel sind, daher kommen die meisten Hoster nicht an min. einer php 5.x Version vorbei. Ich denke aber dass Du auch auf Debian 10 PHP 5.6 kompilieren können wirst, notfalls mit separat kompiliertem openssl und imap lib nur für diese PHP Version. Ich habe ja Anleitungen für Debian 9 auf howtoforge.com dazu veröffentlicht, Du kannst ja mal schauen in wieweit es damit auch noch auf Debian 10 geht.

Was die Sicherheitsproblematik angeht, ich habe regelmäßig mit gehackten Websites zu tun wenn mich Leute diesbezüglich um Hilfe bitten, aber die Seiten werden wegen Fehlern im PHP Code, also fehlerhaften CMS, Plugins, etc. gehacked und nicht wegen Fehlern in PHP selbst. Daher halte ich es für vertretbar noch ein PHP 5.6 einzusetzen wenn PHP 7.2 oder 7.3 nicht möglich sind, solange PHP unter einem nicht privilegierten user läuft und man den Server gut überwacht um schnell auf ungewöhnliches Verhalten reagieren zu können (was man ja eh tun sollte). Meiner Meinung nach hätte das PHP Team versuchen müssen PHP 5.6 noch länger mit Sicherheitspatches zu versorgen, wenn sie schon den Weg gehen PHP 7.x in vielen bereichen inkompatibel mit 5.x zu gestalten.
 
O

Olli2k

Member
Nette Impressionen und ich denke auch, dass das mit dem 5.6 auf Buster noch klappen wird. Aber mit den Sury Packages war das schon mega bequem. Allerdings wenn es keine Updates mehr gibt, ist unbequem ja auch in Ordnung.

Bei mir ist der Hauptgrund Nostalgie. Ich nutze den Server nicht gewerblich sondern hoste nur eigene Projekte und Webseiten von Freunden.

Da aber viele Projekte auf CMS Systemen basieren, die nur völlig verändert oder gar nicht auf aktuellen PHP Versionen laufen, wäre ein Verzicht auf 5.6 das aus für diese Seiten. Auch wenn viele nicht mehr aktiv sind, lasse sich ich Sie am Netz. Überwachen tue ich diese Accounts natürlich auch besonders und für Projekte ohne Aktivität sind zum Beispiel auch sämtliche Formulare, Registrierungen udn sonstige Möglichkeiten für das hinzufügen von Daten deaktiviert.

Die fehlende Abwärtskompatiblität von PHP ist mir bis heute sehr unverständlich, aber diese Entscheidungen wurden von Köpfen getroffen die da weitaus mehr Ahnung von haben als ich. Von daher kann man diese bittere Pille nur schlucken.

Aktuelle Überlegeng wäre vielleicht noch einen Virtuellen Server für eine PHP 5.6 Umgebung zu nutzen.
 
T

Till

Administrator
Was man gerade bei alten Seiten machen sollte ist eine WAF (Web Application Firewall) davor schalten, die kostenlose Variante wäre da mod_security. Da muss man zwar anfangs ein wenig Regeln whitelisten für bestimmte Unterseiten, aber dann läuft es gut und fängt den meisten Unsinn der so auf die Seite einprasselt ab.
 
O

Olli2k

Member
Zitat von Till:
Was man gerade bei alten Seiten machen sollte ist eine WAF (Web Application Firewall) davor schalten, die kostenlose Variante wäre da mod_security. Da muss man zwar anfangs ein wenig Regeln whitelisten für bestimmte Unterseiten, aber dann läuft es gut und fängt den meisten Unsinn der so auf die Seite einprasselt ab.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Kann man sich dafür hier noch dran orientieren, oder ist das nicht mehr up-to-date?
 
T

Till

Administrator
Ich würde an Deiner stelle nach was aktuellerem suchen, kanns ein dass sich da Pfade geändert haben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top