Quiz · Tag 3 · Lernwerkstatt

📝

So funktioniert das Quiz

Klicke deine Antwort an — bei Mehrfachauswahl alle zutreffenden! Sofort siehst du, ob richtig oder falsch, und bekommst eine kurze Erklärung. Keine Wertung, keine Sammlung — das Quiz ist nur für dich selbst, damit du sehen kannst, was sitzt und wo du nochmal nachsehen solltest.

Q1 Single Choice

Du erklärst einem Praktikanten, in welcher Reihenfolge die Komponenten beim Linux-Boot ausgeführt werden. Welche Reihenfolge ist korrekt?

a) Kernel → BIOS/UEFI → Bootloader → systemd b) BIOS/UEFI → Bootloader → Kernel → systemd c) BIOS/UEFI → Kernel → Bootloader → systemd d) Bootloader → BIOS/UEFI → Kernel → systemd

✓ Richtig! Korrekte Reihenfolge: BIOS/UEFI (Firmware-Check) → Bootloader (GRUB2 lädt das gewählte System) → Kernel (Linux übernimmt) → systemd als PID 1 startet alle Services. Auf modernen Systemen ist statt BIOS oft UEFI im Einsatz — die Reihenfolge bleibt gleich.

✗ Nicht ganz. Reihenfolge ist: Firmware (BIOS/UEFI) zuerst — sie kennt nur die Hardware. Dann der Bootloader (GRUB2), der das Betriebssystem auswählt. Dann der Kernel, der die Hardware übernimmt. Dann systemd als erster User-Space-Prozess (PID 1).
Q2 Single Choice

Ein Kollege bittet dich, auf einem Test-Server kurzfristig den grafischen Modus zu starten — ohne Reboot, ohne dass beim nächsten Boot der GUI-Modus automatisch kommt. Welcher Befehl ist passend?

a) sudo systemctl set-default graphical.target b) sudo systemctl isolate graphical.target c) sudo systemctl enable graphical.target d) sudo systemctl switch graphical.target

✓ Richtig! isolate wechselt sofort zum angegebenen Target, ohne den Default beim nächsten Boot zu ändern. Genau das, was hier verlangt war: live umschalten, aber temporär.

✗ Nicht ganz. set-default ändert nur den nächsten Boot, wechselt jetzt nichts. enable ist für Services, nicht für Targets. switch existiert nicht. isolate ist die Antwort — wechselt sofort und beeinflusst den Default nicht.
Q3 Multiple Choice

Welche der folgenden Befehle aktualisieren installierte Pakete auf neuere Versionen? (mehrere richtig möglich)

a) sudo dnf update b) dnf check-update c) sudo dnf upgrade d) sudo dnf install --refresh

✓ Richtig! Bei dnf sind update und upgrade identisch — beide installieren neuere Versionen. check-update zeigt nur an, was es gäbe, installiert aber nichts (read-only). --refresh ist eine Option, kein eigenständiger Update-Befehl.

✗ Nicht ganz. Die zwei richtigen sind update und upgrade — bei dnf synonym. check-update ist nur ein Trockenlauf. install --refresh lädt die Repo-Metadaten neu, aktualisiert aber keine installierten Pakete.
Q4 Single Choice

Du hast in /etc/default/grub die Variable GRUB_TIMEOUT=10 gesetzt und gespeichert. Beim nächsten Reboot ist das Bootmenü trotzdem nur 5 Sekunden sichtbar. Was hast du wahrscheinlich vergessen?

a) sudo systemctl restart grub b) sudo grub2-mkconfig -o /boot/grub2/grub.cfg c) sudo reboot --apply-grub d) Den Wert direkt in /boot/grub2/grub.cfg zu ändern

✓ Richtig! /etc/default/grub ist nur die Vorlage. Die echte Konfiguration in /boot/grub2/grub.cfg wird erst aktualisiert, wenn du grub2-mkconfig -o /boot/grub2/grub.cfg ausführst. Ohne diesen Schritt bleibt der alte Wert wirksam.

✗ Nicht ganz. GRUB hat keinen Daemon, den man neu starten kann — Option a) gibt es nicht. reboot --apply-grub existiert nicht. Direkt in grub.cfg editieren wäre falsch — die Datei wird bei jedem grub2-mkconfig überschrieben. Richtig: grub2-mkconfig aufrufen, das schreibt die aktualisierte grub.cfg aus der Vorlage.
Q5 Single Choice

Welche der folgenden Variablen ist nach Konvention eine Umgebungsvariable?

a) $path b) $Home c) $JAVA_HOME d) $myEditor

✓ Richtig! Umgebungsvariablen werden per Konvention komplett GROSSGESCHRIEBEN, oft mit Unterstrich als Trennzeichen — wie $JAVA_HOME, $HOME, $PATH, $LANG. Eigene Shell-Variablen schreibt man dagegen meist klein.

✗ Nicht ganz. Standard-Umgebungsvariablen sind in Großbuchstaben geschrieben — z. B. $HOME, $PATH, $JAVA_HOME. $path, $Home, $myEditor sehen nicht aus wie System-Umgebungsvariablen. Richtig: $JAVA_HOME.
Q6 Single Choice
In einem Terminal gibst du nacheinander folgende Befehle ein:
```
NAME="Tim"
bash
echo $NAME
```
Der dritte Befehl echo $NAME wird innerhalb der neu gestarteten Bash ausgeführt (also direkt nach bash, ohne vorheriges exit). Was gibt der echo-Befehl aus?
a) Tim b) $NAME c) Eine leere Zeile d) Eine Fehlermeldung „NAME not defined"

✓ Richtig! Ohne export ist NAME nur eine Shell-Variable der ersten Bash. Die zweite Bash (Kind-Prozess) erbt sie nicht — $NAME ist dort leer, also gibt echo eine leere Zeile aus. Erst mit export NAME wäre sie vererbt worden.

✗ Nicht ganz. Variablen ohne export bleiben in der aktuellen Shell. Wenn du eine neue Bash startest, ist die Variable in der neuen Shell nicht definiert. echo gibt für undefinierte Variablen eine leere Zeile aus (keinen Fehler). Nur mit export NAME würde die zweite Bash Tim ausgeben.
Q7 Multiple Choice

Welche der folgenden Befehle fahren ein Linux-System herunter UND schalten die Hardware ab? (mehrere richtig möglich)

a) sudo shutdown now b) sudo poweroff c) sudo systemctl halt d) sudo systemctl isolate poweroff.target e) sudo reboot

✓ Richtig! Drei korrekte Wege zum vollständigen Herunterfahren: shutdown now, poweroff, und der systemd-Weg systemctl isolate poweroff.target. Alle drei stoppen das System und schalten die Hardware ab. systemctl halt stoppt zwar das System, schaltet die Hardware aber NICHT ab — heute meist unerwünscht. reboot ist ein Neustart.

✗ Nicht ganz. Richtig sind a) shutdown now, b) poweroff und d) systemctl isolate poweroff.target — alle drei fahren herunter und schalten die Hardware ab. systemctl halt stoppt zwar das System, schaltet die Hardware nicht ab. reboot ist ein Neustart.
Q8 Single Choice

Ein laufender htop-Prozess auf dem Server reagiert nicht mehr auf Tastatureingaben. Du hast seine PID mit pgrep htop zu 8842 ermittelt. Welcher Befehl beendet ihn als ersten, höflichen Versuch?

a) kill -9 8842 b) kill 8842 c) killall -9 htop d) terminate 8842

✓ Richtig! kill PID (ohne Optionen) sendet SIGTERM — den höflichen Beendigungs-Aufruf. Der Prozess kann noch aufräumen (Dateien schließen etc.). kill -9 ist SIGKILL — die Brachialvariante, erst wenn höflich nicht reicht. killall mit -9 ist auch zu hart als erster Schritt. terminate gibt es nicht.

✗ Nicht ganz. Faustregel: erst höflich, dann brutal. kill 8842 schickt SIGTERM — der Prozess kann sich aufräumen. Erst wenn das nicht hilft (nach ~5 Sek.), nimmt man kill -9 8842 (SIGKILL). terminate existiert nicht als Befehl.
Q9 Single Choice

Du startest in der Shell einen Backup-Job, der die CPU stark beansprucht. Mit ps -alf siehst du, dass er PID 5421 hat und aktuell mit NI=0 läuft. Du willst seinen Niceness-Wert auf +15 hochsetzen, damit andere Prozesse Vorrang haben. Welcher Befehl ist richtig?

a) nice -n 15 5421 b) sudo renice 15 -p 5421 c) sudo nice -n 15 -p 5421 d) kill -15 5421

✓ Richtig! renice ändert die Niceness laufender Prozesse — Syntax: renice WERT -p PID. Hinweis: Für positive Werte (= „höflicher", andere Prozesse bekommen Vorrang) braucht es eigentlich kein sudo — das schadet hier aber nicht. Negative Werte (höhere Priorität) verlangen sudo. nice -n 15 wäre für einen neuen Prozess; ein -p-Flag kennt nice nicht. kill -15 ist SIGTERM und beendet den Prozess komplett.

✗ Nicht ganz. Für laufende Prozesse ist renice das Werkzeug. Syntax: renice WERT -p PID. nice kennt kein -p-Flag und funktioniert nur beim Starten eines Prozesses, nicht für laufende. kill -15 ist SIGTERM und würde den Prozess beenden, nicht priorisieren.
⭐

Bonus-Frage (optional) — behandelt einen Bonus-Inhalt.

Q10 Single Choice

In Terminal A startest du einen Hintergrund-Job: sleep 600 &. In Terminal B (gleicher User, gleicher Server) tippst du jobs. Was siehst du in Terminal B?

a) Den sleep 600-Job aus Terminal A b) Eine leere Liste c) Eine Fehlermeldung „no permission" d) Alle Prozesse des Users (inklusive sleep)

✓ Richtig! jobs zeigt nur Jobs der aktuellen Shell — also nur Hintergrund-Prozesse, die DU in genau dieser Terminal-Session mit & gestartet hast. Terminal B ist eine andere Shell-Session, kennt deshalb die Jobs aus Terminal A nicht. Für eine systemweite Sicht nimmst du ps -ef | grep sleep.

✗ Nicht ganz. jobs ist eine Shell-lokale Liste — nur die Jobs, die in DIESER Shell mit & in den Hintergrund geschickt wurden. Terminal B ist eine andere Shell und sieht deshalb eine leere Liste. Wenn du alle sleep-Prozesse systemweit sehen willst: ps -ef | grep sleep.
Q11 Multiple Choice

Welche der folgenden Befehle starten ein Linux-System tatsächlich neu? (mehrere richtig möglich)

a) sudo reboot b) sudo shutdown -r now c) sudo systemctl reboot d) sudo init 0 e) sudo shutdown -h now

✓ Richtig! Drei korrekte Neustart-Befehle: reboot, shutdown -r now (r = restart), und der systemd-Weg systemctl reboot. init 0 fährt das System herunter (Runlevel 0 = Halt). shutdown -h now fährt herunter (h = halt, nicht reboot).

✗ Nicht ganz. Für Neustart: reboot, shutdown -r now, systemctl reboot. Der Buchstabe -r im shutdown-Befehl steht für restart. init 0 und shutdown -h now sind zum Herunterfahren (h = halt, 0 = Halt-Runlevel).
Q12 Single Choice

Du hast ein Bash-Skript backup.sh geschrieben, aber keine Shebang-Zeile (#!/bin/bash) eingefügt. Du machst es mit chmod +x backup.sh ausführbar. Was passiert beim Aufruf von ./backup.sh?

a) Die Datei läuft garantiert mit Bash b) Das Verhalten ist nicht zuverlässig — abhängig von Shell und System c) Es kommt zwingend eine Fehlermeldung „missing shebang" d) Bash wird automatisch ergänzt vor dem Ausführen

✓ Richtig! Ohne Shebang fällt der Kernel je nach System auf /bin/sh zurück (das auf vielen Linux-Distributionen ein Symlink zu Bash ist, aber im POSIX-Modus läuft) — manchmal funktioniert das, manchmal nicht. „Garantiert" ist es nicht: bash-spezifische Syntax (z. B. [[ ... ]], Arrays) kann im POSIX-Modus brechen, andere Distros werfen Fehler. Deshalb: immer mit Shebang anfangen. Alternativ explizit aufrufen mit bash ./backup.sh — dann ist der Interpreter eindeutig.

✗ Nicht ganz. Ohne Shebang ist das Verhalten nicht zuverlässig — der Kernel fällt oft auf /bin/sh zurück, das im POSIX-Modus läuft. Bash-spezifische Syntax kann dann brechen, andere Distros werfen Fehler. „Garantiert mit Bash" stimmt also nicht — Antwort a) ist zu absolut. Antwort c) (zwingende Fehlermeldung) und d) (automatische Ergänzung) stimmen auch nicht. Best Practice: #!/bin/bash in jede Skript-Datei als Zeile 1.

🎯

Quiz durchgearbeitet?

Wie waren deine Trefferquote? Wenn du 8 von 12 oder mehr richtig hattest, sitzt der Stoff solide. Bei weniger: schau dir die entsprechenden Kapitel nochmal an — die Konzepte sind das Wichtige, nicht die Antwortauswahl auswendig zu lernen.

Wenn du dich gut fühlst: Schau dir das Cheat-Sheet an, drucke es aus, hänge es neben deinen Monitor.

📚

Wo du nachschlagen kannst

Q1, Q4 (Boot, GRUB) → Kapitel 01 · Bootprozess
Q2, Q7, Q11 (Targets, Shutdown, Reboot) → Kapitel 02 · systemd
Q8, Q9, Q10 (kill, renice, jobs) → Kapitel 03 · Prozesse
Q3 (dnf update/upgrade) → Kapitel 04 · dnf
Q5, Q6 (Variablen, export) → Kapitel 05 · Umgebungsvariablen
Q12 (Shebang) → Kapitel 06 · Skripte

Tages-Quiz Tag 3