systemd-services beheren en unitbestanden schrijven

systemctl status geeft een uitgebreid overzicht van een unit. Als je de uitvoer begrijpt, kun je problemen snel diagnosticeren.

• Loaded: pad naar het unitbestand en of de unit tijdens het opstarten is ingeschakeld
• Active: huidige status — active (running), inactive (dead), failed
• Main PID: de proces-ID van het hoofdproces van de service
• CGroup: alle onderliggende processen die bij de service horen
• Logregels: de meest recente journaalvermeldingen voor deze unit

Je kunt ook alleen de actieve status opvragen met systemctl is-active en de ingeschakelde status met systemctl is-enabled. Die opdrachten zijn ideaal voor gebruik in scripts.

Als je veel services beheert, heb je efficiënte manieren nodig om units weer te geven en te filteren. systemctl list-units toont alle momenteel geladen units, terwijl list-unit-files alle geïnstalleerde unitbestanden en hun ingeschakelde status toont.

Handige filteropties:

• --type=service — alleen service-units weergeven
• --state=failed — alleen mislukte units weergeven
• --state=active — alleen actieve units weergeven
• --all — inactieve units in de lijst opnemen

Door deze filters te combineren met grep kun je krachtige inspectiepijplijnen in onderhoudsscripts bouwen.

Een service-unitbestand is een gewoon tekstbestand in INI-stijl dat uit secties bestaat. Elke sectie bepaalt een ander aspect van de levenscyclus van de unit.

• [Unit] — metagegevens: beschrijving en afhankelijkheden voor de volgorde (After=, Requires=, Wants=)
• [Service] — hoe het proces wordt gestart en gestopt: ExecStart, ExecStop, Restart, User, WorkingDirectory
• [Install] — wanneer deze unit moet worden ingeschakeld: WantedBy=multi-user.target betekent dat deze tijdens normaal opstarten voor meerdere gebruikers wordt geactiveerd

Nadat je een unitbestand onder /etc/systemd/system/ hebt geplaatst of bewerkt, moet je systemctl daemon-reload uitvoeren zodat systemd de wijzigingen overneemt.

We maken een eenvoudig service-unitbestand voor een aangepast Python HTTP-serverscript. Het unitbestand vertelt systemd precies hoe dit proces moet worden beheerd, net als elke andere systeemservice.

Belangrijke [Service]-richtlijnen die hier worden gebruikt:

• Type=simple — systemd behandelt het proces van ExecStart als het hoofdproces
• User=www-data — uitvoeren onder een account dat geen rootaccount is, voor meer veiligheid
• WorkingDirectory — de werkmap van het proces instellen
• Restart=on-failure — automatisch opnieuw starten als het proces eindigt met een code die niet nul is
• RestartSec=5 — 5 seconden wachten tussen pogingen om opnieuw te starten

De Type=-richtlijn in [Service] vertelt systemd hoe het moet bepalen wanneer een service klaar is met starten. Het kiezen van het verkeerde type is een veelvoorkomende oorzaak van fouten in de volgorde.

• Type=simple — standaard; systemd beschouwt de service als gestart zodra ExecStart wordt uitgevoerd. Er is geen signaal voor gereedheid nodig.
• Type=forking — het proces van ExecStart maakt een fork en stopt; de echte daemon draait als onderliggend proces. Gebruik PIDFile= zodat systemd het proces kan volgen.
• Type=notify — het proces verzendt sd_notify(READY=1) zodra het echt gereed is. Dit is het betrouwbaarst voor complexe daemons.
• Type=oneshot — wordt één keer uitgevoerd en stopt daarna; volgende units wachten tot de uitvoering is voltooid. Ideaal voor instelscripts.
• Type=idle — werkt zoals simple, maar de uitvoering wordt uitgesteld totdat alle actieve taken zijn voltooid.

Service-unitbestanden ondersteunen verschillende richtlijnen voor het doorgeven van omgevingsvariabelen en het toepassen van beveiligingsbeperkingen — beide zijn belangrijk in productiesystemen.

Richtlijnen voor omgevingsvariabelen:

• Environment="KEY=value" — één variabele inline instellen
• EnvironmentFile=/etc/myapp/env — variabelen uit een bestand laden (één KEY=value per regel)

Veelgebruikte richtlijnen voor beveiligingsversterking:

• NoNewPrivileges=true — voorkomen dat het proces extra rechten verkrijgt via setuid
• ProtectSystem=strict — /usr, /boot en /etc als alleen-lezen koppelen
• PrivateTmp=true — de service een eigen geïsoleerde /tmp geven
• CapabilityBoundingSet= — alle Linux-mogelijkheden laten vallen

Een systemd-timer is een unit die volgens een schema een andere unit activeert (meestal een .service). Deze vervangt traditionele cron-taken door een meer geïntegreerd, logbaar en beheersbaar mechanisme.

Elke timerunit (foo.timer) wordt gekoppeld aan een service-unit met dezelfde basisnaam (foo.service) die het daadwerkelijke werk uitvoert. Je schakelt de timer in en start deze, niet de service rechtstreeks.

Timertypen:

• Realtime-timers (kalendertimers) — worden geactiveerd op kloktijden met OnCalendar=-expressies zoals daily, weekly of Mon *-*-* 02:00:00
• Monotone timers — worden geactiveerd ten opzichte van een systeemgebeurtenis met OnBootSec=, OnActiveSec= of OnUnitActiveSec=

We bouwen een volledig timer- en servicepaar dat elke dag om 02:00 een back-upscript uitvoert. Let erop dat de sectie [Timer] in een eigen .timer-bestand staat, terwijl het werk in het gekoppelde .service-bestand staat.

Belangrijke [Timer]-richtlijnen:

• OnCalendar= — kalenderexpressie voor het schema
• Persistent=true — als het systeem uit stond toen de timer had moeten worden geactiveerd, de taak onmiddellijk uitvoeren bij de volgende start
• RandomizedDelaySec= — maximaal N seconden willekeurige variatie toevoegen om een piekbelasting te voorkomen wanneer veel hosts hetzelfde schema gebruiken
• Unit= — expliciete doelunit (optioneel als de namen overeenkomen)

systemd stuurt alle uitvoer van services naar het journaal, dat je opvraagt met journalctl. Hierdoor worden logboeken van alle units gecentraliseerd in één doorzoekbare opslag.

Essentiële journalctl-opties voor het oplossen van serviceproblemen:

• -u <unit> — filteren op unitnaam
• -f — het logboek in realtime volgen (zoals tail -f)
• -n 50 — alleen de laatste 50 regels weergeven
• --since "1 hour ago" — beperken op tijd
• -p err — alleen fouten met prioriteit error en hoger weergeven
• -b — alleen logboeken van de huidige opstartsessie weergeven

Als een unit niet kan starten, voer je eerst journalctl -u <unit> -n 30 --no-pager uit, gevolgd door systemctl status <unit>, om de recente foutcontext vast te leggen.

In deze les heb je de kernconcepten van het beheer van systemd-services en het schrijven van unitbestanden op professioneel niveau verkend. Hier volgt een samenvatting van de behandelde onderwerpen:

• systemctl-basis — start, stop, restart, reload, enable, disable, status, is-active en is-enabled voor scriptvriendelijke controles
• Weergeven en filteren — list-units en list-unit-files met de opties --type en --state om mislukte of ingeschakelde services te isoleren
• Opbouw van unitbestanden — de drie secties [Unit], [Service] en [Install] en hun belangrijkste richtlijnen
• Servicetypen — simple, forking, notify, oneshot en wanneer je elk type gebruikt
• Omgeving en beveiliging — EnvironmentFile, NoNewPrivileges, ProtectSystem en PrivateTmp voor beter beveiligde daemons
• Timerunits — .timer- en .service-bestanden koppelen, OnCalendar-expressies en inhaalgedrag met Persistent
• Journalctl — filteren op unit, tijd, opstartsessie en prioriteit om fouten efficiënt te diagnosticeren

Met deze vaardigheden kun je elke systeemservice beheren, terugkerende taken betrouwbaar plannen en productieklare unitbestanden voor je eigen daemons schrijven.