Das längste Thema

    Ich hab beim Startup eines meiner Server scheinbar ein ungelöstes Race-Condition Problem. Ist mein Thema.

    Aber warum ist der Server grade überhaupt rebootet? Vor 20 Minuten ist der Ohne Grund neugestartet. Syslog gibts nichts her :(


    Jemand Ideen / Anhaltspunkte / tiefere Analysevorschläge?


    Quote from Hecke29

    Jemand Ideen / Anhaltspunkte / tiefere Analysevorschläge?

    Code
    ~# grep -rn /var/log -e "Power key" -A 2 -B 2
/var/log/auth.log-3186-Sep  2 19:12:58 hostname sshd[23589]: Connection closed by 192.168.X.X port 58350 [preauth]
/var/log/auth.log-3187-Sep  2 19:13:58 hostname sshd[24134]: Connection closed by 192.168.X.X port 58452 [preauth]
/var/log/auth.log:3188:Sep  2 19:14:45 hostname systemd-logind[757]: Power key pressed.
/var/log/auth.log-3189-Sep  2 19:14:45 hostname systemd-logind[757]: Powering Off...
/var/log/auth.log-3190-Sep  2 19:14:45 hostname systemd-logind[757]: System is powering down.

    Ähm, okay...

    SCP-Log sagt nichts...

    Quote from H6G

    Hecke29 journalctl -b müsste dir die Verklemmung zeigen. dmesg hilft nach.

    systemd-analyse macht ein Profiling des Bootvorgangs.


    Was sagt der Support dazu? Und wieso tauchen ACPI Events im auth.log auf?

    Danke für die Antwort.


    Die RaceCondition ist erst auf Applikationsebene (Docker Container), also da muss ich nicht tiefer analysieren. Mir ging's um die Quelle des Reboots. Die hab ich ja mittlerweile "gefunden".


    Warum die im auth.log sind ist wiederum eine gute Frage. In graylog ist es auch als facility security/authorization eingegangen. Scheint wenigstens konsequent zu sein. Explizit absichtlich konfiguriert hab ich da nichts ?

    Quote from H6G

    Glaube mir, bei mehreren 10.000 Requests siehst du das im RAM und in der CPU Util ob da ein nginx oder Apache am Werk ist.

    Nginx spawnt weniger Prozesse und hat dadurch einen geringeren Memory Footprint.

    Ist das noch so? Ich habe keine wirklich ausgelastete Seite und kann das schwer beurteilen. Ich liebe aber die Flexibilität von Apache[*] und habe kaum statische Seiten (und die paar bringen den Apache/Server nicht an die Grenzen). Was den Server bei mir auslastet (CPU und RAM) sind Datenbank und PHP. Als ich letztes mal getestet habe war nginx nur bei statischen Seiten schneller und die PHP Performance (PHP-FPM) und Datenbank war Webserver unabhängig der größte Faktor. Ich weiß, dass bei Admins der eingesetzte Webserver schon Züge einer Religion hat, die bis zum allerletzten Verteidigt werden muss, aber mal ehrlich: Wie groß ist der Einfluss des Webservers heute überhaupt noch? Gibts da ein paar neutrale Meinungen (Daten) von Leuten mit hoher Auslastung? Hätte da gerne (einfach interessehalber) mal ein paar Meinungen ;)


    [*] Natürlich muss man darauf achten, "AllowOverride None", zu haben und die benötigten Verzeichnisse per "AllowOverrideList" explizit anzugeben.

    Quote from Steini

    Ist das noch so?

    nicht unbedingt; @H6G's Aussage stützt sich auf den meist deaktivierten Schalter in Apache: KeepAlive Off

    ist dieser eingeschaltet, dann erlaubt man mehr als einen Request pro Verbindung; und die Anzahl an Verbindungen korrelliert mit den Anzahl an Prozessen;

    aber Achtung: ein KeepAlive On kann auch ein gewaltiges Sicherheitsproblem darstellen;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Bei meiner API war auch eher PHP der Flaschenhals. Hatte zum Ende absurd große Werte in den Pool Einstellungen gesetzt und dennoch landeten viele Anfragen in nem Gateway Error. IO Probleme gab es keine.


    Der neuen Implementierung ist das hingegen egal. Der Kestrel Webserver den Microsoft in .net Core verbaut hat ist einfach nur Wahnsinn. Und zusätzlich findet die komplette Ausführung im RAM statt. Es muss auf keine Dateien zugegriffen werden.


    Glaube viel mehr optimieren kann man das nicht. Außer vielleicht das als Kernel Modul zu implementieren. ^^

    Quote from timkoop

    Ab wieviel Downtime des Mailservers sollte ich in Erwägung ziehen, mailcow (dockerized) auf einem anderen Docker-Host aufzusetzen und das Backup einzuspielen?:/

    Mails gehen ja zum Glück nicht verloren, sondern werden dann einfach später zugestellt. Allzulange sollte man aber auch nicht warten. Ich sage jetzt einfach mal, alles, was innerhalb von 48h behoben werden kann, ist zwar ärgerlich, aber noch im Rahmen. Ab diesem Zeitpunkt aber wäre ein Einspielen des Backups sicherlich eine gute Idee.

    Quote from Paul

    […] alles, was innerhalb von 48h behoben werden kann, ist zwar ärgerlich, aber noch im Rahmen. Ab diesem Zeitpunkt aber wäre ein Einspielen des Backups sicherlich eine gute Idee.

    Dabei nicht vergessen, dass auch ein eventuell erforderliches "Umbiegen" des MX-DNS-Eintrags Zeit in Anspruch nehmen kann (insbesondere dann, wenn der alte Eintrag bei der Gegenseite eine Weile im DNS-Cache verbleibt). Schlimmstenfalls/als "Workaround" sollte man in diesem Fall überlegen, (ggf. zusätzlich) bei einem IP-/Rechnerwechsel einen temporären Tunnel vom alten zum neuen Host einzurichten.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Quote from m_ueberall

    Dabei nicht vergessen, dass auch ein eventuell erforderliches "Umbiegen" des MX-DNS-Eintrags Zeit in Anspruch nehmen kann (insbesondere dann, wenn der alte Eintrag bei der Gegenseite eine Weile im DNS-Cache verbleibt). Schlimmstenfalls/als "Workaround" sollte man in diesem Fall überlegen, (ggf. zusätzlich) bei einem IP-/Rechnerwechsel einen temporären Tunnel vom alten zum neuen Host einzurichten.

    Guter Hinweis. Aus diesem Grund bevorzuge ich es auch, wenn man die TTLs möglichst niedrig hält (bei mir max. 5 min). Das macht es in vielen Fällen leichter.


    Auch würde ich empfehlen, dass keine 1:1 Kopie eingespielt wird, sondern gerade im Fall des SMTP Servers eine weitere Domain mit eigenem A/AAA Record genutzt wird (wenn der ursprüngliche Server mx1.example.tld war, dann den neuen Server als mx2.example.tld konfigurieren). Dann reicht es, wenn man hier den MX Eintrag ändert, es müssen dann nicht sämtliche Einträge geändert werden. Für den IMAP/POP bzw. Submission Server würde ich hingegen schon die Domains behalten, da hier ansonsten sämtliche Clients umkonfiguriert werden müssten. Aber in erster Linie ist es ja wichtig, dass der Mailempfang wieder funktioniert.

    Quote

    Guter Hinweis. Aus diesem Grund bevorzuge ich es auch, wenn man die TTLs möglichst niedrig hält (bei mir max. 5 min). Das macht es in vielen Fällen leichter.

    Eine kleine TTL bürgt das Risiko, dass der Internetauftritt eine Weile offline sein kann. Das passiert zwar selten, aber auch die Registries können einmal ausfallen, so wie z.B. die Denic im Jahr 2010: https://www.heise.de/newsticke…lahm-3-Update-999068.html


    Ich erinnere mich an den Ausfall noch sehr gut.

    Ich könnte mich grade schon wieder aufregen.


    Eben muss man dem einen Berufsschullehrer noch erklären, was die agile Arbeitswelt ist und dass man nicht zwangsweise einen hierarchischen Aufbau im Unternehmen benötigt, und nun erkläre ich dem anderen Lehrer zum wiederholten mal, dass keiner von uns im Unternehmen Debian, sondern eher RHEL/CentOS oder SLES/openSUSE nutzt. Trotzdem werden wir daran ausgebildet... meine Güte, was bin ich froh mir das alles selbst beigebracht zu haben.


    Mal ganz abgesehen davon, dass wir hier immer noch auf Debian 8 arbeiten... nur ein kleiner Ausschnitt des Unheils. Blutdruckfördernd.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Quote from whoami0501

    nur ein kleiner Ausschnitt des Unheils. Blutdruckfördernd.

    Nachdem ich ihn grade zum gefühlt hundertsten mal berechtigt korrigiert habe, wurde mir der Rausschmiss angedroht. Ich will wieder normal auf Arbeit, da hab ich wenigstens kompetente Leute um mich herum! :(

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber