Server startet nicht komplett

extremmichi · Jul 3rd 2018

Hi Leute,

mein VPS50 lief heute heute recht langsam, zeigte aber keine Aus/Belastung. In den logs

war auch nichts Verdächtiges also dachte ich an einen Reboot. Nun startet der Server nicht mehr

komplett durch. Die wichtigsten Dienste laufen ssh FW Apache +Monitoring. Mehr ist da auch nicht drauf.

ich kann mich über ssh einloggen , aber alles läuft immer noch langsam.

Er startet auch nicht durch bis zum login , siehe Bild1 aus der VNC.

[Blocked Image: http://extremmichi.de/share/Bild1.srv3.png]

Danach passiert nichts mehr. auch in den logs ist nicht zu finden.

den grub "quiet-mode" habe ich abgeschaltet und auch das bringt nicht mehr Informationen.

Ich habe keine Ahnung in welche Richtung ich suchen soll.

Warum er so langsam ist, kann ich auch nicht bestimmen. Evtl. hängt das auch nichtmal zusammen

siehe Bild2

[Blocked Image: http://extremmichi.de/share/Bild2.srv3.png]

Kann mich mal einer schubsen?

Danke im Voraus

michi

H6G · Jul 3rd 2018

Er verlässt das Runlevel 2 nicht. Im htop sieht man noch den Prozess /bin/sh /etc/init.d/rc 2 auf PID 2695. Müsste der nicht beendet sein, wenn Runlevel 2 verlassen wird?

Evtl. geben die Child Processes des o.g. Prozesses mehr Auskunft.

heavygale · Jul 3rd 2018

Mein VPS 20 G7 geht auch seit etwa zwei Tagen am Rollator. Ich habe darauf PHP Server Monitor laufen und bekomme seither regelmäßig Fehlalarme, weil es Timeouts beim Verbinden zu meinen anderen Servern gibt. Bei allen eingerichteten Überwachungen sind längere Laufzeiten zu, unabhängig davon welchen meiner anderen Server ich überwache, sodass es am VPS20 liegen muss. In Munin erkenne ich auch keinerlei Auffälligkeiten, weder CPU noch RAM, HDD oder Netzwerk scheinen stärker ausgelastet als zuvor.

Schnappschuss 2018-07-03 21.36.00.png

Einen Reboot habe ich auch gemacht, hat etwas gedauert, lief aber problemlos durch und ist nun auch normal online - natürlich etwas träge, aber das war der kleine Server ja auch sonst schon, gefühlt aber etwas träger als sonst.

ThomasChr · Jul 3rd 2018

Was bekommst du für Geschwindigkeiten bei einfachen CPU oder Platten Benchmarks?

Code

dd if=/dev/zero of=./test.file bs=128M count=10 oflag=direct

time echo "scale=5000; a(1)*4" | bc -l > /dev/null

(bc muss vorher installiert sein!)

extremmichi · Jul 3rd 2018

Quote from H6G

Er verlässt das Runlevel 2 nicht. Im htop sieht man noch den Prozess /bin/sh /etc/init.d/rc 2 auf PID 2695. Müsste der nicht beendet sein, wenn Runlevel 2 verlassen wird?

Evtl. geben die Child Processes des o.g. Prozesses mehr Auskunft.

Es war in der Tat ein Child-Prozess und zwar lasse ich mir über rc.local beim SSH-Login eine Nachricht aufs Handy schicke durch Telegram

Das a hab ich nun abgeschaltet und der Server startet wieder durch.

Danke H6G

Quote from ThomasChr
Was bekommst du für Geschwindigkeiten bei einfachen CPU oder Platten Benchmarks?
Code
dd if=/dev/zero of=./test.file bs=128M count=10 oflag=direct

time echo "scale=5000; a(1)*4" | bc -l > /dev/null
(bc muss vorher installiert sein!)

langsam ist er immer noch aber doch etwas schneller als vorher

Code

root@srv3:/# dd if=/dev/zero of=./test.file bs=128M count=10 oflag=direct
10+0 records in
10+0 records out
1342177280 bytes (1.3 GB) copied, 11.1591 s, 120 MB/s

klingt nicht so schlecht wie es sich anfühlt

heavygale ich zweifle auch langsam an munin.......

Hecke29 · Jul 3rd 2018

Für deine telegram Nachricht könntest du einen Oneshot-Systemd-Service anlegen (Type simple) und einen Systemd-Timer der OnBoot den Service "startet". Dadurch bekommst du die Nachricht, aber wenn es failt geht nicht "alles" kaputt

extremmichi · Jul 3rd 2018

Nachtrag:

Quote from ThomasChr
Was bekommst du für Geschwindigkeiten bei einfachen CPU oder Platten Benchmarks?
Code
time echo "scale=5000; a(1)*4" | bc -l > /dev/null
(bc muss vorher installiert sein!)

time echo "scale=5000; a(1)*4" | bc -l > /dev/null

real 0m47.587s

user 0m46.187s

sys 0m0.868s

@ Hecke29 muss ich mal schauen wie das geht ,vielleicht greife ich auch einfach wieder auf das gute alte mail zurück

H6G · Jul 3rd 2018

Quote from extremmichi

Es war in der Tat ein Child-Prozess und zwar lasse ich mir über rc.local beim SSH-Login eine Nachricht aufs Handy schicke durch Telegram

Das a hab ich nun abgeschaltet und der Server startet wieder durch.

Danke H6G

Quote from extremmichi

@ Hecke29 muss ich mal schauen wie das geht ,vielleicht greife ich auch einfach wieder auf das gute alte mail zurück

Wenn du kein systemd nutzt, kannst du für deinen Daemon ja auch ein init Script schreiben. Natürlich kannst du auch einfach den Aufruf durch z.B. /bin/start-stop-daemon o.Ä. kapseln.

Eine weitere interessante Möglichkeit: du forkst deinen Daemon in rc.local in dem du in den Aufruf ein & anhängst. So kann rc.local mit Fehlercode 0 an den Kernel zurück geben. Allerdings müsste dein Programm dann SIGHUP? abfangen.

Hecke29 · Jul 3rd 2018

Quote from extremmichi

@ Hecke29 muss ich mal schauen wie das geht ,vielleicht greife ich auch einfach wieder auf das gute alte mail zurück

Hm, ich glaube den Timer brauchst du nicht. Ich hatte das nur im Kopf, weil ich eine Aktion absichtlich nach dem Boot verzögere, dafür brauchte ich den Timer. Bei dir sollte folgendes reichen:

/etc/systemd/system/bootnotification.service anlegen mit Inhalt

Code

[Unit]
Description=Sends a telegram message onboot

[Service]
Type=oneshot
ExecStart=/root/send_telegram.sh
RemainAfterExit=true
DefaultTimeoutStartSec=30

[Install]
WantedBy=multi-user.target

Display More

und danach im Terminal systemctl daemon-reload && systemctl enable bootnotification.service

zum Testen systemctl start bootnotification

Der Service wird zwar beim Booten nun auch "synchron" ausgeführt, aber der Bootvorgang hängt maximal DefaultTimeoutStartSec Sekunden.

Aber um das mit dem Timer noch zu zeigen:

z.B:

Eine /etc/systemd/system/bootnotification.service

Code

[Unit]
Description=Sends a telegram message onboot

[Service]
Type=oneshot
ExecStart=/root/send_telegram.sh
RemainAfterExit=true
DefaultTimeoutStartSec=30

Und eine /etc/systemd/system/bootnotification.timer

Code

[Unit]
Description=Starts service to send bootnotification

[Timer]
OnBootSec=10

[Install]
WantedBy=timers.target

und dann systemctl daemon-reload && systemctl enable bootnotification.timer

extremmichi · Jul 6th 2018

Hi Leute,

ich hab das jetzt mal mehrere Tage beobachtet

und seit 2 Tagen ist wieder Ruhe. Ich hab mehrere

Traceroute zwischen meinen Servern hin und her geschickt

und da kamen doch Zeiten von über 100 ms raus. Ich tippe also auf

Routingprobleme innerhalb netcup, wodurch munin dann extrem

lange Wartezeiten hatte. Aber ich bin nicht so im Thema

um da verlässliche Aussagen machen zu können.

Jedenfalls rennt der Server wieder und das reicht mir.

[Blocked Image: http://extremmichi.de/share/munin_last.png]

heavygale Was ist bei dir? Auch alles wieder gut?

LG

michi

P.S. und OT

<shame>kann mich mal einer aufklären warum bilder bei mir nicht direkt angezeigt werden sondern nur als Link? </shame>

heavygale · Jul 6th 2018

Ich hab den Cronjob deaktiviert, da die Überwachung die ganze Zeit geschriehen hat. Ich aktiviere ihn mal wieder und schau wie es sich verhält.

EDIT: Offenbar hab ich den Cronjob schon vor ein paar Tagen wieder aktiviert, und es, da ich keine weiteren Fehlalarme bekommen habe, wohl vergessen. Wie die Antwortzeiten im Grahen dargestellt werden kann ich aber erst heute Abend von zuhause nachschauen (meine PHP Server Monitor GUI ist nur per IPv6 erreichbar und die drei Netzwerke die ich gerade zur Verfügung haben können nur legacy IP).

KB19 · Jul 6th 2018

Quote from extremmichi

kann mich mal einer aufklären warum bilder bei mir nicht direkt angezeigt werden sondern nur als Link?

Eventuell, weil es über HTTP verlinkt wurde und somit eine Mixed-Content-Warnung über HTTPS erzeugen würde?

heavygale · Jul 6th 2018

Schnappschuss 2018-07-06 15.23.10.png

Passt auch bei mir wieder.