LSS - Lecture III - systemd.pdf

# Introductie tot systemd en zijn rol Dit topic introduceert systemd als de moderne opvolger van het SysV init systeem, waarbij de basisprincipes, de command-line interface en de verschillen met oudere methoden worden besproken. ## 1. Introductie tot systemd en zijn rol systemd is een modern init systeem en service manager voor Linux-besturingssystemen, ontworpen als opvolger van het traditionele System V init systeem. Het primaire doel van systemd is om de initiële proces-ID 1 te zijn en het opstarten van het systeem te beheren. In tegenstelling tot het oudere SysV init dat gebruik maakte van scripts en 'runlevels', hanteert systemd een meer monolithische aanpak met 'units'. Deze modernisering heeft geleid tot kritiek, maar biedt ook significante voordelen in termen van configuratie, service management en opstarttijd [4](#page=4) [5](#page=5) [6](#page=6). ### 1.1 De evolutie van init systemen #### 1.1.1 System V init Het traditionele System V init systeem maakte gebruik van een reeks scripts, voornamelijk geplaatst in `/etc/init.d/`, om services te starten, stoppen en herladen. Dit systeem werkte met 'runlevels', die verschillende staten van het systeem vertegenwoordigden (bijvoorbeeld multi-user mode, graphical mode). Het beheren van afhankelijkheden tussen services was vaak complex en foutgevoelig met dit model [5](#page=5) [6](#page=6). #### 1.1.2 systemd als opvolger systemd neemt de rol van PID 1 over van het oude init proces. Het is ontworpen om efficiënter, flexibeler en makkelijker te beheren te zijn. De kernconcepten van systemd zijn gebaseerd op 'units', die een brede reeks systeemcomponenten en acties kunnen vertegenwoordigen [10](#page=10) [4](#page=4) [6](#page=6). > **Tip:** Begrijpen hoe systemd verschilt van oudere init-systemen is cruciaal voor het effectief beheren van moderne Linux-systemen. ### 1.2 Kernconcepten van systemd #### 1.2.1 Systemd units Een systemd 'unit' is een fundamenteel concept dat een service, een actie, of een systeemcomponent definieert. Elke unit bestaat uit [10](#page=10) [13](#page=13) [14](#page=14) [15](#page=15) [16](#page=16) [17](#page=17) [18](#page=18) [19](#page=19) [20](#page=20) [21](#page=21) [22](#page=22) [23](#page=23) [26](#page=26) [38](#page=38) [39](#page=39) [42](#page=42) [44](#page=44): * **Naam:** De identificatie van de unit (bv. `ssh`). * **Type:** Het soort component dat de unit vertegenwoordigt (bv. `service`, `target`). * **Configuratiebestand:** Het bestand dat de parameters en gedragingen van de unit definieert. De naamgeving van units volgt het formaat `naam.type` [15](#page=15) [20](#page=20) [21](#page=21). #### 1.2.2 Unit types systemd ondersteunt verschillende types units, elk met een specifiek doel [16](#page=16): * `.automount`: Voor het beheren van automounts [16](#page=16). * `.device`: Representeert een kernel device zoals gerapporteerd door udev, bv. `dev-sda.device` [39](#page=39). * `.mount`: Representeert een gemount bestandssysteem, bv. `boot.mount` voor `/boot` of `-.mount` voor `/` [42](#page=42). * `.path`: Units die geactiveerd worden wanneer een bepaald pad verandert of bestaat [16](#page=16). * `.service`: Wordt gebruikt om daemons en services op het Linux-systeem te beheren, bv. `ssh.service` [17](#page=17). * `.snapshot`: Een snapshot van de huidige systeemtoestand [16](#page=16). * `.socket`: Voor het beheren van socket-activatie [16](#page=16). * `.target`: Groepeert meerdere units samen zodat ze tegelijkertijd kunnen worden gestart. Ze worden vaak gebruikt om de opstart- of shutdown-status van het systeem te definiëren, bv. `network.target` [18](#page=18). #### 1.2.3 Configuratiebestanden Unit configuratiebestanden specificeren het gedrag van units. Deze bestanden bevinden zich op verschillende locaties: * `/etc/systemd/system`: Voor lokale en permanente aangepaste configuraties [33](#page=33). * `/run/systemd/system`: Voor runtime configuraties die dynamisch worden gegenereerd [33](#page=33). * `/lib/systemd/system`: Voor distributie-brede standaardconfiguraties [33](#page=33). systemd zoekt in deze directories in de genoemde volgorde en stopt bij de eerste match [33](#page=33). Belangrijke secties in configuratiebestanden zijn: * `[Unit]`: Bevat informatie over de unit zelf en afhankelijkheden. Secties zoals `After`, `Before`, `Requires`, `Wants`, `Conflicts`, en `Requisite` definiëren expliciete relaties tussen units [23](#page=23) [24](#page=24). * `Requires`: Strikte afhankelijkheden. Als de vereiste unit faalt, faalt de huidige unit ook [24](#page=24). * `Wants`: Afhankelijkheden voor activering. Als de gewenste unit faalt, heeft dat geen invloed op de huidige unit. Dit is de aanbevolen manier om afhankelijkheden te specificeren [24](#page=24). * `Requisite`: Units die reeds actief moeten zijn voor activering [24](#page=24). * `Conflicts`: Negatieve afhankelijkheden. Activering van de ene unit deactiveert de andere unit, en omgekeerd [24](#page=24). * `[Service]`: Specificeert hoe een service unit moet worden beheerd. Belangrijke parameters zijn `ExecStart` (het programma dat gestart moet worden) en `Restart` (wanneer de service automatisch herstart moet worden) [22](#page=22). * `[Install]`: Bevat informatie over hoe de unit geïnstalleerd en geactiveerd moet worden, met name parameters zoals `WantedBy` en `RequiredBy` [26](#page=26). #### 1.2.4 Afhankelijkheden "in reverse" Afhankelijkheden kunnen ook "omgekeerd" worden geconfigureerd. Een unit A kan bijvoorbeeld een `Wants` afhankelijkheid zijn voor unit B. Dit kan worden ingesteld door in de configuratie van unit A een `WantedBy` sectie te hebben die verwijst naar B.service. Dit stelt gebruikers in staat om afhankelijkheden dynamisch te activeren of deactiveren met commando's als `systemctl enable A.service` en `systemctl disable A.service`. Dit creëert of verwijdert symbolische links in directories zoals `/etc/systemd/system/B.service.wants/` [25](#page=25). #### 1.2.5 Default Target De `default.target` unit bepaalt het "doel" waar het systeem naartoe moet opstarten. Dit is vaak een symbolische link naar een specifiekere target unit, zoals `multi-user.target` of `graphical.target` [27](#page=27). #### 1.2.6 Het opstartproces met systemd Bij het opstarten van het systeem doorloopt systemd de volgende stappen [32](#page=32): 1. systemd laadt zijn configuratie. 2. systemd bepaalt het boot-doel, meestal `default.target`. 3. systemd analyseert alle afhankelijkheden van het `default.target`, en vervolgens de afhankelijkheden van die afhankelijkheden, recursief. 4. systemd activeert de benodigde dependencies en het uiteindelijke doel. 5. Na het opstarten kan systemd reageren op systeemgebeurtenissen en additionele componenten activeren [32](#page=32). ### 1.3 De command-line interface: `systemctl` `systemctl` is het primaire commando voor het beheren van systemd en zijn units. Het is belangrijk om `systemctl` niet te verwarren met `sysctl`, dat wordt gebruikt om kernel-attributen te lezen en te wijzigen [10](#page=10) [8](#page=8). #### 1.3.1 Belangrijke `systemctl` commando's * `systemctl status `: Toont de status van een specifieke unit [31](#page=31) [7](#page=7). * `systemctl start `: Start een unit. Dit start de service maar creëert geen dependencies zoals gedefinieerd in de `[Install]` sectie [31](#page=31) [32](#page=32). * `systemctl stop `: Stopt een actieve unit [31](#page=31) [33](#page=33). * `systemctl restart `: Herstart een unit [31](#page=31). * `systemctl daemon-reload`: Herlaadt de systemd manager configuratie, inclusief alle unit files [31](#page=31). * `systemctl enable `: Configureert de unit om automatisch te starten met andere geselecteerde units. Dit creëert symbolische links in de `wants` directory van de target unit en start de unit *niet* direct [31](#page=31) [32](#page=32). * `systemctl disable `: Verwijdert de configuratie die ervoor zorgt dat een unit automatisch start. Dit stopt de unit niet als deze actief is [31](#page=31) [33](#page=33). * `systemctl mask `: Blokkeert een unit zodat deze niet gestart kan worden, handmatig of automatisch. Dit gebeurt door een symbolische link naar `/dev/null` te creëren [31](#page=31) [33](#page=33). * `systemctl unmask `: Hef de maskering van een unit op [31](#page=31). * `systemctl list-units`: Toont de huidige status van alle geconfigureerde units [11](#page=11) [31](#page=31). * `systemctl --failed`: Toont alleen de units die gefaald zijn [31](#page=31). * `systemctl isolate `: Start de gespecificeerde unit en stopt alle andere [31](#page=31). * `systemctl default`: Schakelt over naar de default target unit [31](#page=31). * `systemctl cat `: Toont de inhoud van het configuratiebestand van een unit [31](#page=31). #### 1.3.2 Starten vs. Enable Het is essentieel om het verschil te begrijpen tussen `start` en `enable`: * `systemctl start`: Start de service onmiddellijk, maar negeert de installatie-afhankelijkheden [32](#page=32). * `systemctl enable`: Zorgt ervoor dat de unit automatisch wordt gestart bij toekomstige boots, maar start de unit niet direct [32](#page=32). Om een unit zowel te starten als in te schakelen, kan `--now` worden gebruikt: `systemctl enable --now ` [32](#page=32). #### 1.3.3 Stoppen, Disablen en Masken * `systemctl stop`: Stopt een actieve service [33](#page=33). * `systemctl disable`: Voorkomt dat een service automatisch start bij toekomstige boots, maar stopt deze niet als deze al draait [33](#page=33). * `systemctl mask`: Voorkomt dat een service ooit nog draait, door deze te koppelen aan `/dev/null` [33](#page=33). ### 1.4 Systeembeheer met systemd #### 1.4.1 `shutdown` en `reboot` commando's Op moderne systemen die systemd gebruiken, zijn de `shutdown` en `reboot` commando's vaak symbolische links naar `systemctl`. Dit betekent dat deze commando's nu worden afgehandeld door systemd's unit management systeem [3](#page=3). #### 1.4.2 Logs bekijken met `journalctl` `journalctl` is het commando voor het inzien van de logs beheerd door systemd's journal. Enkele nuttige opties zijn [35](#page=35): * `journalctl -xe`: Ga naar het einde van de log en geef uitleg over de fouten (-x) [35](#page=35). * `journalctl -xef`: Blijf nieuwe log-items volgen (-f) [35](#page=35). * `journalctl -xef -u `: Toon logs alleen voor een specifieke unit [35](#page=35). * `journalctl -b -1`: Toon berichten van de vorige systeem boot [35](#page=35). * `journalctl -k`: Toon alleen kernelberichten [35](#page=35). * `journalctl --since yesterday`: Filter berichten vanaf gisteren [35](#page=35). * `journalctl --since "YYYY-MM-DD" --until "YYYY-MM-DD"`: Filter op een tijdsinterval [35](#page=35). #### 1.4.3 Systeem analyse met `systemd-analyze` `systemd-analyze` biedt hulpmiddelen voor het analyseren van het systeem en de opstarttijd [44](#page=44): * `systemd-analyze time`: Geeft de totale opstarttijd weer [44](#page=44). * `systemd-analyze blame`: Toont een lijst van units gesorteerd op de tijd die ze nodig hadden om te initialiseren [44](#page=44). * `systemd-analyze critical-chain`: Visualiseert de kritieke keten van units tijdens het opstarten [44](#page=44). * `systemd-analyze plot > file.svg`: Genereert een SVG-bestand dat de opstart-volgorde visualiseert [44](#page=44). * `systemd-analyze security`: Analyseert de beveiligingsgerelateerde instellingen van systemd-managed services . ### 1.5 De adoptie van systemd in Linux distributies De meeste mainstream Linux-distributies gebruiken systemd standaard. Enkele voorbeelden zijn [12](#page=12): * Fedora (vanaf versie 15) [12](#page=12). * Red Hat Enterprise Linux 7 [12](#page=12). * SUSE Linux Enterprise Server 12 [12](#page=12). * Debian 8 [12](#page=12). * Ubuntu 15.04 [12](#page=12). systemd wordt beschouwd als meer dan alleen een vervanging voor `init.d` [40](#page=40). > **Tip:** Raadpleeg de man-pagina's (`man systemd.unit`, `man systemd.service`, `man systemd.target`) voor gedetailleerde informatie over systemd units en hun configuratie. --- # Systemd unit types en configuratie Dit topic behandelt de verschillende types systemd units, zoals services, targets en devices, en hoe deze units worden geconfigureerd via specifieke configuratiebestanden [10](#page=10) [13](#page=13) [14](#page=14) [15](#page=15) [16](#page=16) [17](#page=17) [18](#page=18) [19](#page=19) [20](#page=20) [21](#page=21) [22](#page=22) [23](#page=23) [24](#page=24) [25](#page=25) [26](#page=26) [27](#page=27) [29](#page=29) [38](#page=38) [39](#page=39) [42](#page=42). ### 2.1 Systemd units: de basis Een systemd ‘unit’ definieert een service of actie op het systeem. Een unit bestaat uit [10](#page=10) [14](#page=14) [15](#page=15) [20](#page=20) [21](#page=21) [39](#page=39) [42](#page=42): * Een naam [10](#page=10) [14](#page=14) [15](#page=15) [20](#page=20) [21](#page=21) [39](#page=39) [42](#page=42). * Een type [10](#page=10) [14](#page=14) [15](#page=15) [20](#page=20) [21](#page=21) [39](#page=39) [42](#page=42). * Een configuratiebestand [10](#page=10) [14](#page=14) [15](#page=15) [20](#page=20) [21](#page=21) [39](#page=39) [42](#page=42). Systemd identificeert units door hun naam en type met de notatie ‘naam.type’. Een voorbeeld hiervan is `ssh.service` [15](#page=15) [20](#page=20) [21](#page=21). #### 2.1.1 Verschillende unit types Er zijn diverse typen systemd units, waaronder [16](#page=16) [17](#page=17) [18](#page=18) [39](#page=39) [42](#page=42): * `automount`: voor het automatisch mounten van filesystems. * `device`: representeert een kernel device, zoals gerapporteerd door udev (bv. `/dev/sda`). Systemd genereert deze units automatisch, bijvoorbeeld `dev-sda.device`. Andere units kunnen afhankelijk zijn van devices via `After=dev-sda.device` [39](#page=39). * `mount`: representeert een gemounte filesystem, gebaseerd op de `/etc/fstab` configuratie. Voorbeelden zijn `boot.mount` voor `/boot` en `-.mount` voor de root filesystem `/` [42](#page=42). * `path`: gerelateerd aan bestandsgebaseerde activatie. * `service`: gebruikt om daemons op het Linux systeem te beheren. Een voorbeeld is `ssh.service` [17](#page=17). * `snapshot`: voor het maken van systeem snapshots. * `socket`: voor het beheren van netwerk sockets. * `target`: gebruikt om meerdere units te groeperen, zodat ze tegelijkertijd gestart kunnen worden. Een voorbeeld is `network.target` [18](#page=18). #### 2.1.2 De ‘Default Target’ Het `/lib/systemd/system/default.target` bestand bepaalt welk target het systeem opstart. Dit bestand is vaak een symbolische link naar een specifiek target [27](#page=27). ### 2.2 Configuratie van systemd units De configuratiebestanden voor systemd units bepalen hoe deze units zich gedragen [19](#page=19). #### 2.2.1 Locatie van configuratiebestanden Systemd zoekt naar configuratiebestanden in de volgende directories, in deze volgorde [29](#page=29): 1. `/etc/systemd/system`: Voor lokale en permanente configuraties. Deze configuraties worden niet overschreven door pakketupdates [29](#page=29). 2. `/run/systemd/system`: Voor runtime configuratie. 3. `/lib/systemd/system`: Voor distributie-brede configuratie. Systemd stopt met zoeken zodra het een overeenkomend bestand vindt. Het wordt aangeraden om aangepaste en/of permanentere configuraties in `/etc/systemd/system` te plaatsen [29](#page=29). #### 2.2.2 Configuratie secties en opties Configuratiebestanden van systemd units bevatten verschillende secties die het gedrag van de unit bepalen. ##### 2.2.2.1 De `[Service]` sectie Deze sectie is specifiek voor `service`-type units. Belangrijke opties zijn [22](#page=22) [25](#page=25): * `ExecStart`: Definieert het commando dat gestart moet worden wanneer de service actief wordt [22](#page=22). * `Restart`: Bepaalt wanneer de service automatisch herstart moet worden [22](#page=22). ##### 2.2.2.2 De `[Unit]` sectie Deze sectie is van toepassing op alle unit types, inclusief `target` en `service` units. Opties hierin definiëren dependencies [23](#page=23) [24](#page=24): * `After` / `Before`: Specificeert welke units moeten draaien vóór of ná de huidige unit [23](#page=23). * `Requires` / `Wants` / `Conflicts` / `Requisite`: Definieert expliciete dependencies [23](#page=23). **Tabel 2.1: Verschillende types dependencies in de `[Unit]` sectie** [24](#page=24). | Dependency Type | Beschrijving | Wanneer/welke falen? | | :-------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Requires=B.service` | Strikte dependencies. Bij het activeren van A.service, activeert systemd ook B.service. Als B.service faalt, deactiveert systemd A.service. | Als B.service faalt, faalt A.service. | | `Wants=C.service` | Dependencies voor activatie alleen. Bij het activeren van A.service, activeert systemd ook C.service. Als C.service faalt, heeft dit geen invloed op A.service. | Als C.service faalt, heeft dit geen invloed op A.service. **Tip:** Systemd documentatie stelt dat dit de voorkeursmanier is om dependencies te specificeren indien mogelijk, omdat het falen niet doorgegeven wordt aan andere units. | [24](#page=24). | `Requisite=D.service`| Units die al actief moeten zijn. Vóór het activeren van A.service, controleert systemd D.service. Als D.service niet actief is, faalt de activatie van A.service. | Als D.service niet actief is, faalt de activatie van A.service. | | `Conflicts=E.service`| Negatieve dependencies. Bij het activeren van A.service, deactiveert systemd E.service. Gelijktijdige activatie van twee conflicterende units faalt. | Gelijktijdige activatie van conflicterende units faalt. | Men kan dependencies ook "in reverse" toevoegen. Bijvoorbeeld, om Unit A toe te voegen als `Wants`-dependency aan Unit B, hoeft de `Wants`-declaratie niet in Unit B's configuratie te staan. In plaats daarvan kan men `WantedBy` in Unit A's configuratie gebruiken (vergelijkbaar voor `RequiredBy`). Deze dependency kan dynamisch geactiveerd of gedeactiveerd worden met `# systemctl enable A.service` en `# systemctl disable A.service`. Dit creëert/verwijderd symbolische links in de `/etc/systemd/system/B.service.wants/` directory naar `A.service` [25](#page=25). Men kan de dependencies van een unit bekijken met het `systemctl` commando, bijvoorbeeld: `# systemctl list-dependencies A.service` of `# systemctl list-dependencies A.service --reverse` en `# systemctl show -p Wants B.service` [24](#page=24) [25](#page=25). ##### 2.2.2.3 De `[Install]` sectie Deze sectie wordt gebruikt om installatie-informatie te specificeren voor units, vaak in combinatie met `target` en `service` units [26](#page=26). * `WantedBy` / `RequiredBy`: Specificeert het target level waarin het systeem moet zijn om deze unit te activeren. Dit wordt gebruikt in combinatie met de `enable` en `disable` commando's om dependencies dynamisch te beheren [25](#page=25) [26](#page=26). --- # Besturing en analyse van systemd Dit topic behandelt de commando's voor het beheren van systemd-units en het analyseren van systeemprestaties [30](#page=30). ### 3.1 Beheer van units met systemctl `systemctl` is het primaire commando voor het beheren van systemd-service en target units [31](#page=31). #### 3.1.1 Unit status en informatie * `systemctl status `: Toont de status van de gespecificeerde unit [31](#page=31). * `systemctl list-units`: Geeft de huidige status van alle geconfigureerde units weer [11](#page=11) [31](#page=31). * `systemctl list-unit-files`: Toont de status van alle unit-bestanden [11](#page=11). * `systemctl --failed`: Geeft een lijst van mislukte units weer [31](#page=31). * `systemctl cat `: Print het systemd configuratiebestand van de gespecificeerde unit [31](#page=31). #### 3.1.2 Services starten, stoppen en herladen * `systemctl start `: Start de gespecificeerde unit. Dit start de service zelf, maar creëert geen dependencies zoals gedefinieerd in de `[Install]` sectie [31](#page=31) [32](#page=32). * `systemctl stop `: Stopt een actieve service [31](#page=31) [33](#page=33). * `systemctl restart `: Schakelt de unit uit en start deze opnieuw [31](#page=31). * `systemctl daemon-reload`: Herlaadt de systemd manager configuratie en alle unit-bestanden [31](#page=31). #### 3.1.3 Units inschakelen en uitschakelen * `systemctl enable `: Configureert de unit om automatisch te starten met andere geselecteerde units. Dit koppelt de unit aan verschillende plekken om ervoor te zorgen dat deze automatisch opstart met andere units, maar start de unit zelf niet. Bijvoorbeeld, als `A.service` een `WantedBy=B.target` heeft in zijn configuratie, zal `systemctl enable A.service` een symlink creëren in `/etc/systemd/system/B.target.wants/` [31](#page=31) [32](#page=32). * `systemctl disable `: Configureert de unit om niet automatisch te starten met andere units. Dit voorkomt dat een service, zoals `A.service`, zelfstandig start, maar stopt de momenteel actieve unit niet [31](#page=31) [33](#page=33). #### 3.1.4 Maskeren van units * `systemctl mask `: Markeer een unit als volledig onstartbaar, zowel automatisch als handmatig. Dit voorkomt dat een service ooit op het systeem draait door een symbolische link naar `/dev/null` aan te maken [31](#page=31) [33](#page=33). * `systemctl unmask `: Maakt het maskeren ongedaan [31](#page=31). #### 3.1.5 Gecombineerd starten en inschakelen * `systemctl enable --now`: Combineert het inschakelen en starten van een unit [32](#page=32). > **Tip:** Starten en inschakelen zijn orthogonaal: units kunnen ingeschakeld zijn zonder te starten, en gestart zijn zonder ingeschakeld te zijn [32](#page=32). #### 3.1.6 Isoleren en defaults * `systemctl isolate `: Start de gespecificeerde unit en stopt alle andere [31](#page=31). * `systemctl default`: Wijzigt naar de standaard target unit [31](#page=31). #### 3.1.7 Dependencies beheren Dependencies kunnen ook "omgekeerd" worden toegevoegd. Om Unit A toe te voegen als een `Wants` dependency aan Unit B, hoeft de `Wants` niet in de configuratie van Unit B te worden toegevoegd. Dit kan worden gedaan via `systemctl enable A.service`, wat symlinks creëert in `/etc/systemd/system/B.service.wants/` [25](#page=25). * `systemctl show -p Wants B.service`: Geeft de dependencies van een unit weer [25](#page=25). ### 3.2 Systeemanalyse met systemd-analyze `systemd-analyze` wordt gebruikt om systeemprestaties en opstarttijden te analyseren [36](#page=36). * `systemd-analyze time`: Analyseert de opstarttijd van het systeem [36](#page=36). * `systemd-analyze blame`: Toont een lijst van units gesorteerd op hun opstarttijd, om zo de meest tijdrovende units te identificeren [36](#page=36). * `systemd-analyze critical-chain`: Toont de kritieke keten van units die nodig zijn voor het opstarten van een specifieke unit, met hun opstarttijden [36](#page=36). * `systemd-analyze plot > file.svg`: Genereert een SVG-afbeelding van de opstartketen, wat visueel inzicht geeft in het opstartproces [36](#page=36). * `systemd-analyze security`: Analyseert de per-service beveiligingsfuncties die systemd implementeert. Hoge blootstellingsniveaus kunnen duiden op een potentiële behoefte aan aanvullende beveiligingsinstellingen [37](#page=37). ### 3.3 Logboekweergave met journalctl `journalctl` wordt gebruikt om de logboeken van systemd te bekijken [35](#page=35). * `journalctl -xe`: Gaat naar het einde van het logboek en geeft uitleg [35](#page=35). * `journalctl -xef`: Blijft nieuwe logboekvermeldingen volgen [35](#page=35). * `journalctl -xef -u `: Toont alleen logboeken voor de gespecificeerde unit [35](#page=35). * `journalctl -b -1`: Toont berichten van de laatste systeemopstart [35](#page=35). * `journalctl -k`: Toont alleen kernelberichten [35](#page=35). * `journalctl --no-pager`: Handig voor parsing op stdout [35](#page=35). * `journalctl -u nginx -o json-pretty`: Output in JSON-formaat [35](#page=35). * `journalctl --since yesterday`: Filtert op gegevens vanaf gisteren [35](#page=35). * `--since “2019-01-10” --until “…”`: Filtert op een start- en einddatum (tijd kan worden opgenomen) [35](#page=35). > **Tip:** Verhoogde permissies kunnen vereist zijn om bepaalde logboekvermeldingen te zien [35](#page=35). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | systemd | systemd is een systeem- en servicebeheerder voor Linux-besturingssystemen, bedoeld om een alternatief te bieden voor de traditionele init-daemon en om de systeeminitialisatie en servicebeheer te moderniseren. | | init daemon | De init daemon (initialization daemon) is het eerste proces dat op het besturingssysteem wordt gestart na de kernel. Het is verantwoordelijk voor het starten en beheren van andere processen en services tijdens het opstarten van het systeem. | | runlevels | Runlevels zijn modi waarin een Unix-achtig besturingssysteem kan opereren. Elk runlevel is geassocieerd met een specifieke set draaiende services en processen. | | unit | Een systemd-unit is een basisbouwsteen die een systeemcomponent zoals een service, device, mount point, of target vertegenwoordigt. Elke unit wordt gedefinieerd door een configuratiebestand. | | service | Een systemd-service unit beheert een daemon of applicatie die op de achtergrond draait. Het definieert hoe de service gestart, gestopt en herstart moet worden. | | target | Een systemd-target unit is vergelijkbaar met runlevels in oudere init-systemen. Het groepeert meerdere units die samen opgestart moeten worden om een bepaalde systeemtoestand te bereiken, zoals "graphical.target" voor de grafische omgeving. | | automount unit | Een automount unit in systemd beheert het automatisch mounten van bestandssystemen wanneer deze nodig zijn, vaak geassocieerd met de /etc/fstab-configuratie. | | device unit | Een device unit in systemd vertegenwoordigt een kernelapparaat dat door udev wordt gerapporteerd, zoals `/dev/sda`. Andere units kunnen afhankelijkheden hebben van deze device units. | | mount unit | Een mount unit in systemd vertegenwoordigt een gemount bestandssysteem, zoals de root (/) of /boot. systemd leest configuratie uit /etc/fstab om deze units te creëren. | | path unit | Een path unit in systemd reageert op gebeurtenissen op bestandssysteemobjecten, zoals het aanmaken, wijzigen of verwijderen van bestanden of mappen. | | socket unit | Een socket unit in systemd beheert netwerk- of Unix domain sockets. Het kan worden gebruikt om services te starten wanneer er een verbinding binnenkomt op een specifieke socket. | | snapshot unit | Een snapshot unit in systemd bevriest de huidige systeemtoestand, waardoor het mogelijk is om terug te keren naar die toestand. | | systemctl | systemctl is het primaire commando-regelprogramma voor het beheren van systemd. Het wordt gebruikt om units te starten, stoppen, inschakelen, uitschakelen en hun status te controleren. | | sysctl | sysctl is een commando dat wordt gebruikt om de attributen van de Linux-kernel tijdens het draaien te lezen en aan te passen, zoals netwerkinstellingen. | | journalctl | journalctl is een commando-regelprogramma voor het bekijken en filteren van logs die door systemd's journal worden verzameld. Het biedt gedetailleerde informatie over systeemgebeurtenissen. | | systemd-analyze | systemd-analyze is een tool binnen systemd die wordt gebruikt om de opstarttijd van het systeem en individuele units te analyseren, en om beveiligingsaspecten van services te evalueren. |