Einführung
Community Radio hat einen Clip für die Abendsendung, doch die kleine Medienplatte ist voll. Der Name des großen Zugriffslogs wurde bereits gelöscht. Die Station liefert weiterhin ihr Archiv, aber der Platz kam nicht zurück. Wertvolle Aufnahmen zu löschen würde am eigentlichen Problem vorbeigehen.
Du findest die von Nginx noch gehaltene Datei, nutzt sein dokumentiertes Reopen-Signal und speicherst und spielst den ganzen neuen Clip bei laufenden Originaldiensten. Grundlegende Terminalkenntnisse genügen. C, Geräteformatierung oder Speicherkonfiguration sind nicht nötig. Das Übungsaudio verwendet eine synthetische englische Stimme.
Nutze Workstation für Befehle und Radio Player zum Hören. Jedes Lab hat seinen eigenen vorbereiteten Vorfall. Arbeite nur in /home/labex/project/radio und signalisiere nur den identifizierten Stationsmaster; andere Prozesse gehören zur Lernplattform.
Platz zurückgewinnen, ohne die Station zu stoppen
In diesem Schritt ordnest du das volle Dateisystem einer bestimmten gelöschten Datei zu und gewinnst ihre Blöcke bei laufender Station zurück.
Anhören, was erhalten bleiben muss
Öffne Radio Player. Spiele Archive recording, dann Incoming clip. Das Archiv liegt bereits auf der Medienplatte; der eingehende Clip wartet außerhalb. Der dritte Player hat noch keine vollständige gespeicherte Aufnahme. Es sind synthetische Probestimmen, kein Live-Mikrofon und kein echtes Interview.
In Workstation zeigt pwd deinen Ort, ls die Verzeichniseinträge. Du startest im vorbereiteten Stationsverzeichnis; bei Bedarf kehrst du mit cd zurück:
cd /home/labex/project/radio
pwd
/home/labex/project/radio
ls
media/ ist die isolierte Platte. incoming/ liegt auf dem normalen Dateisystem der Instanz. services/ enthält Konfigurationen und Master-PID-Dateien der beiden kursinternen Nginx-Dienste. media.ext4 ist die von LabEx vorbereitete Trägerdatei fester Größe; lasse sie unverändert. Du erstellst keine Dateisysteme und änderst keine Mount-Einstellungen.
Fehler und Grenze bestätigen
findmnt -T zeigt das Dateisystem eines Pfads. Das Ziel muss genau das Verzeichnis media sein, die Quelle ein Gerät /dev/loop... und der Typ ext4. Das Root-Dateisystem hat eine andere Quelle. Ein Loop-Gerät stellt das begrenzte Plattenabbild als Blockgerät bereit.
findmnt -T media -o TARGET,SOURCE,FSTYPE
findmnt -T incoming -o TARGET,SOURCE,FSTYPE
cp kopiert eine Datei. Die folgende Kopie soll ausdrücklich mit No space left on device scheitern. Dabei kann eine unvollständige Zieldatei entstehen. Verwende kein sudo; diese Dateien benötigen es nicht.
cp incoming/evening-recording.wav media/recordings/evening-recording.wav
Dies ist ein echter Kapazitätsfehler auf dem kleinen Mediendateisystem. Das ursprüngliche Archiv bleibt intakt. df -h zeigt die Blockkapazität in lesbaren Einheiten. du -xsh summiert die über Namen unter einem Verzeichnis erreichbaren belegten Blöcke: -x bleibt im Dateisystem, -s fasst zusammen und -h nutzt lesbare Einheiten.
df -h media
du -xsh media
df meldet fast vollständige Belegung, während du wenig findet. Beide messen Unterschiedliches. Die Abweichung allein beweist keine Ursache: Metadaten, reservierte Blöcke, Rechte, andere Mount-Sichten und weitere Faktoren spielen ebenfalls eine Rolle.
Den tatsächlichen Halter finden
Ein Verzeichniseintrag ordnet einen Namen einem Inode, dem Dateidatensatz des Dateisystems, zu. Die Zahl harter Links sagt, wie viele Namen diesen Inode referenzieren. Ein Prozess kann außerdem einen offenen Dateideskriptor halten, eine nummerierte Dateireferenz. Das Entfernen des letzten Namens setzt die Linkzahl auf null; die Blöcke bleiben bis zum Schließen der letzten offenen Referenz.
lsof listet offene Dateien. Wir nutzen sudo für diese lesende Untersuchung, weil Nginx einen Root-Master hat. -nP vermeidet Host- und Portnamenauflösung, +L1 wählt Linkzahlen unter eins, +f -- media das Dateisystem von media, und -a bildet die Schnittmenge. Behalte diesen Filter: Globale Listen können fremde gelöschte Speicherdateien und Plattformprozesse enthalten.
sudo lsof -nP -a +L1 +f -- /home/labex/project/radio/media
Erwarte zwei Nginx-Zeilen für media/logs/access.log (deleted): Master und Worker. Lies PID, FD, DEVICE, SIZE/OFF, NLINK und NODE. Gerät und Inode sind gleich, NLINK ist null. Die Größen beschreiben dieselbe Datei, addiere sie nicht. Ein FD wie 4w bedeutet Deskriptor 4, zum Schreiben geöffnet. Gerät/Inode identifizieren diese Datei trotz gelöschten Namens.
cat zeigt Text. Lies die tatsächliche Konfiguration und Master-PID-Datei. Die Pfade pid und access_log müssen zu dieser Station und ihrem gelöschten Medienlog gehören:
cat services/studio/nginx.conf
cat services/studio/nginx.pid
MASTER ist eine Shellvariable. $(...) übernimmt die Ausgabe, doppelte Anführungszeichen halten den Wert in einem Argument. ps zeigt ausgewählte Prozesse; -o wählt Spalten, -p diese PID und --ppid zusätzlich ihre Kinder. Bestätige den Master aus den gefilterten lsof-Zeilen mit der Kurskonfiguration. Die andere Zeile ist ein Worker, dessen Eltern-PID dieser Master ist.
MASTER=$(cat services/studio/nginx.pid)
ps -ww -o pid,ppid,user,args -p "$MASTER" --ppid "$MASTER"
Handle nicht, wenn Mount, Pfad oder Masteridentität abweichen. Prüfe Verzeichnis und Konfiguration erneut, statt PIDs zu raten oder allen Nginx-Prozessen Signale zu senden.
Dieses Programm um erneutes Öffnen bitten
Die Bedeutung eines Signals hängt vom Programm ab. Nginx dokumentiert USR1 als Logdateien erneut öffnen: Alte Referenzen werden geschlossen und der konfigurierte Name neu geöffnet. TERM würde stoppen, HUP hat andere Reload-Semantik. Lies mit man nginx das installierte Handbuch, suche SIGNALS und kehre mit q zurück. Die Nginx-Steuerungsdokumentation nennt denselben Vertrag.
man nginx
kill sendet auch benannte Signale und bedeutet nicht immer Beenden. Für den Root-Master brauchst du sudo. Sende nur das dokumentierte Signal an den gerade bestätigten Master:
sudo kill -USR1 "$MASTER"
Prüfe erneut Platz, Halter und Master. Reopen erfolgt asynchron. Falls ein Halter kurz noch erscheint, wiederhole nach einem Moment diese lesenden Beobachtungen.
df -h media
sudo lsof -nP -a +L1 +f -- /home/labex/project/radio/media
ps -ww -o pid,ppid,user,args -p "$MASTER" --ppid "$MASTER"
Der Platz sollte zurückkehren, die Zeilen zum gelöschten Medienlog verschwinden und die Master-PID gleich bleiben. Eine leere gefilterte lsof-Ausgabe ist jetzt erwartet. Du hast weder die Station gestoppt noch eine Datei eines anderen Dateisystems freigegeben.
curl -fsS liest eine URL, scheitert bei HTTP-Fehlern und zeigt nötigenfalls einen knappen Fehler. Diese normale Stationsanfrage muss weiterhin funktionieren. tail -n 2 zeigt danach die letzten zwei Zeilen des neu benannten Zugriffslogs:
curl -fsS http://127.0.0.1:8080/on-air.txt
tail -n 2 media/logs/access.log
Erwarte Community Radio: archive and live programme remain available. und einen neuen Eintrag GET /on-air.txt. Der Originalprozess schreibt nun in das neu benannte Log. Kam kein Platz zurück, prüfe die gefilterten Halter erneut. Lösche nicht das Archiv, kürze keine Deskriptoren, stoppe keine Dienste und erstelle keinen Mount neu. Fehlt das neue Log, prüfe die unveränderte Konfiguration und wiederhole das dokumentierte Reopen für den richtigen Master.
Die vollständige Aufnahme speichern und nutzen
In diesem Schritt ersetzt du die fehlgeschlagene Teilkopie durch den vollständigen Clip, prüfst seine Bytes und nutzt ihn über die laufende Station.
Quelle und Archiv haben verschiedene Aufgaben. Erhalte beide. Erneutes cp zum selben Ziel ersetzt die Teilkopie des Fehlversuchs, ohne die Quelle zu ändern.
cp incoming/evening-recording.wav media/recordings/evening-recording.wav
cmp vergleicht jedes Byte und bleibt bei Gleichheit still. Prüfe sofort nach dem Kopieren:
cmp incoming/evening-recording.wav media/recordings/evening-recording.wav
sha256sum gibt einen Inhaltsfingerabdruck aus. Gleiche Hashes sind ein weiterer sichtbarer Vergleich; die Bewertung vergleicht auch Originalarchiv und Quelle mit den vorbereiteten Bytes.
sha256sum incoming/evening-recording.wav media/recordings/evening-recording.wav
Beide Zeilen müssen denselben Hash haben. Eine Nulldatei oder dünn belegte Datei mit plausiblem Namen oder Größe ist keine Aufnahme. Eine Kopie auf dem falschen Dateisystem bleibt ebenfalls unvollständige Medienlieferung.
findmnt -T media/recordings/evening-recording.wav -o TARGET,SOURCE,FSTYPE
Es muss derselbe isolierte ext4-Mount sein. Prüfe, ob die Station die tatsächlich gespeicherte Datei ausliefert. -o lässt curl die Antwort außerhalb der Medienplatte speichern; vergleiche diese Antwort mit dem eingehenden Clip:
curl -fsS http://127.0.0.1:8080/recordings/evening-recording.wav -o /tmp/radio-delivered.wav
cmp incoming/evening-recording.wav /tmp/radio-delivered.wav
Kehre zu Radio Player zurück und lade neu. Spiele Your saved recording, springe nahe ans Ende und höre den Schlusssatz. Spiele nochmals Archive recording. Lade über Download saved recording herunter. Folge Read the on-air message; die Stationsnachricht muss weiter erscheinen. Browseraudio benötigt eine Wiedergabeaktion; gespeicherte Bytes starten es nicht automatisch.
Meldet der Player einen Format- oder Netzwerkfehler, vergleiche Quelle und Ziel erneut und prüfe die URL. Ein Versuch bei voller Platte kann WAV-Header oder Daten abschneiden. Kopiere nach der Wiederherstellung die unveränderte Quelle erneut. Scheitert der Vergleich, repariere keine Header und ändere nicht die Quelle passend zum beschädigten Ziel.
df -h media
Nun sollte das Dateisystem ausreichend Platz und den vollständigen Clip haben. Die Prüfungen lesen nur finale Dateien, Mountidentität, offene Deskriptoren und echten Dienstzustand. Sie senden keine Signale, kopieren oder reparieren kein Audio und erstellen keine Aufnahme für dich.
Zusammenfassung
Du hast echten Plattenplatz zurückgewonnen, indem du Namen, Inodes und offene Deskriptoren unterschieden hast. Die nach Dateisystem gefilterte Untersuchung ordnete das gelöschte Log dem richtigen Nginx-Master zu. Sein dokumentiertes USR1 gab alte Referenzen frei, ohne den Prozess zu ersetzen. Danach hast du den vollständigen Clip gespeichert, verglichen, heruntergeladen und abgespielt und Archiv sowie Dienste erhalten.
Ein Unterschied zwischen df/du ist ein Hinweis, keine Diagnose. Reopen-Verhalten hängt vom Programm ab: Lies vor jedem Signal dessen Dokumentation. Diese Übung nutzt eine isolierte ext4-Platte und synthetische Stimmen; Formatierung, beliebige Prozessabbrüche und vollständige Logrotation gehören nicht dazu.
