Server startet nicht komplett

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.

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.

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

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!)

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

Zitat von 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

Zitat von 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.

Zitat von 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

[Unit]
Description=Sends a telegram message onboot

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

[Install]
WantedBy=multi-user.target

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

[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

[Unit]
Description=Starts service to send bootnotification

[Timer]
OnBootSec=10

[Install]
WantedBy=timers.target

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

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).

Zitat von 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?

Schnappschuss 2018-07-06 15.23.10.png

Passt auch bei mir wieder.