moin,
ich freu mich bei solchen problemen bei euch zu sein.
sowas lernt man anscheint nur hier.
wir hatte grade ein problem mit srv01
tail /var/log/syslog
[...] systemd[1]: Looping too fast. Throttling execution a little.
[...]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789796#40
die lösung war
systemctl daemon-reexec
hmm da hat systemd mit jounald anscheint einen bug!?
dannach habe ich noch php5-fpm neu getartet.
meinen test nach geht alels wieder.
Zitat von picard <freifunk@fr32k.de>:
dannach habe ich noch php5-fpm neu getartet.
ich muss mich berichtigen bjo war auch zur gleichen zeit auf dem srv01
und schrieb mir eine mail auf dem srv das er auch neustartete.
btw: das ist auch ein riesen vorteil von user verwaltung:
mails auf den srv 
Zitat von picard <freifunk@fr32k.de>:
dannach habe ich noch php5-fpm neu getartet.
meinen test nach geht alels wieder.
nicht ganz, nginx ist noch ganz schön langsam.
den habe ich auch noch neu gestartet mit php5-fpm zusammen.
aber ihrgendwas läuft da immer noch nicht ganz rund.
lassen wir der maschine noch mal paar minuten... so langsam wird es wieder normal.
Zitat von picard <freifunk@fr32k.de>:
aber ihrgendwas läuft da immer noch nicht ganz rund.
lassen wir der maschine noch mal paar minuten... so langsam wird es wieder normal.
systemctl --failed
hat mir gezeigt das ein paar services nicht gestartet wurden.
diese habe ich von hand gestartet, aber immer noch läuft srv01 bescheiden (nginx).
journalctl -b
zeigte mir das wie immer php5-fpm und einige andere dingen icht hoch bekommen sind nach dem reboot heute nacht.
wieso eigendlich ein reboot?
wurde der manuell gemacht oder der srv01 alleine?
/lib/systemd/system/php5-fpm.service
habe ich bearbeitet, wasi ch gemacht habe steht kommentiert drin,
ich mache mal einen (kontrollierten) reboot
um zu sehen ob jetzt alles hoch kommt.
ich bin weiter dran.
Zitat von picard <freifunk@fr32k.de>:
systemctl --failed
auch nach dem reboot kammen einige servies nicht hoch.
die mussten von hand gestartet werden.
php5-fpm, zerobin, spamassassin
journalctl -b
Dez 23 13:52:14 srv01.ffnw.de cron[836]: Error: bad username; while reading /etc/cron.d/partkeepr
Dez 23 13:52:15 srv01.ffnw.de smartd[821]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Dez 23 13:52:15 srv01.ffnw.de smartd[821]: Problem creating device name scan list
Dez 23 13:52:15 srv01.ffnw.de smartd[821]: In the system's table of devices NO devices found to scan
Dez 23 13:52:21 srv01.ffnw.de rc.local[838]: sh: 0: Can't open /etc/fastd/ffol/up.sh
Dez 23 13:52:21 srv01.ffnw.de systemd[1]: rc-local.service: control process exited, code=exited status=127
Dez 23 13:52:21 srv01.ffnw.de systemd[1]: Failed to start /etc/rc.local Compatibility.
Dez 23 13:52:21 srv01.ffnw.de systemd[1]: Unit rc-local.service entered failed state.
Dez 23 13:52:27 srv01.ffnw.de spamass-milter[1014]: spamass-milter 0.3.2 starting
Dez 23 13:53:34 srv01.ffnw.de systemd[1]: php5-fpm.service start operation timed out. Terminating.
Dez 23 13:53:39 srv01.ffnw.de sshd[1365]: Connection closed by 62.75.151.93 [preauth]
Dez 23 13:53:46 srv01.ffnw.de systemd[1]: spamassassin.service start operation timed out. Terminating.
Dez 23 13:53:46 srv01.ffnw.de systemd[1]: Failed to start Perl-based spam filter using text analysis.
Dez 23 13:53:46 srv01.ffnw.de systemd[1]: Unit spamassassin.service entered failed state.
Dez 23 13:55:04 srv01.ffnw.de systemd[1]: php5-fpm.service stop-final-sigterm timed out. Killing.
Dez 23 13:55:05 srv01.ffnw.de systemd[1]: php5-fpm.service: main process exited, code=killed, status=9/KILL
Dez 23 13:55:05 srv01.ffnw.de systemd[1]: Failed to start The PHP FastCGI Process Manager.
Dez 23 13:55:05 srv01.ffnw.de systemd[1]: Unit php5-fpm.service entered failed state.
das müssen wir uns unbedingt anschauen!
Zitat von picard <freifunk@fr32k.de>:
journalctl -b
Dez 23 13:52:14 srv01.ffnw.de cron[836]: Error: bad username; while reading /etc/cron.d/partkeepr
habe erstmal "root" eingetragen.
es sollte einen eigenen user geben, root hat zu viel rechte.
Dez 23 13:52:15 srv01.ffnw.de smartd[821]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Dez 23 13:52:15 srv01.ffnw.de smartd[821]: Problem creating device name scan list
Dez 23 13:52:15 srv01.ffnw.de smartd[821]: In the system's table of devices NO devices found to scan
sudo systemctl disable smartd.service
Dez 23 13:52:21 srv01.ffnw.de rc.local[838]: sh: 0: Can't open > /etc/fastd/ffol/up.sh
den path /etc/fastd/ffol gibt es nicht mehr!
aber /etc/fastd/ffnw/up.sh
habe /etc/ff/ffolgate.sh
abgeändert auf
/etc/fastd/ffnw/up.sh
Dez 23 13:52:27 srv01.ffnw.de spamass-milter[1014]: spamass-milter 0.3.2 starting
Dez 23 13:53:34 srv01.ffnw.de systemd[1]: php5-fpm.service start operation timed out. Terminating.
Dez 23 13:53:46 srv01.ffnw.de systemd[1]: spamassassin.service start operation timed out. Terminating.
Dez 23 13:53:46 srv01.ffnw.de systemd[1]: Failed to start Perl-based spam filter using text analysis.
Dez 23 13:53:46 srv01.ffnw.de systemd[1]: Unit spamassassin.service entered failed state.Dez 23 13:55:04 srv01.ffnw.de systemd[1]: php5-fpm.service stop-final-sigterm timed out. Killing.
Dez 23 13:55:05 srv01.ffnw.de systemd[1]: php5-fpm.service: main process exited, code=killed, status=9/KILL
Dez 23 13:55:05 srv01.ffnw.de systemd[1]: Failed to start The PHP FastCGI Process Manager.
Dez 23 13:55:05 srv01.ffnw.de systemd[1]: Unit php5-fpm.service entered failed state.
hierzu bitte hilfe
Kann dort raus, war für den GW Betrieb nur!
smartmontools kann eh runter, da Virtualisierung.
/etc/rc.local
das GW zeugs habe ich auskommentiert
habe erneut noch mal rebootet es wird immer besser
aber
php5-fpm.service start operation timed out. Terminating.
spamassassin.service start operation timed out. Terminating.
die beiden services wollen nicht beim booten hoch kommen.
dann gibt es aktuell noch ein problem
der ping auf den srv01 ist schlecht.
dann gibt es aktuell noch ein problem
der ping auf den srv01 ist schlecht.
Ist er?
bjo@ostrea ~ % mtr -r srv01.ffnw.de
Start: Wed Dec 23 21:23:02 2015
HOST: ostrea Loss% Snt Last Avg Best Wrst
StDev
1.|--
??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- 10.96.89.154 0.0% 10 62.8 73.2 45.9
146.2 30.1
3.|--
89.15.232.17 0.0% 10 82.7 57.1 42.2 93.1 18.0
4.|--
89.15.232.3 0.0% 10 80.6 54.5 42.1 80.6 14.4
5.|--
213.20.91.225 0.0% 10 89.8 62.1 39.7 89.8 16.0
6.|-- et-7-1-0-
0.0001.prrx.13.f 0.0% 10 59.7 67.0 49.9 93.1 16.3
7.|-- et-7-1-0-0.0001.prrx.13.f 0.0% 10 56.2 85.0 50.1
139.6 27.9
8.|-- gw-decix.ffm.netcup.net 0.0% 10 53.8 85.1 53.8
178.5 36.3
9.|-- srv01.ffnw.de 0.0% 10 65.6 84.9 52.6
187.9 43.6
war er, bei 1k pings war der Avg bei ~200ms.
deswegen auch im anderen tread hilkos odoo sei kapput
viel wichtiger ist aber was machen wir mit den services die nicht hoch
kommen?
php5-fpm.service start operation timed out. Terminating.
spamassassin.service start operation timed out. Terminating.
Zitat von Bjoern Franke <bjo@nord-west.org>:
dann gibt es aktuell noch ein problem
der ping auf den srv01 ist schlecht.
Ist er?
heute ist der ping zu srv01 und von srv01 weg
soweit normal, aber packet verluste nahe 10% in beide richtungen.
Zitat von picard <freifunk@fr32k.de>:
heute ist der ping zu srv01 und von srv01 weg
soweit normal, aber packet verluste nahe 10% in beide richtungen.
(h)top, iftop, nmon
CPU/RAM, DiskIO und Netzwerk
nichts zeigt wieso der Vserver so langsam ist.
aus meiner sicht zum srv01
pic@nas:~$ mtr -c 100 -r srv01.ffnw.de
HOST: nas Loss% Snt Last Avg Best Wrst StDev
1.|-- openwrt.lan 0.0% 100 0.4 0.3 0.3 0.4 0.0
2.|-- firewall.lan 0.0% 100 0.4 0.5 0.4 0.8 0.1
3.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
4.|-- 83-169-159-134.static.sup 0.0% 100 8.1 9.6 7.4 35.1 3.4
5.|-- ip5886c327.dynamic.kabel- 0.0% 100 19.2 13.1 8.0 75.4 10.0
6.|-- ip5886c329.dynamic.kabel- 0.0% 100 16.2 17.2 15.5 22.6 1.4
7.|-- ip5886ee15.dynamic.kabel- 0.0% 100 21.7 22.8 19.4 28.3 1.7
8.|-- ip5886ca34.dynamic.kabel- 0.0% 100 25.0 25.0 23.6 27.5 0.8
9.|-- ip5886eacf.dynamic.kabel- 0.0% 100 22.5 22.8 21.4 27.7 0.9
10.|-- ae0-429.fra20.core-backbo 0.0% 100 24.1 24.0 19.1 45.5 4.1
11.|-- ae3-2003.nbg40.core-backb 0.0% 100 30.3 31.3 27.8 63.8 4.1
12.|-- gw-cb40.nbg.netcup.net 0.0% 100 30.6 27.2 23.7 58.0 4.8
13.|-- srv01.ffnw.de 0.0% 100 30.4 32.4 28.9 63.9 6.1
vom srv01 ins internet
picard@srv01 ~ % mtr -c 100 -r google.de
Start: Mon Dec 28 21:21:26 2015
HOST: srv01.ffnw.de Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a03:4000:6:8000::2 0.0% 100 0.4 19.0 0.3 509.9 75.3
2.|-- 100ge7-2.core1.fra1.he.ne 1.0% 100 4.0 42.1 4.0 492.2 74.6
3.|-- de-cix20.net.google.com 0.0% 100 4.3 28.6 3.9 617.1 77.7
4.|-- 2001:4860::1:0:abf5 0.0% 100 4.6 22.5 4.3 470.6 58.5
5.|-- 2001:4860:0:1::6eb 0.0% 100 130.2 23.6 4.6 318.1 54.5
6.|-- 2a00:1450:4001:806::2003 1.0% 100 4.9 22.1 4.4 666.7 74.4
wieso ist der srv01 so langsam? hat der KVM wo der srv drauf läuft ein problem?
wie kann ich probleme weiter eingränzen?
Hi,
das Problem kann ich nachvollziehen. Ein paar Ideen:
* Ist die Maschine auf der die VM läuft überlastet? CPU Steal in Munin
anschauen. Sieht normal bzw. quasi nicht vorhanden aus. Da dürfte alles ok
sein.
* Problem fühlt sich nach disk io an. In Munin mal die disk io der Server
vergleichen. Srv01 hat eine 2-3x höhere IO als andere Server. Sieht für mich
noch nicht kritisch aus, könnte aber ein Grund sein.
** Netmon läuft wieder soweit ich weiß. Ich weiß aber nicht wo, ich sehe nur
die DB-Requests auf srv07. Netmon generiert RRDs, die massiv disk io erzeugen.
Ich hatte das mal mit rrdcached gelöst, weiß aber nicht wie da der Stand ist.
** Munin selbst generiert ja auch einiges an rrds. Wird hier rrdcached
verwendet? Wenn nein, ist das auch eine Quelle für hohes disk io
* Andere Möglichkeiten:
** Es sieht so aus als würde der Server HTTP Anfragen nur einzeln beantworten.
Gibts im nginx Probleme mit irgendeiner Einstellung a la MaxConnections oder
MaxParallelRequests?
Das ist erstmal nur ins Blaue geraten, weil ich einen konkreten Verursacher
gestern auch nicht direkt ausmachen konnte.
LG
Clemens
Hi,
ich denke auch, dass es am Netcup Host liegt.
Zitat von Clemens John <clemens.john@floh1111.de>:
erstmal vielen dank das du dich beteiligst!
hier zeigen sich mir probleme die ich bis dato noch nie gesehen habe bei linux
auf einer art nett, aber auf der anderen art hilf los.
* Problem fühlt sich nach disk io an. In Munin mal die disk io der Server
vergleichen. Srv01 hat eine 2-3x höhere IO als andere Server. Sieht für mich
noch nicht kritisch aus, könnte aber ein Grund sein.
das vermute ich auch.
können wir auf der VM ihrgendwie das problem weiter eingrenzen?
"nmon" hilft sonst immer sehr gut, weil es alles auf einen blick zeigt.
** Munin selbst generiert ja auch einiges an rrds. Wird hier rrdcached
verwendet? Wenn nein, ist das auch eine Quelle für hohes disk io
gute idee, aber das problem hatten wir ja vor monaten gelöst.
picard@srv01 ~ % systemctl status rrdcached.service
● rrdcached.service - LSB: start the RRDtool data caching daemon
Loaded: loaded (/etc/init.d/rrdcached)
Active: active (running) since Mi 2015-12-23 19:26:15 CET; 5 days ago
CGroup: /system.slice/rrdcached.service
└─1155 /usr/bin/rrdcached -s munin -B -b /var/lib/munin/ -F -j /va...
picard@srv01 ~ % sudo systemctl restart rrdcached.service
picard@srv01 ~ % systemctl status rrdcached.service
● rrdcached.service - LSB: start the RRDtool data caching daemon
Loaded: loaded (/etc/init.d/rrdcached)
Active: active (running) since Di 2015-12-29 13:52:29 CET; 2s ago
und arbeitet immer noch.
* Andere Möglichkeiten:
** Es sieht so aus als würde der Server HTTP Anfragen nur einzeln beantworten.
Gibts im nginx Probleme mit irgendeiner Einstellung a la MaxConnections oder
MaxParallelRequests?
hast du an der nginx.conf was geändert?
dort ist eine änderung drin, von wann ist die?
ich habe heute den hebel worker_connections 2048; geändert.
aber das scheint auch nichts zu bewirken.
können wir gemeinsam noch mal überlegen ob oder was haben wir vor dem 23 o. 22.12 geändert?
nicht das wir beim support als deppen da stehen.
So, nach fünf Stunden Debugging bin ich mit meinem Latein dann auch am Ende...
Anfrage ist gerade raus:
Wie wäre es, wenn du eine Lösung suchst?
waren meine ML emails in den letzten wochen zu dem thema spam?
Du hast öfters festgestellt, dass die Dienste Probleme bereiten.