Server im deadlock

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Server im deadlock

Beitrag von mclien » 02.12.2018 14:26:39

Ich habe für mein heimnetzwerk einen Debianserver als Datensumpf und als internen IMAP Server.

Leider bleibt die Kiste alle paar Wochen komplett stehen. Sogar Tastatureingaben funktionieren nicht mehr. Auch mit Magig system kommands komme ich an nix mehr dran.
Schließe ich dann einen Monitor an, sehe ich die letzten Zeilen von einer Kernelpaic(?). Lauter Zeilen, die mit nem Hexcode beginnen.
Ich habe in keinem log irgendeinen Hinweis gefunden, also habe ich mein altes Monitoringsystem wieder aktiviert (checkMK/OMD).
Letzte Nacht hatte ich den Effekt wieder.
Leider habe ich auch dann keinen direkten Hinweis, weil das Monitoring Sytsem dann "nur noch" das Problem hat den Host nicht mehr zu erreichen.
Als ich in den Verlaufsdiagrammen von checkMK gesucht habe ist mir als einzigesProblem die CPU LOAD aufgefallen.
nachts um ~2:30 geht die CPU auf Vollast und der Rechner bleibt dann nach ca. 2 Std CPU Vollast stehen.

Ich habe jetzt keine Idee, wie ich das Problem weiter eingrenzen kann, bzw. wie ich rausfinde welcher Prozess denn die Last erzeugt.
Ein Cronjob, der alle 15min jeden Prozess in ein log schreibt, der mehr als 90% cpu beansprucht evtl?

DeletedUserReAsG

Re: Server im deadlock

Beitrag von DeletedUserReAsG » 02.12.2018 14:48:26

Systeminfos fehlen völlig.

Keine Hinweise im Log oder Journal (welches vorher natürlich persistent gemacht wurde), je nach System?

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 02.12.2018 20:55:00

OK, nächstes mal schreibe ich erst, wenn ich den Server wieder an habe..
Da hätten wir ein Supermicro Board, mit einen 4 Kern Intel(R) Atom(TM) CPU D510 @ 1.66GHz

Code: Alles auswählen

~# lspci
00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
04:04.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 (rev 0a)
Ist ein debian 7 mit 4 Platten, mit folgenden RAID1 :

Code: Alles auswählen

 cat /proc/mdstat 
Personalities : [raid1] 
md130 : active raid1 sda1[0] sdc1[1]
      2930133824 blocks super 1.2 [2/2] [UU]
      
md129 : active raid1 sdb4[0] sdd4[1]
      2856734720 blocks super 1.2 [2/2] [UU]
      bitmap: 0/22 pages [0KB], 65536KB chunk

md128 : active raid1 sdb3[0] sdd3[1]
      68702208 blocks super 1.2 [2/2] [UU]
      
md127 : active raid1 sdb1[0] sdd1[1]
      510912 blocks [2/2] [UU]
habe alle logs durchsucht, das einizg verdächtige was ich gefunden habe:

Code: Alles auswählen

Dec  2 00:57:07 moya kernel: [1923662.789795] md: data-check of RAID array md129
Dec  2 00:57:07 moya kernel: [1923662.789804] md: delaying data-check of md128 until md129 has finished (they share one or more physical units)
Dec  2 00:57:07 moya kernel: [1923662.789813] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Dec  2 00:57:07 moya kernel: [1923662.789821] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
Dec  2 00:57:07 moya kernel: [1923662.789834] md: using 128k window, over a total of 2856734720k.
Dort hört das messages auf. Das ist allerdings ~1,5h bevor die cpu lt. OMD auf 100% geht.

pferdefreund
Beiträge: 3791
Registriert: 26.02.2009 14:35:56

Re: Server im deadlock

Beitrag von pferdefreund » 03.12.2018 09:16:39

Ich würde als erstes mal memtest und smartctl befragen. Ich hatte es mal, dass meine Kiste hängen blieb, weil der Kernel bis zum bitteren Ende versucht hat, einen bad block zu lesen. Nachdem ich die per badblocks als fehlerhaft markiert hatte, hat es die Platte aber noch ca 10 Jahre getan. Damals habe ich vermutet, dass die durch einen Stromausfall entstanden sind.
Wenn die CPU ewig auf Vollgas läuft - kann es dann sein, dass da irgendwas einfach zu warm wird ?

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Server im deadlock

Beitrag von MSfree » 03.12.2018 09:28:10

pferdefreund hat geschrieben: ↑ zum Beitrag ↑
03.12.2018 09:16:39
Wenn die CPU ewig auf Vollgas läuft - kann es dann sein, dass da irgendwas einfach zu warm wird ?
Naja, nicht wirklich bei einem Atom D510 :wink:

Diese CPU ist übrigens nur ein Zweikerner mit Hyperthreading, so daß er von aussen aussieht wie ein Vierkerner. Das Ding hat 13W TDP und ist selbst unter Maximalauslastung locker mit dem vormontierten Passivkühlkörper kühlbar, zumindest, wenn im Gehäuse einigermassen Platz für Konvektion ist.

Im übrigen ist es bei einem Atom D510 keine große Kunst, den auf 90% Auslastung zu bringen, das sind halt keine schnellen Teile.

Defektes RAM oder ein defekter Sektor auf einer der Festplatten würde ich auch eher als Ursache vermuten als Wärmeprobleme.

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 03.12.2018 12:50:22

Ok, hatte ich jetzt nicht so explizit geasagt, aber:
Temperatur und smarctl habe ich ja mit dem Monitoring schon im Blick und da gab es keine Probleme.

Dann bliebe nur der memtest. Aber kann das wirklich zu CPU Last führen, wenn noch reichlich RAM frei ist?
Und mir ist schon klar, dass man den Atom schon schnell auf 90% bekommen kann. Allerdings kann ich ja den Verlauf der CPU Last noch recht weit zurückverfolgen im Monitoring (6 Wochen oder so). Und die meiste ist das nicht mal 2 stellig was da passiert..

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Server im deadlock

Beitrag von MSfree » 03.12.2018 13:39:37

mclien hat geschrieben: ↑ zum Beitrag ↑
03.12.2018 12:50:22
Temperatur und smarctl habe ich ja mit dem Monitoring schon im Blick und da gab es keine Probleme.
Nunja, ich persönlich bein kein Freund von S.M.A.R.T., das wirft mir zu viele false Positives und dient eher dazu, beim Endanwender Panik zu schüren, damit er viel zu früh seine Hardware erneuert. Andererseits bekommt man über S.M.A.R.T. längst nicht jeden Hardwaredefekt angezeigt. Für mich ist ads Snakeoil.
Aber kann das wirklich zu CPU Last führen, wenn noch reichlich RAM frei ist?
CPU-Last hat wenig mit dem freien RAM zu tun. Es ist sogar eher so, daß bei wenig freiem RAM die Kiste anfängt zu swappen, und damit fällt die CPU-Last sogar teilweise unter 2%, weil die CPU nur noch wartet statt zu arbeiten.
Allerdings kann ich ja den Verlauf der CPU Last noch recht weit zurückverfolgen ... Und die meiste ist das nicht mal 2 stellig was da passiert.
Hohe CPU-Last ist ja erstmal nichts ungewöhliches. Das Betriebssystem ist eigentlich immer bedacht, eine Aufgabe so schnell wie möglich abzuarbeiten, das produziert also immer eine (kurzfristige) Lastspitze mit 100% Auslastung, die durchaus auch nur ein paar Mikrosekunden dauern kann. Die angezeigte CPU-Auslastung ist nur ein über einen längeren Zeitraum (ein paar zehntel Sekunden) gemittelter Wert.

Hast du denn schonmal mit journalctl nachgesehen, ob da Auffälligkeiten drin stecken? IO-Error, (SATA) Bus-Resets und dergleichen werden da eigentlich protokolliert, sofern das System nicht zu dem Zeitpunkt einfriert, wenn gerade eine Logausgabe geschrieben werden soll.

Die Frage ist halt, was hat in dem Moment, als das System eingefroren ist, stattgefunden? Wenn da irgendwelche Schreibvorgänge aktiv waren, z.B. weil ein Cronjob ein Backup oder rsync angestossen hat, wären wir zumindest einen kleinen Schritt weiter.

Netzwerktechnisch ist die Kiste unauffällig? Keine "disconnect" oder "connect" Meldungen im Log?

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 03.12.2018 21:17:08

im log habe ich eben keine Hinweise gefunden, acuh nichts von dem jetzt noch erwähnten.

Daher fehlt mir ja quasi eine Idee, wie ich denn nun rausfinde, was genau um die Uhrzeit gelaufen ist. Daher rührte ja meine Idee extra per cron ein script zu starten, was aus top/atop o.ä. alles rausschreibt was über 70% Last erzeugt.
Was anderes ist mir bisher jedenfalls nicht eingefallen, um die Verdächtigen einzukreisen..

In welchem Packt ist journalctl ?
Wäre das eigentlcih nicht sinnig, wennd as als dependency mit einem journaling FS mitkommt?

(Oh, und der Quatsch, den ich mit RAM Verbrauch/CPU Lastvon mir gegeben habe, hätte mir schon selbst auffallen können, sorry)

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Server im deadlock

Beitrag von MSfree » 03.12.2018 21:42:28

mclien hat geschrieben: ↑ zum Beitrag ↑
03.12.2018 21:17:08
Daher rührte ja meine Idee extra per cron ein script zu starten, was aus top/atop o.ä. alles rausschreibt was über 70% Last erzeugt.
Dann schau dich lieber bei Debianacct um. Damit kannst du jeden Prozeßstart und -stop protokollieren lassen.
In welchem Packt ist journalctl ?
Das gehört zu systemd. Welche uralte Debianversion ist denn bei dir noch am Laufen, daß du das nicht findest? Mit einem journaling FS hat das jedenfalls nichts zu tun.

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 03.12.2018 22:01:38

OK, ist tatsächlich noch wheezy bei mir...

Allerdings wäre da ja auch kein systemd system draus geworden, denn installiert hatte ich da ursprünglich sicher speeze oder gar lenny. Und von da habe ich ein sys upgrde gemacht (ok offenbar in letzter Zeit nicht so sorgfältig).

hmm, das heißt ich müsste wenigstens zu jessy aupdaten, um acct zu haben.

Da muss ich vorher noch etwas umbauen...

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Server im deadlock

Beitrag von eggy » 03.12.2018 22:16:55

Sind die Probleme immer um die gleiche Zeit? Dann mal schauen, was an crobjobs eingetragen ist. Wenns wirklich nur alle paar Wochen ist, wär RAM eher ungewöhnlich, die Probleme sollten sonst öfter auftreten. Das lässt sich aber relativ einfach testen, memtest etc wurden ja schon genannt. Wie siehts aus, wenn Du der Kiste RAM entziehst? Große Ramdisk anlegen, mit Randomzeugs vollmalen, und darauf warten (aka irgendne Aktion anstossen, die viel Ram braucht), dass die Kiste ins Swappen/Thrashen gerät.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Server im deadlock

Beitrag von MSfree » 03.12.2018 22:40:29

mclien hat geschrieben: ↑ zum Beitrag ↑
03.12.2018 22:01:38
hmm, das heißt ich müsste wenigstens zu jessy aupdaten, um acct zu haben.
Nein, das gibt es schon sehr sehr lange und müßte auch für Wheezy nachinstallierbar sein. Allerdings mußt du wohl deinen sources.list auf archive.debian.org umstellen, damit du überhaupt noch Pakete nachinstallieren kannst.

ernstlx
Beiträge: 42
Registriert: 25.02.2011 01:15:44
Kontaktdaten:

Re: Server im deadlock

Beitrag von ernstlx » 04.12.2018 00:37:26

Zunächst, ich würde wegen diesem Problem nicht auf systemd umsteigen, wiewohl ein Upgrade auf Jessie doch wichtig wäre, da der Support für Wheezy bereits beendet ist.

Aber zum Problem:
Sind die Probleme immer um die gleiche Zeit? Dann mal schauen, was an crobjobs eingetragen ist.
Vor allem wann laufen die cronjobs? Immer in der Nacht klingt stark nach einem cronjob.

Code: Alles auswählen

cat /etc/crontab
Ich nehme an, bei einem Server verwendest du nicht anacron. Sonst müsstest du dort nachsehen.

Code: Alles auswählen

cat /etc/anacrontab
Andere Ideen (Brainstorming):
- Macht der Mailserver irgendwelche Virenchecks?
- Von wegen SMART: laufen irgendwelche offline selftests? Das sollte zwar nichts mit CPU-Last zu tun haben, aber als ich das letzte mal einen Bildschirm mit Hexadezimalzahlen geflutet sah, hatte sich die Systemfestplatte vom Dienst abgemeldet. Und die selftests habe ich inzwischen stark reduziert, da meine Festplatten dabei unnatürlich laute Geräusche von sich geben.
- Werden sehr große Logfiles geschrieben? Bei meinem Router habe ich versehentlich zu viele Firewall-Informationen gesammelt und dabei in einer Woche ein 20 GB großes Logfile erzeugt. Die Manipulation solch einer Text-Datei ist durchaus herausfordernd.

Welche Server laufen noch?

Die CPU ist wohl nicht sehr leistungsstark, aber ich verwende einen Atom 330, der noch ein Stück schwächer ist, aber die meisten Server erzeugen nicht viel Last und selbst wenn, sollte das nicht zu einem Absturz führen. Ein Hardwareproblem halte ich für durchaus wahrscheinlich.
Desktop: Intel i5-6600T@2,7GHz, ASRock Z170 Extreme4, 8GB RAM, Samsung 970 Evo SSD, Debian Stretch (64-bit), Xfce
Notebook: HP 2540p, Intel i5-540M@2,53GHz mit GMA HD Graphik, 4GB RAM, Intel SSD SAM080, Debian Jessie (64-bit), Xfce
Router/Server: Intel D945GCLF2 ITX-Board mit Atom 330@1,6GHz, 2GB RAM, Samsung 860 Evo SSD, Debian Stretch (32-bit), -

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Server im deadlock

Beitrag von MSfree » 04.12.2018 08:27:07

ernstlx hat geschrieben: ↑ zum Beitrag ↑
04.12.2018 00:37:26
Die CPU ist wohl nicht sehr leistungsstark, aber ich verwende einen Atom 330, der noch ein Stück schwächer ist
Der Atom 330 und der Atom D510 unterscheiden sich darin, daß der D510 einen Graphikkern auf dem Die hat, ansonsten sind sie technisch identisch, und 4% mehr Takt macht nun wirklich keinen Unterschied.
aber die meisten Server erzeugen nicht viel Last und selbst wenn, sollte das nicht zu einem Absturz führen.
Richtig, für viele Zwecke ist so eine CPU völlig ausreichend und auch Last darf keinen Absturz erzeugen.
Ein Hardwareproblem halte ich für durchaus wahrscheinlich.
Das scheint ja ohnehin ein sporadisches Problem zu sein. Ich erinnere mich gerade wieder an meinen alten Router (600MHz VIA Epia), der dieses Jahr zusammengebrochen ist. Da fing es auch mit sporadischen Abstürzen alle paar Wochen an. Die Abstürze kamen dann in immer kürzeren Abständen und ganz zum Schluß habe ich dann beim Anschalten Elkos pfeifen hören. Da war klar, was die Ursache war und das Gerät wurde nach 13 Jahren Dauerbetrieb ersetzt.

Das Alter des Atom D510 (erschienen im Januar 2010) würde auch ganz gut zu langsam sterbenden Elkos passen.

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 04.12.2018 20:21:04

Eine Ergänzung, die ich bisher nicht erwähnt hatte, sorry:
Das Problem ist nicht neu, es besteht schon seit langem. bei 3-5 Mal resetten im Jahr war es halt nicht soo deängen, aber jetzt will ich das Rätsel irgendwie mal lösen.

Code: Alles auswählen

cat /etc/crontab
# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
ist unverändert von der debian Inst.übernommen.

Zur Hardware:
Ursprünglich was das ein 1HE Server von Thomas Krenn, das Board habe ich aber in ein anders Gehäuse gebaut, um die 4-6 Platten betreiben zu können. Und das darin verbaute Board von Supermicro halte ich jetzt mal für etwas hoch-qualitatives.

Zu den laufenden Servern:
-Mailserver macht keine Viruschecks.
-große Logfiles werden nicht geschrieben
-es läuft noch ein NFS Server

SMART: hier ist der entscheidene (und einzig einkommentoerte) Snipsel

Code: Alles auswählen

# The word DEVICESCAN will cause any remaining lines in this
# configuration file to be ignored: it tells smartd to scan for all
# ATA and SCSI devices.  DEVICESCAN may be followed by any of the
# Directives listed below, which will be applied to all devices that
# are found.  Most users should comment out DEVICESCAN and explicitly
# list the devices that they wish to monitor.
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runne

ernstlx
Beiträge: 42
Registriert: 25.02.2011 01:15:44
Kontaktdaten:

Re: Server im deadlock

Beitrag von ernstlx » 05.12.2018 01:18:39

Naja, wenn es langsam schlimmer geworden ist, spricht natürlich sehr viel für einen Hardware-Schaden.

Cron scheidet also aus - alles nach 6 Uhr. Um 2:30 ist gar nichts (außer stündlichen Jobs, falls es die überhaupt gibt).

Bei der Default-Konfiguration von smartd.conf werden akut auftretende Fehler an ein Script namens smartd-runner übergeben (ich hoffe, da fehlt ein "r" am Ende) und da steht drin, dass run-parts alle Scripte in /etc/smartmontools/run.d mit den SMART-Meldungen als Argument ausführen soll ...
Jedenfalls sind keine Selftests programmiert - scheidet also auch aus.

Logrotate entfaltet seine Aktivitäten auch mit cron. Also erst am frühen morgen. Außerdem wären Probleme allenfalls zu erwarten, wenn wirklich große Logfiles z.B. komprimiert werden. (ich habe übrigens übertrieben - mein Shorewall-Logfile war bloß knapp über 6 GB groß ...)

Keine weiteren Server (NFS-Server wird nachts nichts tun) ... was also kann die CPU mitten in der Nacht beschäftigen? Spannend.

Welcher Mailserver läuft? Was tut er?
Welche Prozesse laufen? Vielleicht nur mal

Code: Alles auswählen

ps -e
Desktop: Intel i5-6600T@2,7GHz, ASRock Z170 Extreme4, 8GB RAM, Samsung 970 Evo SSD, Debian Stretch (64-bit), Xfce
Notebook: HP 2540p, Intel i5-540M@2,53GHz mit GMA HD Graphik, 4GB RAM, Intel SSD SAM080, Debian Jessie (64-bit), Xfce
Router/Server: Intel D945GCLF2 ITX-Board mit Atom 330@1,6GHz, 2GB RAM, Samsung 860 Evo SSD, Debian Stretch (32-bit), -

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 06.12.2018 19:46:13

ernstlx hat geschrieben: ↑ zum Beitrag ↑
05.12.2018 01:18:39
Naja, wenn es langsam schlimmer geworden ist, spricht natürlich sehr viel für einen Hardware-Schaden.
Ist es nicht, ich habe halt bisher einfach einen reset gemacht.
Keine weiteren Server (NFS-Server wird nachts nichts tun) ... was also kann die CPU mitten in der Nacht beschäftigen? Spannend.
Und das halt nur alle paar Wochen...
Welcher Mailserver läuft? Was tut er?
dovecot, versorgt 4-6 Mailpostfächer, die nur im internen Netz abgerufen werden.
Einsammeln tue ich das per getmail und cron
.....FCK, jetzt wo ich es schreibe...
Ich Pfuscher habe dem script, das den getmail Aufruf macht, keine Kontrolle verpasst, ob der vorherige cronjob noch läuft....
-> wenn der nach 3 Minuten noch nicht fertig ist und cron dann den nächsten Job startet, könnte ich natürlich irgendwann das System durch zu viele Prozesse blocken.
Allerdings müsste ich dann im Monitoring sehen, dass die Anzahl der CPU Threads auf "critical" springt, oder? was sie aber lt. Monitor History nicht gemacht hat.
Welche Prozesse laufen? Vielleicht nur mal

Code: Alles auswählen

ps -e
http://nopaste.debianforum.de/40513

ernstlx
Beiträge: 42
Registriert: 25.02.2011 01:15:44
Kontaktdaten:

Re: Server im deadlock

Beitrag von ernstlx » 06.12.2018 21:26:42

habe dem script, das den getmail Aufruf macht, keine Kontrolle verpasst, ob der vorherige cronjob noch läuft....
Welcher vorherige cronjob? Was sind das für cronjobs? cron.hourly, cron.daily? Dafür wären dann eigentlich die cronjobs der Clients interessant.
run-parts führt die jobs, glaube ich, wirklich hintereinander aus oder macht da dein Skript etwas parallel?
Desktop: Intel i5-6600T@2,7GHz, ASRock Z170 Extreme4, 8GB RAM, Samsung 970 Evo SSD, Debian Stretch (64-bit), Xfce
Notebook: HP 2540p, Intel i5-540M@2,53GHz mit GMA HD Graphik, 4GB RAM, Intel SSD SAM080, Debian Jessie (64-bit), Xfce
Router/Server: Intel D945GCLF2 ITX-Board mit Atom 330@1,6GHz, 2GB RAM, Samsung 860 Evo SSD, Debian Stretch (32-bit), -

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 07.12.2018 09:41:37

Ich habe root eine crontab verpasst, die die Mails von den Servern abholt und dann im localen IMAp Server zur verfügung stellt.
Ich führe alle 3 min das hier aus:

Code: Alles auswählen

/usr/bin/getmail -q --getmaildir=/etc/.getmail -d --rcfile getmailrc.user
ursprünglich waren das mal 6 user die so abgewickelt wurden, momentan ist es nur noch einer. Das sit eine Altlast, die ich eh noch loswerden will.

Wenn jetzt der getmail Abruf länger als 3 min läuft, wird er halt nochmal aufgerufen, obwohl er schon läuft. Das kann dann dazu führen, dass die Anzahl der Prozesse ständig ansteigt und irgendwann nichts mehr geht.
-> ist momentan zumindest die einzige Idee, die ich habe.
Ich könnte jetzt "einfach" den letzten verbelibenden IMAP user umziehen und den IMAP Server samt getmail entfernen und abwarten was passiert....

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Server im deadlock

Beitrag von MSfree » 07.12.2018 09:58:30

mclien hat geschrieben: ↑ zum Beitrag ↑
07.12.2018 09:41:37
Ich führe alle 3 min das hier aus:

Code: Alles auswählen

/usr/bin/getmail -q --getmaildir=/etc/.getmail -d --rcfile getmailrc.user
getmail lastet deinen Rechner mit absoluter Sicherheit nicht aus, dazu kommen die Daten viel zu langsam an deinem Rechner an. Auf meinem alten VIA Epia hat die CPU-Last beim Post abholen auch nur maximal 10% ausgemacht, und die CPU war um eine Größenordnung langsamer.

Auch eine Überlappung durch ein noch nicht abgeschlossenes getmail mit einem 3 Minuten später gestarteten getmail ist kein Problem. getmail erzeugt sich normalerweise ein lockfile, das der spätergestartete getmail erkennt und sich dann einfach unverrichteter Dinger beendet.

Abgesehen davon halte ich 3 Minuten für sehr kurz. Nichts in der Welt kann so wichtig sein, daß es bei Emails, die ja kein Real-Time-Medium sind, auf ein paar Minuten mehr oder weniger ankäme. Wenn es auf jede Sekunde ankommt, greifen die Leute sowieso zum Telefon (und fragen, ob du ihre Email schon gelesen hast :mrgreen: :facepalm: )

Vielleicht wäre auch fetchmail eine Alternative für dich. Das kann man direkt als Daemon laufen lassen und braucht dadurch kein cron, was Überlappungen zuverlässig verhindert.

mludwig
Beiträge: 793
Registriert: 30.01.2005 19:35:04

Re: Server im deadlock

Beitrag von mludwig » 07.12.2018 16:52:47

Mehrere Platten mit mdadm? mdadm läuft am 1. Sonntag jeden Monats los und führt ein checkarray aus ... kommt automatisch mit. Würde für alle paar Wochen (4) sprechen.

Code: Alles auswählen

cat /etc/cron.d/mdadm 
#
# cron.d/mdadm -- schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft <madduck@madduck.net>
# distributed under the terms of the Artistic Licence 2.0
#

# By default, run at 00:57 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 07.12.2018 18:36:28

mludwig hat geschrieben: ↑ zum Beitrag ↑
07.12.2018 16:52:47
Mehrere Platten mit mdadm? mdadm läuft am 1. Sonntag jeden Monats los und führt ein checkarray aus ... kommt automatisch mit. Würde für alle paar Wochen (4) sprechen.
Einerseits könnte das passen:
1 Plattenpaar mit 1 RAID Device
1 Plattenpaar mit 3 RAID Devices
(alle Platten sind 3 TB Platten)

andererseits startet das Problem erst um 2:50 und davor ist die CPU Last sogar 1 Stunde lang geringer, als den restlichen Tag.

mludwig
Beiträge: 793
Registriert: 30.01.2005 19:35:04

Re: Server im deadlock

Beitrag von mludwig » 07.12.2018 19:57:26

Ich hätte jetzt erwartet, dass du prüfts ob:
a) es solche einen (oder vielleicht andere ähnliche) cronjob bei dir gibt
b) ob deine Ausfälle immer am 1. Sonntag des Monats stattgefunden haben.

mdadm prüft die vorhandenen MD-Devices nacheinander, d. h. es ist durchaus möglich das zunächst eine Prüfung läuft, die unauffällig ist, und das 2. oder 3. MD-Device dann dein Problem verursacht.

mclien
Beiträge: 2427
Registriert: 06.12.2005 10:38:46
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Baustelle

Re: Server im deadlock

Beitrag von mclien » 08.12.2018 12:05:21

Oh, ich dachte das sei implizit klar..
Also ja, es gibt den cronjob, allerdings, tritt das Problem, wie beschrieben 2Std später auf, mit vorheriger Verringerung der CPU Last.

Ich sekĺbt habe die Ausfälle jetzt nicht dokumentiert, weil sie so selten waren. Und meine Serverüberwachung läuft leider noch nicht lange genug, dass ich schauen könnte, wann die Ausfälle waren.
Gibt es irgendwo eine stelle im System, die die Uhrzeiten der Rechnerstarts dokumentiert?

mludwig
Beiträge: 793
Registriert: 30.01.2005 19:35:04

Re: Server im deadlock

Beitrag von mludwig » 08.12.2018 13:05:27

last -x

zeigt bei mir zumindest die (Re)boots und Logins an, ich weiß aber nicht wie weit das zurückreicht.

Antworten