Hoe gebruik ik Systemctl om systemd-eenheden en -services te beheren?

Systemd is de standaard systeem- en servicemanager die in de meeste moderne Linux-distributies wordt gebruikt. Het is verantwoordelijk voor het opstarten van het systeem tijdens het opstarten en het beheren van actieve services. Het neemt proces-ID 1 (PID 1) over, wat betekent dat het het allereerste gebruikersruimteproces is dat door de Linux-kernel wordt gestart en blijft draaien totdat het systeem wordt afgesloten.

In tegenstelling tot oudere init-systemen zoals SysV, gebruikt systemd units om systeembronnen te definiëren en te beheren. Elke unit wordt beschreven door een configuratiebestand, een zogenaamd unit-bestand, dat systemd vertelt hoe die bron moet worden beheerd. Units kunnen services, apparaten, koppelpunten of zelfs groepen units vertegenwoordigen, zogenaamde targets, die tijdens het opstartproces als controleposten fungeren.

Het belangrijkste hulpmiddel voor interactie met systemd is systemctl, waarmee u services en andere units kunt starten, stoppen, herstarten, in- en uitschakelen en de status ervan kunt controleren.

Om systeemlogboeken met betrekking tot systemd en zijn services te bekijken, kunt u journalctl gebruiken, een commando dat berichten uit het systemd-logboek weergeeft.

In deze handleiding zullen we bekijken hoe u het commando systemctl kunt gebruiken, een hulpmiddel voor het beheren van het initialisatiesysteem op Linux. We bespreken ook hoe u services kunt beheren, hun status kunt bekijken, systeemstatussen kunt aanpassen en kunt communiceren met configuratiebestanden.

Het is belangrijk om te vermelden dat systemd weliswaar het standaard init-systeem is in veel populaire Linux-distributies, maar dat niet elke distributie het gebruikt. Als u een foutmelding ziet zoals bash: systemctl: command not found, maakt uw systeem waarschijnlijk gebruik van een ander init-systeem en is systemctl niet beschikbaar.

Services beheren met Systemctl

Een van de belangrijkste taken van een init-systeem is het opstarten van essentiële componenten nadat de Linux-kernel is geladen. Deze componenten, vaak userland-processen genoemd, omvatten verschillende services en daemons die ervoor zorgen dat het systeem soepel blijft draaien. Een init-systeem speelt ook een voortdurende rol bij het beheren van deze services terwijl het systeem actief is.

In het geval van systemd worden de belangrijkste elementen die het beheert units genoemd. Units worden gedefinieerd in configuratiebestanden die unitbestanden worden genoemd, en elk bestand specificeert hoe een bepaalde bron moet worden behandeld. Het type bron wordt aangegeven door de extensie (achtervoegsel) van het bestand.

Voor het specifiek beheren van services gebruikt systemd service-units, waarvan de bestandsnamen eindigen op .service. Bij het gebruik van systemctl-commando's kunt u echter meestal de extensie .service weglaten. Systemd gaat er dan automatisch vanuit dat u naar een service verwijst.

Services starten en stoppen met Systemctl

Om een service handmatig te starten en de acties te activeren die in het unit-bestand zijn gedefinieerd, gebruikt u de volgende opdracht:

$ sudo systemctl start application.service

Aangezien systemd kan afleiden dat u met een service werkt, kunt u ook het volgende uitvoeren:

$ sudo systemctl start application

Beide formaten werken, maar voor de duidelijkheid zal deze handleiding consequent het achtervoegsel .service gebruiken bij het werken met service-units.

Om een service te stoppen die momenteel actief is, gebruikt u de volgende opdracht:

$ sudo systemctl stop application.service

Systemctl Service opnieuw starten

Om een service volledig opnieuw te starten (d.w.z. te stoppen en vervolgens opnieuw te starten), gebruikt u:

$ sudo systemctl restart application.service

Sommige services ondersteunen het opnieuw laden van hun configuratiebestanden zonder dat ze volledig opnieuw hoeven te worden gestart. Om het opnieuw laden van de configuratie te activeren, voert u het volgende uit:

$ sudo systemctl reload application.service

Als u niet zeker weet of de service herladen ondersteunt, kunt u een veiliger, gecombineerd commando gebruiken:

$ sudo systemctl reload-or-restart application.service

Hiermee wordt geprobeerd de configuratie opnieuw te laden, indien ondersteund. Als dat niet het geval is, wordt de service opnieuw gestart.

Services in- en uitschakelen met systemctl

De commando's die we tot nu toe hebben behandeld, helpen bij het beheren van services binnen de huidige sessie, maar als u wilt dat een service automatisch wordt gestart wanneer het systeem opstart, moet u deze inschakelen.

Systemctl Service inschakelen (systemd enable service)

Om een service te configureren zodat deze tijdens het opstarten wordt gestart, voert u het volgende uit:

$ sudo systemctl enable application.service

Dit commando maakt een symbolische link van het bestand van de service – meestal te vinden in /lib/systemd/system/ of /etc/systemd/system/ – naar een map die systemd bij het opstarten scant op automatisch startende services (meestal iets als /etc/systemd/system/some_target.target.wants).

Systemctl service uitschakelen

Om te voorkomen dat een service bij het opstarten wordt gestart, gebruikt u:

$ sudo systemctl disable application.service

Hiermee wordt de symbolische link verwijderd, zodat systemd de service niet langer automatisch start.

Houd er rekening mee dat het inschakelen van een service alleen betekent dat deze bij het opstarten wordt gestart – de service wordt niet onmiddellijk gestart in de huidige sessie. Als u de service wilt inschakelen en direct wilt starten, moet u zowel enable als start uitvoeren.

De status van de service controleren

Om te controleren of een service actief is en om wat basisinformatie over de service te bekijken, kunt u het volgende gebruiken:

$ systemctl status application.service

Hiermee worden details weergegeven, zoals of de service actief is, hoe lang deze al actief is en de meest recente logboekvermeldingen met betrekking tot de service.

Als u bijvoorbeeld de status van docker controleert, ziet u mogelijk iets als:

Dit overzicht geeft u een snelle gezondheidscontrole van de service en wijst op eventuele problemen.

De status van specifieke services controleren

Als u alleen wilt controleren of een service actief is, kunt u het volgende gebruiken:

$ systemctl is-active application.service

Dit commando geeft ‘active’ of ‘inactive’ weer. Het geeft ook een exitcode weer: 0 betekent dat de service actief is, wat handig kan zijn als u controles in een script automatiseert.

Om te controleren of een service is ingesteld om bij het opstarten te starten, voert u het volgende uit:

$ systemctl is-enabled application.service

Dit geeft ‘enabled’ of ‘disabled’ weer en net als eerder kan de exitcode van de opdracht het resultaat aangeven.

Om ten slotte te controleren of een service is mislukt, wat betekent dat er een fout is opgetreden bij het starten of uitvoeren, gebruikt u:

$ systemctl is-failed application.service

Dit geeft ‘failed’ weer als er iets mis is gegaan, of ‘active’ als de service correct werkt. Als de service opzettelijk is gestopt, ziet u mogelijk inactive of unknown. Een exitcode van 0 duidt op een storing, terwijl 1 een andere status aangeeft.

De algehele systeemstatus bekijken (Systemctl List Services)

Tot nu toe hebben we gekeken naar commando's die helpen bij het beheren van individuele services, maar als u een breder beeld van het systeem als geheel wilt krijgen, biedt systemctl daar ook commando's voor.

Actieve eenheden bekijken

Om te zien welke eenheden momenteel actief zijn, kunt u de opdracht list-units gebruiken:

$ systemctl list-units

Hiermee worden alle eenheden weergegeven die op dit moment actief door systemd worden beheerd. De uitvoer ziet er ongeveer zo uit:

Dit is wat elke kolom betekent:

• UNIT: De daadwerkelijke naam van de eenheid.
• LOAD: Of systemd het eenheidsbestand met succes heeft gelezen en in het geheugen heeft geladen.
• ACTIVE: Een algemene indicator of de unit correct werkt.
• SUB: Een meer gedetailleerde status op een lager niveau die afhankelijk is van het specifieke type unit.
• DESCRIPTION: Een korte samenvatting waarin het doel van de unit wordt uitgelegd.

Standaard worden alleen units weergegeven die momenteel actief zijn. Als u systemctl zonder extra argumenten uitvoert, krijgt u dezelfde uitvoer.

$ systemctl

Alle eenheden weergeven (actief en inactief)

Als u alle eenheden wilt zien die systemd heeft geprobeerd te laden of momenteel in het geheugen heeft, zelfs als ze op dit moment niet actief zijn, kunt u de vlag --all toevoegen:

$ systemctl list-units --all

Dit omvat eenheden die zijn uitgevoerd en vervolgens zijn gestopt, of zelfs eenheden die systemd heeft geprobeerd te laden maar niet kon vinden.

Om dit te beperken, kunt u filteren op specifieke statussen. Als u bijvoorbeeld alleen inactieve eenheden wilt zien, kunt u het volgende uitvoeren:

$ systemctl list-units --all --state=inactive

U kunt ook filteren op type. Om bijvoorbeeld alleen services weer te geven:

$ systemctl list-units --type=service

Alle eenheidsbestanden weergeven (ongeacht of ze geladen zijn)

De bovenstaande commando's tonen alleen units waarmee systemd interactie heeft gehad, door ze te laden of te proberen uit te voeren. Om alle beschikbare unitbestanden op het systeem te zien (ongeacht of systemd ze heeft aangeraakt), gebruikt u:

$ systemctl list-unit-files

Dit geeft een lijst van alle unitdefinitiebestanden die in de systemd-mappen zijn gevonden. Dit omvat ook bestanden die systemd nooit heeft geprobeerd te laden. De uitvoer ziet er als volgt uit:

Er zijn twee kolommen:

• UNIT FILE: De naam van het unit-bestand.
• STATE: Of het unit-bestand is ingeschakeld, uitgeschakeld, statisch of gemaskeerd.

Dit is wat deze statussen betekenen:

• enabled: De unit is ingesteld om automatisch te starten wanneer dat nodig is.
• disabled: De unit start niet automatisch, maar kan handmatig worden gestart.
• static: Deze unit heeft geen “install”-sectie, wat betekent dat hij niet is ontworpen om direct te worden ingeschakeld, maar bedoeld is om te worden geactiveerd door afhankelijkheden.
• masked: De unit is expliciet uitgeschakeld op een manier die voorkomt dat hij onder welke omstandigheden dan ook kan worden gestart (meer hierover in de volgende sectie).

Dit geeft u een volledig overzicht van alle units op het systeem, ongeacht of systemd daadwerkelijk heeft geprobeerd ze te gebruiken.

Hoe werkt u met systemd-units?

Tot nu toe hebben we ons vooral gericht op het starten en stoppen van services en het bekijken van basisgegevens over systemd-units en hun bestanden. Systemd biedt echter verschillende opdrachten om dieper in de unit-informatie te duiken en deze nauwkeuriger te beheren.

Het bestand van een unit bekijken

Om het daadwerkelijke unitbestand te zien dat systemd in het geheugen heeft geladen, kunt u de opdracht cat gebruiken (deze is geïntroduceerd in systemd versie 209). Om bijvoorbeeld het unitbestand voor de apache2-service te bekijken, voert u het volgende uit:

$ systemctl cat apache2.service

Dit commando geeft de inhoud weer van het unit-bestand dat momenteel bekend is bij systemd. Dit is vooral handig als het bestand recentelijk is gewijzigd of als er aangepaste overschrijvingen zijn toegepast. De weergegeven inhoud geeft de live status van het bestand weer zoals systemd die ziet.

Unit-afhankelijkheden controleren

Als u wilt controleren op welke andere units een bepaalde service vertrouwt, is het commando list-dependencies handig. Om bijvoorbeeld te zien waar de sshd-service van afhankelijk is, voert u het volgende uit:

$ systemctl list-dependencies sshd.service

Dit geeft een boomstructuur weer van units die sshd.service direct nodig heeft of wenst (optionele afhankelijkheden). Systemd-doelen, speciale groeperingen van units die systeemstatussen vertegenwoordigen, tonen ook hun eigen interne afhankelijkheden.

Om alle recursieve afhankelijkheden weer te geven, kunt u de optie --all toevoegen:

$ systemctl list-dependencies --all sshd.service

U kunt deze weergave ook omkeren om te zien welke units afhankelijk zijn van de opgegeven service. Voeg hiervoor de vlag --reverse toe:

systemctl list-dependencies --reverse sshd.service

Als u wilt controleren welke units zijn geconfigureerd om vóór of na de betreffende service te starten, kunt u deze opties gebruiken:

systemctl list-dependencies sshd.service --before

systemctl list-dependencies sshd.service --after

Unit-eigenschappen bekijken

Elke unit heeft veel eigenschappen die bepalen hoe systemd ermee omgaat. Gebruik het commando show om al deze eigenschappen voor een bepaalde unit te bekijken. Dit geeft gedetailleerde unitgegevens weer in een key=value-formaat:

systemctl show sshd.service

Hierdoor worden tientallen eigenschappen weergegeven, waaronder tot welke doelen deze unit behoort, eventuele conflicten met andere units en de afhankelijkheidsrelaties.

Als u slechts één bepaalde eigenschap wilt zien, kunt u filteren met de optie -p. Om bijvoorbeeld te controleren met welke units de sshd-service conflicteert:

systemctl show sshd.service -p Conflicts

Eenheden maskeren en demaskeren

Soms is het niet voldoende om een service gewoon te stoppen of uit te schakelen. Misschien wilt u volledig voorkomen dat deze onder welke omstandigheden dan ook wordt gestart. Hier komt maskeren om de hoek kijken. Wanneer een eenheid wordt gemaskeerd, koppelt systemd deze aan /dev/null, waardoor deze effectief wordt geblokkeerd voor handmatig of automatisch starten.

Om een eenheid te maskeren, voert u het volgende uit:

$ sudo systemctl mask apache2.service

Als u daarna alle unitbestanden controleert, ziet u dat apache2.service is gemarkeerd als “gemaskeerd”:

$ systemctl list-unit-files

Als u probeert een gemaskeerde service te starten, weigert systemd dit en geeft het een foutmelding:

$ sudo systemctl start apache2.service

Om de service weer te kunnen starten, ontmasker u deze met:

$ sudo systemctl unmask apache2.service

Hiermee wordt de blokkering verwijderd en wordt de unit teruggezet naar de normale staat, waarin deze weer kan worden gestart of ingeschakeld zoals elke andere service.

Hoe unitbestanden bewerken met systemctl?

Hoewel het buiten het bestek van deze handleiding valt om de exacte structuur en syntaxis van unitbestanden uit te leggen, biedt systemd ingebouwde tools waarmee u indien nodig direct wijzigingen kunt aanbrengen. Deze bewerkingsfuncties zijn geïntroduceerd in systemd versie 218.

Bewerken met systemctl

Met het bewerkingscommando kunt u wijzigingen aanbrengen in een unitbestand via een eenvoudige interface. Standaard opent dit commando een leeg override-bestand dat specifiek is voor de unit die u wilt wijzigen. Om bijvoorbeeld een override voor nginx.service te maken, gebruikt u:

$ sudo systemctl edit nginx.service

Hiermee wordt een map aangemaakt onder /etc/systemd/system met de naam van de unit gevolgd door .d, bijvoorbeeld nginx.service.d. In die map plaatst systemd een bestand met de naam override.conf, waar u uw aangepaste configuratie kunt toevoegen.

Wanneer de service start, combineert systemd dit overschrijvingsbestand met het hoofdunitbestand, waarbij voorrang wordt gegeven aan alle instellingen die in de overschrijving zijn gedefinieerd. Dit maakt het gemakkelijk om specifieke opties aan te passen zonder het oorspronkelijke bestand rechtstreeks te bewerken.

Het volledige unitbestand bewerken

Als u het volledige unitbestand wilt wijzigen in plaats van een kleine overschrijving te maken, kunt u de optie --full gebruiken:

$ sudo systemctl edit --full nginx.service

Met deze opdracht wordt het huidige volledige bestand in uw editor geladen, zodat u alle nodige wijzigingen kunt aanbrengen. Zodra u de editor opslaat en sluit, slaat systemd het gewijzigde bestand op in /etc/systemd/system, dat voorrang heeft op het standaardbestand in /lib/systemd/system.

Aangepaste wijzigingen verwijderen

Als u uw wijzigingen ooit ongedaan wilt maken, kunt u eenvoudigweg de overschrijvingsmap of het aangepaste unit-bestand zelf verwijderen.

Om een overschrijvingsmap te verwijderen:

$ sudo rm -r /etc/systemd/system/nginx.service.d

Om een volledig aangepast unit-bestand te verwijderen:

$ sudo rm /etc/systemd/system/nginx.service

Nadat de bestanden zijn verwijderd, moet u systemd opnieuw laden, zodat het de verwijderde bestanden vergeet en terugkeert naar het gebruik van het oorspronkelijke systeemeenheidsbestand:

sudo systemctl daemon-reload

Dit zorgt ervoor dat systemd niet langer zoekt naar of de wijzigingen toepast die u hebt verwijderd.

Systeemstatussen beheren met doelen

In systemd vertegenwoordigen doelen specifieke systeemstatussen, vergelijkbaar met traditionele runlevels in oudere init-systemen. Deze doelen worden gedefinieerd als speciale unitbestanden die eindigen op .target, en ze werken door andere units te groeperen om de gewenste status te bereiken.

Standaarddoel (opstartdoel)

Het systeem start op in een standaarddoel, dat de systeemstatus na het opstarten bepaalt. U kunt het huidige standaarddoel controleren met:

$ systemctl get-default

Om het standaarddoel te wijzigen, bijvoorbeeld naar een grafische desktopomgeving, gebruikt u:

$ sudo systemctl set-default graphical.target

Doelen weergeven en bekijken

Om alle beschikbare doelen op het systeem te zien:

$ systemctl list-unit-files --type=target

Om alleen de momenteel actieve doelen te bekijken:

$ systemctl list-units --type=target

Van doel wisselen (isoleren)

U kunt het systeem naar een ander doel schakelen, waarbij alle niet-gerelateerde services worden gestopt en alleen de services worden gestart die nodig zijn voor het nieuwe doel. Dit doet u met het commando isolate.

Om bijvoorbeeld over te schakelen van een grafische desktop naar een omgeving met alleen een opdrachtregel:

$ sudo systemctl isolate multi-user.target

Voordat u gaat isoleren, is het handig om te controleren van welke services een doel afhankelijk is:

$ systemctl list-dependencies multi-user.target

Zo voorkomt u dat u per ongeluk belangrijke services stopt.

Snelkoppelingen van Systemctl gebruiken voor belangrijke gebeurtenissen

Systemd biedt speciale snelkoppelingen voor het afhandelen van essentiële systeemgebeurtenissen, zoals afsluiten, opnieuw opstarten of de reddingsmodus activeren. Deze snelkoppelingen activeren de juiste doelen en stellen alle aangemelde gebruikers op de hoogte van de gebeurtenis, waardoor een extra communicatielaag wordt toegevoegd.

Om de reddingsmodus (modus voor één gebruiker) te activeren, voert u het volgende uit:

$ sudo systemctl rescue

Dit werkt op dezelfde manier als het isoleren van rescue.target, maar met als bijkomend voordeel dat actieve gebruikers worden geïnformeerd.

Om het systeem te stoppen (alle processen stoppen zonder uit te schakelen):

$ sudo systemctl halt

Om het systeem volledig uit te schakelen, gebruikt u:

$ sudo systemctl poweroff

Om de machine opnieuw op te starten:

$ sudo systemctl reboot

De meeste Linux-systemen bieden ook traditionele commando's die rechtstreeks aan systemd zijn gekoppeld, dus u kunt vaak gewoon het volgende typen:

$ sudo reboot

Deze commando's integreren naadloos met systemd, waardoor een goede communicatie en een nette afhandeling van systeemgebeurtenissen worden gegarandeerd.

Verbeter de beveiliging van services met systemd

Het beveiligen van systemd-services is een cruciale stap om uw systeem te beschermen tegen aanvallen, ongeoorloofde toegang en onopzettelijke schade. Hieronder vindt u een gestroomlijnde aanpak voor het versterken van services met behulp van systemd.

1. Begrijp service-unitbestanden

Elke service die door systemd wordt beheerd, heeft een bijbehorend unit-bestand, dat bepaalt hoe de service wordt uitgevoerd, inclusief opstartprocessen, toegangsrechten en resourcebeperkingen. Deze bestanden worden meestal opgeslagen in /etc/systemd/system/ en kunnen worden aangepast om de beveiliging te verbeteren.

2. Beperk serviceprivileges

• Voer uit als een niet-rootgebruiker: wijs een speciale gebruiker en groep toe aan elke service in plaats van deze als root uit te voeren. Dit vermindert het risico als de service wordt gecompromitteerd.

3. Gebruik de ingebouwde beveiligingsopties van systemd

• Isoleer tijdelijke mappen: schakel PrivateTmp in, zodat de service zijn eigen tijdelijke ruimte krijgt, waardoor gegevenslekken tussen services worden voorkomen.
• Beperk de toegang tot het systeem: stel ProtectSystem in om te beperken tot welke delen van het bestandssysteem de service toegang heeft. Gebruik ProtectHome om de toegang tot de thuismappen van gebruikers te blokkeren.
• Beheer de toegang tot mappen: gebruik ReadOnlyPaths om mappen als alleen-lezen te markeren en ReadWritePaths om te definiëren waar de service gegevens kan schrijven.

4. Stel limieten voor bronnen in

• Beperk het CPU- en geheugengebruik: gebruik CPUQuota om te beperken hoeveel CPU de service kan gebruiken en MemoryLimit om te beperken hoeveel geheugen deze kan verbruiken. Dit helpt om overmatig bronnenverbruik te voorkomen, of dit nu opzettelijk is of het gevolg is van bugs.

5. Beheer netwerktoegang

• Beheer netwerkblootstelling: gebruik RestrictAddressFamilies om te beperken welke adresfamilies de service kan gebruiken (bijvoorbeeld door AF_INET uit te schakelen als netwerktoegang niet nodig is).
• Gebruik IPAddressAllow en IPAddressDeny om netwerktoegangsregels te maken als de service moet communiceren.

6. Bestandseigendom en machtigingen

• Zorg voor de juiste bestandsmachtigingen: de bestanden en mappen die door de service worden gebruikt, moeten de juiste eigendom (via chown) en beperkende machtigingen (via chmod) hebben. Alleen de benodigde gebruikers mogen schrijftoegang hebben tot configuratiebestanden, logboeken en gegevens.

7. Blijf up-to-date en controleer logboeken

• Pas regelmatig updates toe: houd zowel het systeem als de servicessoftware up-to-date om de nieuwste beveiligingspatches te ontvangen.
• Controleer serviceactiviteit: Gebruik journalctl om de logbestanden van de service te controleren op fouten, verdachte activiteiten of beveiligingsgerelateerde berichten.

Conclusie

In dit artikel hebben we geleerd hoe we het commando systemctl kunnen gebruiken. Systemctl is het belangrijkste hulpmiddel voor het beheren van services en systeemstatussen in systemd. Het dient als de belangrijkste interface voor interactie met het kernproces van het systeem. Systemd bevat echter ook aanvullende hulpmiddelen, zoals journalctl voor het bekijken van logbestanden en loginctl voor het beheren van gebruikerssessies. Als u deze gerelateerde tools begrijpt, kunt u uw systeem effectiever beheren.

Is uw bedrijf de grenzen van VPS-hosting ontgroeid? Upgrade dan naar de kracht en prestaties van een dedicated server van BlueServers!

• Volledig aanpasbaar en gebouwd om mee te groeien met uw behoeften
• Volledige servercontrole in een dedicated omgeving
• Geniet van onbeperkt verkeer voor uw groeiende bedrijf

Til uw hosting naar een hoger niveau — Ontdek vandaag nog de dedicated servers van BlueServers!