Server im deadlock

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
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: 2292
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: 2292
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....

MSfree
Beiträge: 4040
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: 546
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: 2292
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: 546
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: 2292
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: 546
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.

mclien
Beiträge: 2292
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 23:39:04

mludwig hat geschrieben: ↑ zum Beitrag ↑
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.
Leider nicht lange genug... In meinem Fall ist nur der letzte Deadlock vom 2.12. gelistet.

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

Re: Server im deadlock

Beitrag von mludwig » 09.12.2018 09:43:38

Dann kannst du entweder bis zum nächsten Mal warten, (6.01.19) oder checkarray mal manuell aufrufen.

Code: Alles auswählen

/usr/share/mdadm/checkarray --all 
Wenn das sauber durchläuft, liegt es an was anderem ...

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

Re: Server im deadlock

Beitrag von mclien » 14.12.2018 11:11:16

Also irgendwelche regelmäßigen Dinge kann ich jetzt schonmal ausschließen:
Do um 8:20 stand der Server und heute (also 3Tage später) wieder. Beim 2.Mal habe ich nicht mal mehr eine Ausgabe auf dem Monitor mehr bekommen.
Am Di sah das ganze aus: [image]http://iibi.de/zeug/server_absturz.jpeg[/image]
Und jetzt findet sich auch was im syslog:

Code: Alles auswählen

head -50 /var/log/syslog
Dec 13 06:36:01 moya /USR/SBIN/CRON[22541]: (root) CMD (/root/getmail.sh)
Dec 13 06:36:54 moya kernel: [907208.555398] BUG: unable to handle kernel NULL pointer dereference at           (null)
Dec 13 06:36:54 moya kernel: [907208.555433] IP: [<ffffffff81084264>] proc_cgroup_show+0x36/0x1ba
Dec 13 06:36:54 moya kernel: [907208.555461] PGD 800000013778a067 PUD 13837c067 PMD 0 
Dec 13 06:36:54 moya kernel: [907208.555487] Oops: 0002 [#1] SMP 
Dec 13 06:36:54 moya kernel: [907208.555505] CPU 2 
Dec 13 06:36:54 moya kernel: [907208.555514] Modules linked in: parport_pc ppdev lp parport nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 jbd loop i2c_i801 snd_pcm snd_page_alloc snd_timer snd soundcore evdev coretemp pcspkr i2c_core iTCO_wdt iTCO_vendor_support processor button thermal_sys ext4 crc16 jbd2 mbcache cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod raid1 md_mod sg sd_mod crc_t10dif ahci libahci uhci_hcd libata scsi_mod ehci_hcd usbcore e1000e usb_common [last unloaded: scsi_wait_scan]
Dec 13 06:36:54 moya kernel: [907208.555767] 
Dec 13 06:36:54 moya kernel: [907208.555778] Pid: 22637, comm: smart Not tainted 3.2.0-5-amd64 #1 Debian 3.2.96-3 Supermicro X7SPA-HF/X7SPA-HF
Dec 13 06:36:54 moya kernel: [907208.555812] RIP: 0010:[<ffffffff81084264>]  [<ffffffff81084264>] proc_cgroup_show+0x36/0x1ba
Dec 13 06:36:54 moya kernel: [907208.555840] RSP: 0018:ffff880139b27e28  EFLAGS: 00010246
Dec 13 06:36:54 moya kernel: [907208.555857] RAX: 0000000000000000 RBX: ffff8801385a3080 RCX: 0000000000000000
Dec 13 06:36:54 moya kernel: [907208.555876] RDX: 0000000000000000 RSI: 00000000000dd7c8 RDI: ffffffff817b96c0
Dec 13 06:36:54 moya kernel: [907208.555924] RBP: ffff88013af9b7c0 R08: 00000000000000d0 R09: 000000000000000a
Dec 13 06:36:54 moya kernel: [907208.555971] R10: ffff8801373df440 R11: ffff8801373df440 R12: 0000000000000000
Dec 13 06:36:54 moya kernel: [907208.556027] R13: 0000000000000000 R14: ffff8801385a32a8 R15: 00007f829de5f9d0
Dec 13 06:36:54 moya kernel: [907208.556083] FS:  00007f829de5f700(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
Dec 13 06:36:54 moya kernel: [907208.556133] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Dec 13 06:36:54 moya kernel: [907208.556164] CR2: 0000000000000000 CR3: 000000013970a000 CR4: 0000000000000670
Dec 13 06:36:54 moya kernel: [907208.556212] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec 13 06:36:54 moya kernel: [907208.556259] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Dec 13 06:36:54 moya kernel: [907208.556307] Process smart (pid: 22637, threadinfo ffff880139b26000, task ffff88013af9b7c0)
Dec 13 06:36:54 moya kernel: [907208.556356] Stack:
Dec 13 06:36:54 moya kernel: [907208.556379]  ffffffff810872b5 ffff8801385a3080 0000000001200011 ffff8801385a3080
Dec 13 06:36:54 moya kernel: [907208.556440]  ffffffff81046ff7 ffffffff8135918e ffff88013af9b7c0 ffff8801fffffff5
Dec 13 06:36:54 moya kernel: [907208.556499]  00007ffe302a5360 ffff880139b27f58 0000000000000000 ffff880138795a40
Dec 13 06:36:54 moya kernel: [907208.556559] Call Trace:
Dec 13 06:36:54 moya kernel: [907208.556588]  [<ffffffff810872b5>] ? cgroup_fork+0x2e/0x4e
Dec 13 06:36:54 moya kernel: [907208.556624]  [<ffffffff81046ff7>] ? copy_process+0x511/0x10e8
Dec 13 06:36:54 moya kernel: [907208.556659]  [<ffffffff8135918e>] ? do_page_fault+0x30a/0x345
Dec 13 06:36:54 moya kernel: [907208.556693]  [<ffffffff81047cd8>] ? do_fork+0xe1/0x249
Dec 13 06:36:54 moya kernel: [907208.556726]  [<ffffffff81037e4a>] ? should_resched+0x5/0x23
Dec 13 06:36:54 moya kernel: [907208.556761]  [<ffffffff81057f2d>] ? set_current_blocked+0x2d/0x43
Dec 13 06:36:54 moya kernel: [907208.556796]  [<ffffffff8135b553>] ? stub_clone+0x13/0x20
Dec 13 06:36:54 moya kernel: [907208.556828]  [<ffffffff8135b212>] ? system_call_fastpath+0x16/0x1b
Dec 13 06:36:54 moyDec 13 19:50:16 moya kernel: imklog 5.8.11, log source = /proc/kmsg started.
Dec 13 19:50:16 moya rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="5141" x-info="http://www.rsyslog.com"] start
Dec 13 19:50:16 moya kernel: [    0.000000] Initializing cgroup subsys cpuset
Die letzten beiden Zeilen sind dann schon der Neustart (allerdings der von gestern)
Das Monitoring meldet den "Ups" als critical.
Heute ist die letzte Zeiel vor dem Stillstand die hier:

Code: Alles auswählen

Dec 14 03:00:01 moya /USR/SBIN/CRON[19165]: (root) CMD (/root/getmail.sh)
Ich denke ich mache wohl doch erstmal das Update auf Debian 8, denn jetzt habe ich ja zum erstem Mal einen Hinweis auf einen Bug im Kernel

Antworten