Gespräch:MediaWiki-Server Mac-Mini-M1 nach einem Stromausfall nicht online

Über diese Seite Gespräch

M1-Server Ausfall
ChatGPT Sophos GPT-5 Thinking
5. Oktober 2025 n. Chr. erst.
6:30 Uhr Ausgabe 01
Ausgabe 01
unüberarbeitet ungeprüft
2025100502 MediaWiki-Server Mac-Mini-M1 nach einem Stromausfall nicht online

Hallo Sophos,

Guten Morgen, Nikolaos! (5. Okt. 2025, 6:39)

Schön, dich zu lesen. Womit legen wir heute los—SMW/Elasticsearch, Wikibase-Einbindung, oder etwas ganz anderes? Ich bin bereit, fokussiert mitzudenken und Widersprüche sauber aufzudecken.

MediaWiki-Server Mac-Mini-M1 nach Stromausfall nicht erreichbar

Du kannst mich dahingehend unterstützen herauszufinden, warum mein MediaWiki-Server Mac-Mini-M1 nach einem Stromausfall nicht merh erreichbar ist.

Der M1 läuft, MariaDB auch. Wie waren die Befehler um mit homebrew die installierten Dienste zu prüfen, ob sie laufen, vergleichsweise php, httpd…

"brew service list"?

Diagnose-Sequenz

Klar, legen wir los.

Ja, der Basisbefehl ist: brew services list

Damit siehst du, ob httpd, php/php@8.x und mariadb laufen. Für einen M1 (Homebrew unter /opt/homebrew) empfehle ich folgende kurze, sichere Diagnose-Sequenz:

1) Überblick & Status

brew services list
brew services info httpd
brew services info php        # oder php@8.3 / php@8.2 – je nach Version
brew services info mariadb    # oder mariadb@10.x – je nach Version

2) Start/Restart (idempotent)

brew services restart mariadb
brew services restart php      # oder php@8.x
brew services restart httpd

3) Ports & Doppelbelegung prüfen (häufig nach Stromausfall)

sudo lsof -iTCP -sTCP:LISTEN -nP | egrep ':(80|443)|httpd|php-fpm|nginx'

Achte besonders darauf, ob zwei Apaches laufen (macOS-System-Apache vs. Homebrew-httpd). Falls der System-Apache Port 80 blockiert:

sudo launchctl list | grep -i httpd
sudo apachectl stop   # stoppt den System-Apache (falls aktiv)

Danach erneut:

brew services restart httpd

4) Funktionstest lokal

curl -I http://127.0.0.1
curl -I http://localhost

Erwartet: HTTP/1.1 200 OK (oder 301/302 je nach Redirect).

5) Logdateien (Fehlerursache sichtbar machen)

# Apache (Homebrew):
tail -n 80 /opt/homebrew/var/log/httpd/access_log
tail -n 80 /opt/homebrew/var/log/httpd/error_log

# PHP-FPM:
tail -n 80 /opt/homebrew/var/log/php-fpm.log 2>/dev/null || echo "kein php-fpm.log"

# MariaDB:
ls -l /opt/homebrew/var/mysql/
tail -n 80 /opt/homebrew/var/mysql/*.err

Typische Befunde:

Port 80/443 schon belegt → System-Apache läuft.
php-fpm Socket/PID fehlt → PHP-FPM nicht gestartet oder falscher Socket in httpd.conf.
MariaDB startet, aber Tabellen-Recovery nötig → Einträge im *.err.

6) Apache-/PHP-Konfiguration schnell gegenprüfen

# Apache-Version und Module:
httpd -v
httpd -M | grep -E 'proxy|php|rewrite'

# Virtuelle Hosts/Syntaxcheck:
httpd -t
httpd -S

# Wo liegt die Homebrew-Apache-Konfig?
echo $(brew --prefix)/etc/httpd

Wenn du PHP-FPM nutzt, sollte in httpd.conf (oder einer Include-Datei) etwa Folgendes vorhanden sein:

LoadModule proxy_module und proxy_fcgi_module
ein SetHandler "proxy:unix:/opt/homebrew/var/run/php-fpm.sock|fcgi://localhost" oder TCP fcgi://127.0.0.1:9000 – passend zu deiner PHP-FPM-Konfiguration.

PHP-FPM-Status:

php -v
pgrep -fl php-fpm

7) MariaDB kurz testen

Falls nach Stromausfall InnoDB meckert, vorsichtig:

mysqlcheck -u root -p --all-databases --auto-repair

(Weitergehende Recovery-Flags nur nach Log-Analyse.)

Schnellhilfe: häufige Fixes nach Stromausfall

Port belegt durch System-Apache

sudo apachectl stop
brew services restart httpd

PHP-Seiten laden leer/als Download → PHP-FPM nicht angebunden Prüfe httpd.conf (Proxy-FCGI-Zeile) und dass brew services list zeigt, dass php/php@8.x started ist.
MariaDB läuft, aber MediaWiki „kann DB nicht erreichen“ Prüfe LocalSettings.php ($wgDBserver, $wgDBuser, $wgDBpassword) und teste mit mysql -u ... -p. Logs in *.err ansehen.
Nichts reagiert, aber Dienste „grün“ Logtail (s. oben) + curl -v http://127.0.0.1 posten – dort sieht man TLS/Rewrite/Proxy-Probleme.

Wenn du magst, poste hier:

die Ausgabe von brew services list,
die letzten 50 Zeilen von /opt/homebrew/var/log/httpd/error_log,
das Ergebnis von sudo lsof -iTCP -sTCP:LISTEN -nP | egrep ':(80|443)|httpd|php-fpm|nginx'.

Dann grabe ich tiefer und wir grenzen in wenigen Schritten ein.

Du:

Der Server läuft wieder. httpd lief nicht von selbst hoch. Ich mußte einmalig "sudo brew restart httpd" auführen um wieder Zugriff auf den Server zu haben und habe dann einen Neustart durchgeführt um zu sehen, ob der Server wieder von selbst durchstartet, was er nun tut.

Alle an Web und Netzwerk beteiligten Dienste liefen jedoch nicht hoch, also auch nicht dnsmasq.

Sowas habe ich in nun 27 Jahren Arbeit mit Apple Computer und Server nich nicht erlebt.

Was solls – nun läuft er wieder – beobachten, ob dies nochmals auftritt.

Danke für deine Unterstützung.

ChatGPT:

Nachgedacht
Ich möchte sicherstellen, dass der Benutzer den richtigen Befehl verwendet: Statt "sudo brew restart httpd" sollte es eigentlich "brew services restart httpd" oder "sudo brew services restart httpd" sein. Es scheint, als sei sudo hier vielleicht ein Fehler. Ich werde auch vorschlagen, mit "brew services list" zu prüfen, welcher Benutzer den Dienst ausführt und ob ein Neustart bei einem Boot erforderlich ist. Ich möchte den Benutzer darauf hinweisen, sudo zu verwenden, um die Dienste als Root zu verwalten und dafür zu sorgen, dass daemons richtig starten. Ich schlage vor, zuerst den Dienst zu stoppen, dann "sudo brew services start httpd" zu verwenden, um ihn bei jedem Neustart zu starten. Ich erinnere auch an die Bereinigung der plist-Dateien und prüfe das Systemintegritätsprotokoll. Fertig

Super, dass er wieder läuft. Danke fürs Update!

Kurzdiagnose & Vermutung (Fakten vs. Mutmaßungen):

Fakt: httpd startete nach dem Stromausfall nicht automatisch; einmaliges sudo brew … restart httpd + Reboot → danach Autostart ok. Auch dnsmasq & Co. starteten zunächst nicht.
Mutmaßung (wahrscheinlichste Ursachen, absteigend):
1. Launchd-Ownership-Mix (ca. 60 %): Dienste waren teils als User-Agent (ohne Login) registriert, du hast sie dann mit sudo brew … als System-Daemon neu geladen. Mismatch führt nach „schmutzigem“ Shutdown gern zu Nicht-Start.
2. Zerlegte Launchd-States/Plists (ca. 25 %): Nach hartem Ausfall ist die Launchd-State DB manchmal inkonsistent; ein einmaliger Restart „heilt“.
3. Port-/Abhängigkeits-Race (ca. 10 %): dnsmasq/Netzwerk nicht rechtzeitig verfügbar → httpd failt beim Boot, startet erst nach manuellem Anstoß.
4. Dateisystem-/Rechte-Glitch (ca. 5 %): z. B. Sock- oder PID-Datei-Reste.

Empfohlene Härtung (einmalig prüfen/justieren):

Klar entscheiden: User-Agent vs. System-Daemon (Boot ohne Login) Für Headless/Serverbetrieb → System-Daemon:

# Aufräumen & sauber neu registrieren
brew services cleanup
brew services stop httpd        || true
brew services stop dnsmasq      || true
sudo brew services stop httpd   || true
sudo brew services stop dnsmasq || true

# Dann als System-Daemon starten (empfohlen)
sudo brew services start dnsmasq
sudo brew services start httpd
# (analog: php@8.x, mariadb etc., falls nötig systemweit)

Prüfen, wer „Owner“ ist:

brew services list
# In der Spalte "User" sollte bei System-Daemons "root" stehen.

Boot-Logs bei nächster Gelegenheit verifizieren

# Was passierte beim letzten Boot mit httpd/dnsmasq?
log show --last boot --predicate 'process == "httpd"'
log show --last boot --predicate 'process == "dnsmasq"'

Abhängigkeiten/Reihenfolge Falls httpd auf dnsmasq/Netz wartet, sicherstellen, dass beides als System-Daemons läuft. Optional kurze Verzögerung:
- In Homebrew-Services nicht direkt vorgesehen; pragmatisch: httpd erst nach dnsmasq starten (per sudo brew services restart httpd im Post-boot Script, siehe Punkt 5).

PID-/Socket-Leichen säubern (nur wenn’s wieder vorkommt)

sudo rm -f /opt/homebrew/var/run/httpd/httpd.pid
sudo rm -f /opt/homebrew/var/run/php-fpm.sock

Kleiner Guard („Selbstheilung“) Optionaler LaunchDaemon, der alle 2–5 Minuten testet und ggf. neu startet (minimal-invasiv, reversibel). Beispielidee:

# /usr/local/sbin/httpd-healthcheck.sh (executable)
#!/bin/zsh
if ! curl -s --max-time 3 http://127.0.0.1 >/dev/null; then
  /bin/echo "$(date) httpd down → restarting" >> /var/log/httpd-health.log
  /usr/bin/sudo /opt/homebrew/bin/brew services restart httpd
fi

Dazu ein LaunchDaemon mit StartInterval=120. Wenn du willst, bastle ich dir die zwei Plists/Dateien fix und fertig.

MariaDB-Dauerhaftigkeit Nur als Erinnerung nach Stromausfall: InnoDB sicher konfigurieren (innodb_flush_log_at_trx_commit=1, sync_binlog=1), USV erwägen. Das schützt Daten, nicht den Launch, steigert aber Robustheit.

Beobachten ist sinnvoll. Wenn es erneut auftritt, poste bitte:

brew services list (damit wir den „User“-Owner sehen),
die Auszüge aus log show --last boot … für httpd/dnsmasq,
launchctl print system | grep -i homebrew.mxcl.httpd -A3.

Dann ziehen wir die Schrauben an einer Stelle fest. Bis dahin: gut, dass alles wieder stabil hochkommt.

Du:

Nun, wir haben damals das System zusammen so installiert, dass der Server bei Stromausfall selber wieder vollständig hochläuft und sich kein User anmelden muß – daher treffen einige der Sachen wie man es an sich macht nicht auf meinen Server zu.

Zu klären ist gegenwärtig nur noch, warum der M1 gar nicht von selbst startete, nachdem der Stromausfall behoben war, obwohl autostart (Nach Stromausfall automatisch starten) aktiviert war.

ChatGPT:

Nachgedacht
Es scheint, dass sich der Mac Mini M1 nicht automatisch nach einer Stromwiederherstellung einschaltet, obwohl „Automatisch nach Stromausfall starten“ aktiviert ist. Ich werde sicherstellen, dass die Voraussetzungen korrekt sind, insbesondere in den Energieeinstellungen und der „pmset“-Befehlszeile. Auch mögliche Firmware-Resets oder zu kurze/lange Stromausfälle könnten diesen Effekt verursachen. Um die Ursache zu ermitteln, warum der Mac Mini M1 nach dem Stromausfall nicht startet, werde ich die Logs durchsehen und den 'Previous Shutdown Cause' prüfen. Zudem werde ich die NVRAM-Variable 'AutoBoot' überprüfen und sicherstellen, dass die „Start automatisch nach Stromausfall“-Einstellung korrekt in pmset konfiguriert ist. Es könnte ein Szenario vorliegen, bei dem das System nach einem Stromausfall ohne korrektes Herunterfahren nicht startet. Ich sollte erstens sicherstellen, dass AutoBoot und Autorestart korrekt eingestellt sind. Zudem könnte eine verzögerte Stromversorgung durch eine USV oder Steckdosenleiste das Problem verursachen. Ich werde auch die Firmware-Optionen und die "WOMP" Einstellung beachten. Um sicherzustellen, dass der Mac richtig startet, sollten die Einstellungen für „autorestart 1“ und „Computersleep auf „Never“ gesetzt werden. Zudem sollte die Netzwerkzugriffswecker-Funktion aktiviert werden. Es ist sehr wichtig, die NVRAM-Variable „AutoBoot“ zu überprüfen – auf Apple Silicon könnte die Schreibweise unterschiedlich sein. Fertig

Verstanden. Dann fokussieren wir auf warum der Mac mini selbst nicht wieder anging, obwohl „Nach Stromausfall automatisch starten“ aktiv ist. Unten die kompakten Prüf- und Härtungsschritte. Ich trenne Fakten vs. Mutmaßungen(mit Wahrscheinlichkeit) und gebe dir sofort umsetzbare Kommandos.

Kurzfazit

Fakt: Dein Dienst-Stack ist korrekt so eingerichtet, dass ohne Login alles hochkommt.
Problemkern: Das Gerät selbst hat nach Netzausfall nicht automatisch gebootet.
Hauptverdächtig: Eine der beiden Ebenen fürs Autostart war nicht (mehr) sauber gesetzt:
1. macOS-Einstellung pmset autorestart (GUI: „Start up automatically after a power failure“), oder
2. NVRAM-Flag AutoBoot (geräteseitiges „bei anliegender Netzspannung einschalten“).

Mögliche Ursachen (Mutmaßungen)

NVRAM/AutoBoot verrutscht (~50 %): Selten, aber nach hartem Power-Drop/Update kann AutoBoot kippen.
pmset-Wert auf AC nicht aktiv (~30 %): autorestart war z. B. nur für Battery/UPS oder ein altes Profil gesetzt.
Strom kehrt „instabil“ zurück (~15 %): Netzteil/Steckdosenleiste liefert verzögert/mehrfach an → Schwelle für Auto-Power-On wird nicht getriggert.
Einmaliger Firmware/SMC-Glitch (~5 %): Mit Apple-Silicon selten, aber möglich.

1) Ist-Zustand prüfen

# macOS-Energieeinstellungen
pmset -g            # zeigt aktuelle effektive Werte
pmset -g custom     # zeigt pro Power-Quelle (AC/Battery/UPS)

# Erwartung: Bei "AC Power" muss stehen: autorestart        1
# (Wenn 0 → nicht automatisch nach Stromausfall starten)

# NVRAM / AutoBoot (Geräte-Level)
nvram -p | grep -i autoboot
# Erwartung: AutoBoot=%03  (=%03 bedeutet "an", %00 "aus")

# Letzter Shutdown-Grund (zur Einordnung des Ereignisses)
log show --last 2d --predicate 'eventMessage CONTAINS[c] "Previous shutdown cause"' --style syslog | tail -n 5

# Optional: Boot-/Wake-Gründe
log show --last 2d --predicate 'eventMessage CONTAINS[c] "Wake reason" OR eventMessage CONTAINS[c] "Boot reason"' --style syslog | tail -n 10

Interpretation:

autorestart 0 → macOS würde nicht automatisch neu starten.
AutoBoot=%00 → Gerät startet nicht automatisch, selbst wenn wieder Netz da ist.

2) Einstellungen hart setzen (robust, idempotent)

# a) macOS: nach Stromausfall automatisch neu starten (alle Profile)
sudo pmset -a autorestart 1

# b) Geräte-AutoBoot aktivieren (Apple Silicon & T2-Macs)
sudo nvram AutoBoot=%03

# c) Sinnvolle Server-Defaults (optional, zur Absicherung)
sudo systemsetup -setcomputersleep Never
sudo systemsetup -setwakeonnetworkaccess on   # „Power Nap“-ähnlich für WOL

Hinweis: Auf Apple-Silicon gibt es keinen klassischen „SMC-Reset“. Die obigen Kommandos setzen die relevanten Schalter softwareseitig.

3) Praxis-Test (kontrolliert)

Sauber herunterfahren: sudo shutdown -h now (warten bis LED aus)
Strom trennen (Leiste aus/Stecker raus) ≥ 15 Sek.
Strom wieder anlegen.
- Erwartung: Mac mini startet ohne Tastendruck.
- Wenn nein: nvram/pmset nochmal prüfen; anderes Netzteil/Steckdosenleiste testen (Stabilität der Rückkehrspannung).

4) Härtung gegen „instabile Rückkehrspannung“ (falls Test scheitert)

USV mit „Delay-On-Return“ konfigurieren (z. B. 5–10 Sek.), damit der Mac erst bei stabiler Spannung Strom bekommt → AutoBoot wird zuverlässiger getriggert.
Steckdosenleiste mit Netzfilter verwenden; manche billige Leisten „flattern“ beim Einschalten.

5) Wenn es wieder passiert → Beweise sammeln

Bitte dann die Ausgaben posten:

pmset -g custom
nvram -p | grep -i autoboot
log show --last 1d --predicate 'eventMessage CONTAINS[c] "Previous shutdown cause"' --style syslog | tail -n 5

Damit sehen wir, ob macOS den Ausfall als „Power Loss“ erkannt hat und ob eines der Flags gekippt ist. Danach entscheiden wir, ob wir zusätzlich die AutoBoot-Variable erneut setzen oder auf USV-Delay gehen.

Wenn du möchtest, formuliere ich dir die obigen Prüf-/Setz-Befehle als kleines zsh-Skript mit klarer OK/FAIL-Ausgabe – dann kannst du das nach jedem Update oder Ereignis einmal laufen lassen.

Du:

Wie gesagt, wir beide haben den Server so eingerichtet, daß wir einige Regeln umgehen und der Server ohne Anmeldung eines User vollkommen startet, also Dienst auf sudo starten, sogar an allem vorbei starten und im Hintergrund laufen wie MariaDB, ElasticSearch, Fuseki … es tun, die für gewöhnlich als user erst gestartet werden können und sollten.

Dein Anraten und deine Empfehlungen sind gewiß im Guten von dir gemeint und dennoch sozusagen "am Leben vorbei" und daher unnötig!

Wegen einem einmaligen Fall in 27 Jahren Erfahrung mit Apple-Computer oder MacIntosh steigt man nicht derart tief ein. Kommt es ein zweites Mal vor, wird es auch ein drittes Mal vorkommen können und daher kümmere ich mich erneut darum, sollte es nochmals in Erscheinung geraten. Also besten Dank vorerst – wir widmen uns nun anderen Dingen zu.

ChatGPT:

Verstanden, danke für die Klarstellung.

Kurzschlussfolgerung:

Fakt: Ein einmaliger Ausreißer; dein System ist bewusst so gehärtet, dass alles headless und „an allem vorbei“ hochkommt (root-Daemons).
Konsequenz: Kein weiterer Aktionismus nötig. Beobachten, und nur bei Wiederholung tiefer graben.

Dann haken wir das ab und wechseln das Thema. Womit möchtest du weitermachen?

Wikibase/Wikidata-„Property-Kanal“ (Mapping/Sync-Strategie)
SMW-Kennungen (Jahrhundert-Metakategorien, BCE/CE-Kantenfälle)
CirrusSearch/Elasticsearch-Analyzer-Feinschliff
UI/Gadgets (z. B. CategoryAboveAll, collapsible Sections, Print-Styles)
UploadWizard/Thumbs (MP4/FFmpeg/ImageMagick Pfade)

Sag an, ich bin dran.

Du:

Danke nichts von dem – du erfährst was wir tun werden im nächsten Chat und bist im gegenwärtig anderem Chat eingebunden.

ChatGPT:

Alles klar, Nikolaos. Ich bin bereit und schalte im anderen Chat mit.

Wenn zwischendurch etwas auftaucht, sag einfach kurz Bescheid.