LSS - Lecture III - systemd.pdf

# Introductie tot systemd Dit gedeelte introduceert systemd als de moderne opvolger van traditionele init-systemen, waarbij de basisconcepten, commando's en voordelen worden uitgelegd [2](#page=2) [5](#page=5). ## 1.1 Wat is systemd? systemd is een systeem- en servicebeheerder voor Linux-besturingssystemen. Het is ontworpen als een moderne vervanging voor oudere init-systemen zoals System V init, die gebaseerd waren op een daemon met veel kleine initialisatiescripts en 'runlevels'. systemd werkt als een monolithisch programma dat gebruik maakt van 'units'. Het draait als proces met PID 1 en wordt vaak geïnitieerd als '/sbin/init' [4](#page=4) [5](#page=5). ### 1.1.1 De rol van PID 1 Het proces met Process ID (PID) 1 is het allereerste proces dat wordt gestart na de kernel tijdens het opstarten van het systeem. Van oudsher was dit de init daemon. Met systemd is dit proces ook de systemd-manager [4](#page=4) [5](#page=5). ### 1.1.2 Verschil met System V init systemd wijkt af van de traditionele Linux-filosofie van veel kleine, gespecialiseerde programma's, wat soms kritiek oplevert [5](#page=5). ### 1.1.3 Voordelen van systemd ten opzichte van System V init systemd biedt diverse verbeteringen ten opzichte van oudere init-systemen: * **Eenvoudigere en logischere configuratie** [6](#page=6). * **Expliciete afhankelijkheden tussen services** [6](#page=6). * **Makkelijk instellen van permissies en resource limieten per service** [6](#page=6). * **Monitoring en automatische herstart van services** [6](#page=6). * **Watchdogs** voor zowel services als systemd zelf [6](#page=6). * **Parallel starten van services**, wat de opstarttijd verkort [6](#page=6). ### 1.1.4 systemctl vs. sysctl Het is belangrijk om `systemctl` niet te verwarren met `sysctl`. * `systemctl` wordt gebruikt om systemd te beheren [8](#page=8). * `sysctl` wordt gebruikt om de attributen van de Linux kernel te lezen en aan te passen, zoals eerder gezien bij `net.ipv4.ip_forward` [8](#page=8). ### 1.1.5 systemd in distributies De meeste gangbare Linux-distributies gebruiken tegenwoordig systemd als standaard init-systeem. Voorbeelden hiervan zijn [9](#page=9): * Fedora 15 (mei 2011) [9](#page=9). * Red Hat Enterprise Linux 7 (juni 2014) [9](#page=9). * SUSE Linux Enterprise Server 12 (oktober 2014) [9](#page=9). * Debian 8 (april 2015) [9](#page=9). * Ubuntu 15.04 (april 2015) [9](#page=9). ## 1.2 systemd units Een systemd 'unit' definieert een service of een actie op het systeem. Een unit bestaat uit [10](#page=10) [14](#page=14) [15](#page=15) [16](#page=16) [17](#page=17) [18](#page=18) [20](#page=20) [21](#page=21) [23](#page=23): * Een naam [10](#page=10). * Een type [10](#page=10). * Een configuratiebestand [10](#page=10). Systemd identificeert units met de notatie `naam.type`, bijvoorbeeld `ssh.service` [15](#page=15) [20](#page=20) [21](#page=21). ### 1.2.1 Unit types Er zijn diverse types systemd units, waaronder [16](#page=16) [17](#page=17) [18](#page=18): * `automount` [16](#page=16). * `device` [16](#page=16). * `mount` [16](#page=16). * `path` [16](#page=16). * `service`: wordt gebruikt om daemons op het Linux-systeem te beheren, zoals `ssh.service` [17](#page=17). * `snapshot` [16](#page=16). * `socket` [16](#page=16). * `target`: groepeert meerdere units die tegelijkertijd gestart kunnen worden, zoals `network.target` [18](#page=18). ### 1.2.2 systemd unit configuratiebestanden De configuratiebestanden voor systemd units zijn te vinden in specifieke directory's. Systemd doorzoekt deze in de volgende volgorde [29](#page=29): * `/etc/systemd/system`: Lokale configuratie (aanbevolen voor aangepaste en permanente configuraties) [29](#page=29). * `/run/systemd/system`: Runtime configuratie [29](#page=29). * `/lib/systemd/system`: Configuratie specifiek voor de distributie [29](#page=29). Systemd stopt met zoeken zodra een overeenkomst is gevonden [29](#page=29). #### 1.2.2.1 Sectie [Service Deze sectie bevat configuraties specifiek voor service-type units. Belangrijke parameters zijn [22](#page=22): * `ExecStart`: Het commando dat moet worden uitgevoerd om de service te starten [22](#page=22). * `Restart`: Specificeert wanneer de service automatisch opnieuw moet worden gestart [22](#page=22). #### 1.2.2.2 Sectie [Unit Deze sectie is van toepassing op zowel target als service units en definieert afhankelijkheden. Belangrijke parameters zijn [23](#page=23): * `After` / `Before`: Bepaalt welke units voor of na deze unit moeten draaien [23](#page=23). * `Requires` / `Wants` / `Conflicts` / `Requisite`: Definieert expliciete afhankelijkheden tussen units [23](#page=23). ##### 1.2.2.2.1 Verschillende soorten afhankelijkheden in de [Unit sectie | [Unit van A.service | Beschrijving | Wanneer/welke storing? | | :------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Requires=B.service` | Strikte afhankelijkheden. Bij activering van A.service, wordt B.service ook geactiveerd. Als B.service faalt, wordt A.service gedeactiveerd. | Als B.service faalt, faalt A.service ook. | | `Wants=C.service` | Afhankelijkheden voor activering. Bij activering van A.service, wordt C.service ook geactiveerd. Als C.service faalt, heeft dit geen invloed op A.service. | Als C.service faalt, heeft systemd hier geen problemen mee. | | `Requisite=D.service`| Units die reeds actief moeten zijn. Voor activering van A.service, controleert systemd D.service. Als D.service niet actief is, faalt de activering van A.service. | Als D.service niet actief is, faalt A.service. | | `Conflicts=E.service`| Negatieve afhankelijkheden. Bij activering van A.service, wordt E.service gedeactiveerd. Gelijktijdige activering van twee conflicterende units faalt. | Gelijktijdige activering van A.service en E.service faalt. | **Tip:** De `Wants` dependency type propageert storingen niet naar andere units. De systemd documentatie geeft aan dat dit de voorkeursmanier is om afhankelijkheden te specificeren indien mogelijk [24](#page=24). Je kunt de afhankelijkheden van een unit bekijken met `systemctl list-dependencies .service` of `systemctl list-dependencies .service --reverse` [24](#page=24). #### 1.2.2.3 Sectie [Install Deze sectie bevat configuraties die relevant zijn bij het inschakelen (enabling) van een unit. Belangrijke parameters zijn [26](#page=26): * `WantedBy` / `RequiredBy`: Specificeert tot welk 'target level' het systeem moet behoren wanneer deze unit wordt ingeschakeld [26](#page=26). ### 1.2.3 Afhankelijkheden 'in reverse' Afhankelijkheden kunnen ook 'in reverse' worden ingesteld. In plaats van de `Wants` in de configuratie van Unit B te zetten om Unit A als dependency toe te voegen, kun je dit in Unit A's configuratie doen met `WantedBy`. Dit maakt dynamische activering en deactivering mogelijk via `systemctl enable A.service` en `systemctl disable A.service`. Dit creëert of verwijdert symlinks in de `/etc/systemd/system/B.service.wants/` directory [25](#page=25). Je kunt de afhankelijkheden van een unit bekijken met `systemctl show -p Wants B.service` [25](#page=25). ### 1.2.4 Het 'Default Target' Het `default.target` bestand (vaak een symbolische link naar een specifiek target) is het bestand waarnaar systemd zoekt bij het opstarten van het systeem [27](#page=27). ## 1.3 Het opstartproces met systemd Wanneer het systeem opstart met systemd, gebeurt het volgende [28](#page=28): 1. systemd laadt zijn configuratie [28](#page=28). 2. systemd bepaalt het 'boot goal', wat meestal `default.target` is [28](#page=28). 3. systemd bepaalt alle afhankelijkheden van het `default.target`, de afhankelijkheden van deze afhankelijkheden, enzovoort (via `Wants`, `Requires`, `Conflicts`, etc.) [28](#page=28). 4. systemd activeert de afhankelijkheden en het `default.target` [28](#page=28). 5. Na het opstarten kan systemd reageren op systeemgebeurtenissen en aanvullende componenten activeren [28](#page=28). ## 1.4 Veelgebruikte `systemctl` commando's `systemctl` is het commando om systemd te beheren [7](#page=7). ### 1.4.1 Controleren van service en target units | Commando | Beschrijving | | :-------------------------------------- | :------------------------------------------------------------------------ | | `systemctl status ` | Toont de status van de opgegeven unit. | . | `systemctl start ` | Start de opgegeven unit. | . | `systemctl stop ` | Stopt de opgegeven unit. | . | `systemctl restart ` | Herstart de opgegeven unit. | . | `systemctl daemon-reload` | Herlaadt de configuratie van de systemd manager (alle unit files). | . | `systemctl enable ` | Configureert de unit om automatisch te starten met andere geselecteerde units. | . | `systemctl disable ` | Configureert de unit om **niet** automatisch te starten. | . | `systemctl mask ` | Markert een unit als volledig onstartbaar, automatisch of handmatig. | . | `systemctl unmask ` | Verwijdert de masking. | . | `systemctl list-units` | Toont de huidige status van alle geconfigureerde units. | [11](#page=11) . | `systemctl --failed` | Toont mislukte units. | . | `systemctl isolate ` | Start de opgegeven unit en stopt alle andere units. | . | `systemctl default` | Schakelt over naar de standaard target unit. | . | `systemctl cat ` | Toont de inhoud van het systemd configuratiebestand van de unit. | . #### 1.4.1.1 Starten versus inschakelen (`enable`) * `systemctl start` start de service zelf, maar creëert geen afhankelijkheden zoals gedefinieerd in de `[Install]` sectie . * `systemctl enable` koppelt de unit aan de juiste plaatsen om ervoor te zorgen dat deze automatisch start met andere units. Het start de unit **niet** direct. Bijvoorbeeld, `systemctl enable A.service` met `WantedBy=B.target` in de `[Install]` sectie creëert een symlink `/etc/systemd/system/B.target.wants/A.service` . * Om beide acties te combineren, gebruik je `systemctl enable --now` . #### 1.4.1.2 Stoppen versus uitschakelen (`disable`) versus maskeren (`mask`) * `systemctl stop` stopt een service als deze actief is [33](#page=33). * `systemctl disable` voorkomt dat een service automatisch start. Het stopt de momenteel actieve unit **niet**. Als een andere service echter een afhankelijkheid heeft van de uitgeschakelde service, zal deze proberen deze te starten [33](#page=33). * `systemctl mask` voorkomt dat een service ooit nog draait door een symbolische link naar `/dev/null` te creëren [33](#page=33). ### 1.4.2 Voorbeelden van `systemctl` commando's * Controleren van de status van de SSH-service: ```bash sudo systemctl status ssh.service ``` Dit toont details zoals of de service actief is, het proces-ID, geheugengebruik, etc. [7](#page=7). * De `shutdown` en `reboot` commando's zijn vaak symbolische links naar `/bin/systemctl` [3](#page=3). systemd is meer dan alleen een vervanging voor `init.d` [34](#page=34). --- # Systemd unit types en configuratie Dit deel behandelt de verschillende soorten 'units' die systemd gebruikt om taken en services te beheren, alsook de structuur van hun configuratiebestanden [10](#page=10) [13](#page=13). ## 2.1 Wat is een systemd unit? Een systemd 'unit' definieert een service of een actie op het systeem. Elke unit bestaat uit de volgende componenten [10](#page=10) [14](#page=14) [15](#page=15) [20](#page=20) [21](#page=21) : * **Naam:** De unieke identificatie van de unit [10](#page=10) [14](#page=14) [15](#page=15) [20](#page=20) [21](#page=21) . * **Type:** Geeft aan wat voor soort unit het is (bijvoorbeeld `service`, `target`, `device`) [10](#page=10) [14](#page=14) [15](#page=15) [20](#page=20) [21](#page=21) . * **Configuratiebestand:** Het pad naar het bestand dat de instellingen van de unit bevat [10](#page=10) [14](#page=14) [15](#page=15) [20](#page=20) [21](#page=21) . Systemd identificeert units met de notatie `naam.type`, zoals `ssh.service` [15](#page=15) [20](#page=20) [21](#page=21). > **Tip:** Een unit configuratiebestand zoals `/lib/systemd/system/ssh.service` is strikt gescheiden van de daadwerkelijke service configuratiebestanden zoals `/etc/ssh/sshd_config` [21](#page=21). ## 2.2 Systemd unit types Systemd ondersteunt diverse unit types, waaronder [16](#page=16) [17](#page=17) [18](#page=18) [39](#page=39) : * `automount`: Beheert automount points [16](#page=16) [39](#page=39) . * `device`: Representeert een kernel device zoals gerapporteerd door udev (bijv. `/dev/sda`). Systemd genereert deze units automatisch, bijvoorbeeld `dev-sda.device`. Andere units kunnen afhankelijk zijn van devices, bijvoorbeeld via `After=dev-sda.device` [16](#page=16) [39](#page=39) . * `mount`: Vertegenwoordigt een gemounte filesystem (bijv. `boot.mount` voor `/boot` of `-.mount` voor `/`). Systemd leest hiervoor `/etc/fstab` [16](#page=16) [42](#page=42) . * `path`: Monitort bestandspadactiviteiten [16](#page=16) [39](#page=39) . * `service`: Wordt gebruikt om daemons en services op het Linux-systeem te beheren, zoals `ssh.service` [16](#page=16) [17](#page=17) [39](#page=39) . * `snapshot`: Een snapshot van de system state [16](#page=16) [39](#page=39) . * `socket`: Beheert netwerk sockets [16](#page=16) [39](#page=39) . * `target`: Groepeert meerdere units zodat ze tegelijkertijd kunnen worden gestart, zoals `network.target` [16](#page=16) [18](#page=18) [39](#page=39) . ## 2.3 Systemd unit configuratiebestanden Configuratiebestanden voor systemd units zijn tekstbestanden die gestructureerd zijn in secties [19](#page=19) [22](#page=22) [23](#page=23) [26](#page=26). ### 2.3.1 Algemene structuur en secties Elk configuratiebestand bevat minimaal één sectie, meestal `[Unit]`, `[Service]` en/of `[Install]` [22](#page=22) [23](#page=23) [26](#page=26). * **`[Unit]` sectie:** Deze sectie bevat metagegevens over de unit en definieert afhankelijkheden tussen units [23](#page=23) [26](#page=26). * `After=`: Definieert dat deze unit pas mag starten nadat de gespecificeerde units zijn gestart [23](#page=23). * `Before=`: Definieert dat deze unit moet stoppen voordat de gespecificeerde units mogen starten [23](#page=23). * `Requires=`: Strikte afhankelijkheden. Als de vereiste unit faalt, faalt ook deze unit [24](#page=24). * `Wants=`: Afhankelijkheden voor activering. Als de gewenste unit faalt, heeft dit geen invloed op deze unit. Dit is de aanbevolen manier om afhankelijkheden te specificeren indien mogelijk [24](#page=24). * `Conflicts=`: Negatieve afhankelijkheden. Het activeren van deze unit zorgt voor het deactiveren van de conflictuerende unit. Gelijktijdige activering van conflicterende units mislukt [24](#page=24). * `Requisite=`: Units die al actief moeten zijn voordat deze unit geactiveerd kan worden [24](#page=24). * **`[Service]` sectie:** Deze sectie is specifiek voor `service`-type units en definieert hoe de service uitgevoerd moet worden [22](#page=22). * `ExecStart=`: Het commando of programma dat gestart moet worden [22](#page=22). * `Restart=`: Geeft aan wanneer de service automatisch opnieuw gestart moet worden [22](#page=22). * **`[Install]` sectie:** Deze sectie definieert hoe de unit geïnstalleerd en geactiveerd kan worden tijdens het opstarten van het systeem [26](#page=26). * `WantedBy=`: Specificeert de target level waarin het systeem moet zijn om deze unit te activeren. Dit wordt vaak gebruikt om een unit te koppelen aan een `target` unit, bijvoorbeeld `multi-user.target` [26](#page=26). * `RequiredBy=`: Vergelijkbaar met `WantedBy`, maar met een striktere afhankelijkheid [26](#page=26). ### 2.3.2 Afhankelijkheden "in reverse" Afhankelijkheden kunnen ook "in reverse" worden geconfigureerd. In plaats van `Wants=` toe te voegen aan de configuratie van unit B om naar unit A te verwijzen, kan men in de configuratie van unit A `WantedBy=` toevoegen. Dit creëert symbolische links in de `/etc/systemd/system/` directory [25](#page=25). Deze dynamische activering en deactivering van afhankelijkheden kan worden beheerd met de commando's `systemctl enable A.service` en `systemctl disable A.service` [25](#page=25). De afhankelijkheden van een unit kunnen worden opgevraagd met `systemctl show -p Wants B.service` [25](#page=25). ### 2.3.3 Locatie van configuratiebestanden Unit configuratiebestanden zijn op verschillende locaties te vinden, waarbij systemd de volgende volgorde hanteert [29](#page=29): 1. `/etc/systemd/system`: Lokale, aangepaste en meer permanente configuraties die niet verloren gaan bij pakketupdates [29](#page=29). 2. `/run/systemd/system`: Configuratiebestanden die tijdens de runtime worden aangemaakt [29](#page=29). 3. `/lib/systemd/system`: Configuratiebestanden die door de distributie worden geleverd [29](#page=29). Systemd stopt met zoeken zodra het een overeenkomst vindt, wat betekent dat configuraties in `/etc/systemd/system` voorrang hebben [29](#page=29). ## 2.4 Wat gebeurt er tijdens het opstarten? Bij het opstarten van het systeem doorloopt systemd de volgende stappen [32](#page=32): 1. Systemd laadt zijn configuratie [32](#page=32). 2. Systemd bepaalt het bootdoel, meestal genaamd `default.target` [32](#page=32). 3. Systemd bepaalt alle afhankelijkheden van het `default.target`, en de afhankelijkheden van die afhankelijkheden, recursief [32](#page=32). 4. Systemd activeert de afhankelijkheden en het bootdoel [32](#page=32). 5. Na het opstarten kan systemd reageren op systeemgebeurtenissen en additionele componenten activeren [32](#page=32). Het bestand `/lib/systemd/system/default.target` (vaak een symbolische link) bepaalt het primaire opstartdoel van het systeem [27](#page=27). > **Tip:** Begrijp de hiërarchie van `target`-units en hun afhankelijkheden (`Requires`, `Wants`, etc.) om te doorgronden hoe het systeem opstart en welke services wanneer worden geladen [24](#page=24) [28](#page=28). ## 2.5 Commando's voor unitbeheer Enkele nuttige `systemctl` commando's gerelateerd aan units: * `systemctl list-units --type=device --all`: Toont alle device units, actief en inactief [40](#page=40). * `systemctl list-dependencies A.service`: Toont de afhankelijkheden van de unit `A.service` [24](#page=24). * `systemctl list-dependencies A.service --reverse`: Toont de units die afhankelijk zijn van `A.service` [24](#page=24). * `systemctl show -p Wants B.service`: Toont de 'Wants' afhankelijkheden van `B.service` [25](#page=25). * `systemctl enable A.service`: Activeert `A.service` bij het opstarten door symlinks te creëren [25](#page=25). * `systemctl disable A.service`: Deactiveert `A.service` bij het opstarten door symlinks te verwijderen [25](#page=25). --- # Systemd commando's en analyse Dit gedeelte behandelt de essentiële commando's voor het beheer van systemd, waaronder `systemctl` en `journalctl`, en de analysemogelijkheden van `systemd-analyze`. ### 3.1 Systemd beheer met `systemctl` `systemctl` is het primaire commando voor het beheren van systemd-services en andere eenheden (units) op het systeem [30](#page=30) [31](#page=31) [7](#page=7). #### 3.1.1 Status en overzicht van units * `systemctl status `: Geeft de status van de opgegeven unit weer. Dit commando toont informatie zoals of de unit actief is, geladen is, en details over het proces [12](#page=12) [31](#page=31) [7](#page=7). * `systemctl list-units`: Toont de huidige status van alle geconfigureerde units [11](#page=11) [31](#page=31). * `systemctl list-unit-files`: Geeft een overzicht van alle beschikbare unit-bestanden en hun status (enabled/disabled) [11](#page=11). * `systemctl --failed`: Toont een lijst van units die mislukt zijn [31](#page=31). #### 3.1.2 Starten, stoppen en herstarten van units * `systemctl start `: Start de opgegeven unit. Belangrijk om te weten is dat `start` de service zelf start, maar niet noodzakelijk de afhankelijkheden zoals gedefinieerd in de `[Install]` sectie van de unit-configuratie [31](#page=31) [32](#page=32). * `systemctl stop `: Stopt de opgegeven unit indien deze actief is [31](#page=31) [33](#page=33). * `systemctl restart `: Zorgt ervoor dat de opgegeven unit wordt afgesloten en opnieuw wordt gestart [31](#page=31). * `systemctl isolate `: Start de opgegeven unit en stopt alle andere actieve units [31](#page=31). #### 3.1.3 Configuratie en inschakelen van units * `systemctl enable `: Configureert de unit om automatisch te starten met andere geselecteerde units. `enable` koppelt de unit aan verschillende plaatsen zodat deze automatisch start met andere units, maar start de unit zelf niet. Een voorbeeld hiervan is het aanmaken van een symbolische link in `/etc/systemd/system/B.target.wants/A.service` als `A.service` `WantedBy=B.target` heeft in zijn `[Install]` sectie, wat ervoor zorgt dat `A.service` start wanneer `B.target` start [31](#page=31) [32](#page=32). * `systemctl disable `: Configureert de unit om niet automatisch te starten met andere units. `disable` voorkomt dat een service zelfstandig start, maar stopt de momenteel actieve unit niet. Als een andere service `A.service` als afhankelijkheid heeft, zal die andere service `A.service` proberen te starten wanneer deze zelf start [31](#page=31) [33](#page=33). * `systemctl daemon-reload`: Herlaadt de systeemd-managerconfiguratie, inclusief alle unit-bestanden [31](#page=31). * `systemctl enable --now`: Combineert het inschakelen en starten van een unit in één commando [32](#page=32). #### 3.1.4 Maskeren en unmasken van units * `systemctl mask `: Markeer een unit als volledig niet-startbaar, automatisch of handmatig. Maskeren zorgt ervoor dat de unit helemaal niet meer kan draaien, door een symbolische link naar `/dev/null` te creëren voor die service [31](#page=31) [33](#page=33). * `systemctl unmask `: Ongedaan maken van het maskeren [31](#page=31). #### 3.1.5 Andere `systemctl` commando's * `systemctl default`: Wijzigt naar de standaard target unit [31](#page=31). * `systemctl cat `: Print het systemd-configuratiebestand van de opgegeven unit [31](#page=31). > **Tip:** Het starten en inschakelen van units zijn orthogonale bewerkingen. Een unit kan ingeschakeld zijn zonder gestart te zijn, en gestart zijn zonder ingeschakeld te zijn [32](#page=32). ### 3.2 Loganalyse met `journalctl` `journalctl` is het commando om de logs van systemd te bekijken [35](#page=35). * `journalctl -xe`: Gaat naar het einde van de log (`-e`) en geeft uitleg (`-x`) voor foutmeldingen [35](#page=35). * `journalctl -xef`: Gaat naar het einde van de log, geeft uitleg, en blijft nieuwe logvermeldingen volgen (`-f`) [35](#page=35). * `journalctl -xef -u `: Volgt nieuwe logvermeldingen en toont alleen logs voor de opgegeven unit `` [35](#page=35). * `journalctl -b -1`: Toont alleen berichten van de laatste systeemopstart [35](#page=35). * `journalctl -k`: Toont alleen kernelberichten [35](#page=35). * `journalctl --no-pager`: Gebruikt voor het parsen van output op stdout [35](#page=35). * `journalctl -u nginx -o json-pretty`: Output de logs in een mooie JSON-structuur [35](#page=35). * `journalctl --since yesterday`: Filtert op logs vanaf gisteren [35](#page=35). * `--since "YYYY-MM-DD" --until "YYYY-MM-DD"`: Filtert op een start- en einddatum, waarbij ook tijd kan worden gespecificeerd [35](#page=35). > **Tip:** Voor het zien van bepaalde logvermeldingen zijn verhoogde permissies (zoals `sudo`) vereist [35](#page=35). ### 3.3 Systeemprofielering met `systemd-analyze` `systemd-analyze` biedt tools om de opstarttijd en andere aspecten van het systeem te analyseren [36](#page=36) [37](#page=37). * `systemd-analyze time`: Analyseert de totale opstarttijd van het systeem [36](#page=36). * `systemd-analyze blame`: Toont een lijst van alle units en de tijd die ze nodig hadden om te initialiseren, gesorteerd van langste naar kortste tijd [36](#page=36). * `systemd-analyze critical-chain`: Toont de kritieke keten van units die de totale opstarttijd bepalen [36](#page=36). * `systemd-analyze plot > file.svg`: Genereert een SVG-afbeelding die de opstartvolgorde en afhankelijkheden visualiseert [36](#page=36). * `systemd-analyze security`: Analyseert de beveiligingsfuncties die systemd zelf implementeert voor services [37](#page=37). > **Let op bij `systemd-analyze security`:** Deze analyse kijkt enkel naar de beveiligingsmechanismen die *systemd zelf* implementeert per service. Extra beveiligingsmaatregelen die de servicecode zelf toepast, worden niet meegerekend. Hoge blootstellingsniveaus duiden er echter wel op dat de service waarschijnlijk baat kan hebben bij aanvullende beveiligingsinstellingen [37](#page=37). --- ## 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 die als opvolger van de traditionele init-daemon fungeert en een breed scala aan systeembeheertaken afhandelt, waaronder het starten, stoppen en monitoren van services en het beheren van systeemconfiguraties. | | unit | Een systemd 'unit' vertegenwoordigt een configuratiebestand dat een service, apparaat, mountpoint, socket, of een groep van andere units definieert, en gedefinieerd wordt door een naam, type en configuratiebestand. | | service unit | Een 'service unit' binnen systemd wordt gebruikt om daemonprocessen op een Linux-systeem te beheren, zoals de OpenSSH-server (ssh.service), en bevat configuratieopties voor het starten en herstarten van de betreffende service. | | target unit | Een 'target unit' in systemd is een manier om meerdere units te groeperen die tegelijkertijd gestart kunnen worden, vergelijkbaar met "runlevels" in oudere init-systemen, zoals de 'network.target' die netwerkgerelateerde services activeert. | | systeem kernel | De systeem kernel is het centrale deel van een besturingssysteem dat alle andere delen van het systeem beheert en direct communiceert met de hardware, waarbij het de basisfunctionaliteit voor geheugenbeheer, procesbeheer en apparaatstuurprogramma's biedt. | | cgroup | Cgroups (control groups) zijn een Linux-kernelmechanisme dat processen organiseert in hiërarchische groepen, waardoor bronnen zoals CPU-tijd, geheugen en I/O-bandbreedte effectief kunnen worden beheerd en beperkt voor individuele processen of groepen. | | dependencies | In de context van systemd verwijzen dependencies naar expliciete relaties tussen units, waarbij de activering van de ene unit afhankelijk is van de status of beschikbaarheid van een andere unit, gespecificeerd via secties als Requires, Wants, Requisite en Conflicts. | | init daemon | De init daemon, vaak geïdentificeerd als PID 1, is het eerste proces dat start wanneer een Linux-systeem opstart en is verantwoordelijk voor het initialiseren van de rest van het systeem, inclusief het starten van andere services en het beheren van de systeemstatus. | | runlevel | Een runlevel is een modus van een Unix-achtig besturingssysteem die bepaalt welke processen actief zijn, vaak geassocieerd met de traditionele SysVinit-systeembeheerder, waarbij verschillende runlevels corresponderen met verschillende systeemtoestanden zoals normale bewerking of onderhoudsmodus. | | journalctl | journalctl is een command-line utility in Linux die wordt gebruikt om logboeken te bekijken en te beheren die door de systemd journal worden opgeslagen, en biedt functionaliteit voor het filteren, weergeven en analyseren van systeemgebeurtenissen. | | systemd-analyze | systemd-analyze is een commando in Linux dat wordt gebruikt om de opstarttijd van het systeem te analyseren, afzonderlijke units te beoordelen op hun bijdrage aan de opstarttijd, en gedetailleerde informatie te verstrekken over de opstartvolgorde en prestaties. |