Vraag Hoe kan ik systemd services negeren of configureren?


Veel sysv init-scripts gebruikten een overeenkomstig bestand in /etc/default om de beheerder toe te staan ​​het te configureren. Upstart-taken kunnen worden aangepast met behulp van .override bestanden. Hoe kan ik systemd-eenheden overschrijven of configureren, nu systemd de standaard is in Ubuntu?


69
2017-08-09 03:31


oorsprong




antwoorden:


systemd eenheden hoeven de bestanden niet te gehoorzamen /etc/default. systemd is eenvoudig te configureren, maar vereist dat u de syntaxis kent van systemd unit-bestanden.

Pakketten verzenden unit-bestanden meestal in /lib/systemd/system/. Dit zijn niet om te worden bewerkt. In plaats daarvan, systemd kunt u deze bestanden overschrijven door de juiste bestanden te maken in /etc/systemd/system/.

Voor een bepaalde service foo, het pakket zou bieden /lib/systemd/system/foo.service. U kunt de status controleren met systemctl status foo, of bekijk de logboeken met journalctl -u foo. Om iets op te heffen in de definitie van foo, doen:

sudo systemctl edit foo

Hiermee wordt een map gemaakt in /etc/systemd/system vernoemd naar de eenheid, en een override.conf bestand in die map (/etc/systemd/system/foo.service.d/override.conf). U kunt instellingen toevoegen of negeren met dit bestand (of andere .conf bestanden in /etc/systemd/system/foo.service.d/).

Opdracht argumenten overschrijven

Neem de getty dienst bijvoorbeeld. Stel dat ik TTY2-autologine voor mijn gebruiker wil hebben (dit is niet aan te raden, maar slechts een voorbeeld). TTY2 wordt gerund door de getty@tty2 service (tty2 een instantie van de sjabloon zijn /lib/systemd/system/getty@service). Om dit te doen, moet ik het wijzigen getty@tty2 service.

$ systemctl cat getty@tty2
# /lib/systemd/system/getty@.service
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
After=systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

# On systems without virtual consoles, don't start any getty. Note
# that serial gettys are covered by serial-getty@.service, not this
# unit.
ConditionPathExists=/dev/tty0

[Service]
# the VT is cleared by TTYVTDisallocate
ExecStart=-/sbin/agetty --noclear %I $TERM
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=

[Install]
WantedBy=getty.target
DefaultInstance=tty1

In het bijzonder, ik moet het veranderen ExecStart regel, die momenteel is:

$ systemctl cat getty@tty2 | grep Exec     
ExecStart=-/sbin/agetty --noclear %I $TERM

Om dit op te heffen, doe:

sudo systemctl edit getty@tty2

En voeg toe:

[Service]
ExecStart=
ExecStart=-/sbin/agetty -a muru --noclear %I $TERM

Let daar op:

  1. Ik moest het expliciet duidelijk maken ExecStart voordat je het opnieuw instelt, omdat het een additieve instelling is, vergelijkbaar met After, Environment (in zijn geheel, niet per variabele) en EnvironmentFile, en tegengesteld aan het negeren van instellingen zoals RestartSec of Type. ExecStart kan meerdere vermeldingen hebben alleen voor Type=oneshot Diensten.
  2. Ik moest de juiste sectiekop gebruiken. In het originele bestand, ExecStart is in de [Service] sectie, dus mijn override moet zetten ExecStart in de [Service] sectie ook. Vaak kijkt u naar het daadwerkelijke servicebestand met behulp van systemctl cat zal je vertellen wat je moet overschrijven en in welke sectie het is.

Gewoonlijk moet u, als u een systemd unit-bestand bewerkt, om het effect te krijgen, het volgende uitvoeren:

sudo systemctl daemon-reload

Echter, systemctl edit doet dit automatisch voor u.

Nu:

$ systemctl cat getty@tty2 | grep Exec
ExecStart=-/sbin/agetty --noclear %I $TERM
ExecStart=
ExecStart=-/sbin/agetty -a muru --noclear %I $TERM

$ systemctl show getty@tty2 | grep ExecS
ExecStart={ path=/sbin/agetty ; argv[]=/sbin/agetty -a muru --noclear %I $TERM ; ... }

En als ik dat doe:

sudo systemctl restart getty@tty2

en druk op CtrlaltF2, presto! Ik zal op die TTY ingelogd zijn op mijn account.

Zoals ik al zei, getty@tty2 is een instantie van een sjabloon. Dus, wat als ik alle exemplaren van die sjabloon zou willen overschrijven? Dat kan gedaan worden door de sjabloon zelf te bewerken (in dit geval de instantie-identifier verwijderen) tty2):

systemctl edit getty@

De omgeving negeren

Een veelgebruikt voorbeeld van /etc/default bestanden zijn omgevingsvariabelen in te stellen. meestal /etc/default is een shellscript, dus je zou hier taalconstructies in kunnen gebruiken. Met systemddit is echter niet het geval. U kunt omgevingsvariabelen op twee manieren specificeren:

Via een bestand

Stel dat u de omgevingsvariabelen in een bestand hebt ingesteld:

$ cat /path/to/some/file
FOO=bar

Vervolgens kunt u toevoegen aan de overschrijving:

[Service]
EnvironmentFile=/path/to/some/file

In het bijzonder, als uw /etc/default/grub bevat alleen toewijzingen en geen shell-syntaxis, je zou het kunnen gebruiken als EnvironmentFile.

Via Environment entries

Het bovenstaande kan ook worden bereikt met behulp van de volgende opheffing:

[Service]
Environment=FOO=bar

Dit kan echter lastig worden met meerdere variabelen, spaties, etc. Kijk eens naar een van mijn andere antwoorden voor een voorbeeld van een dergelijke instantie.

Verder lezen

Via dit mechanisme wordt het heel gemakkelijk om op te heffen systemd eenheden, en om dergelijke wijzigingen ongedaan te maken (door eenvoudig het override-bestand te verwijderen). Dit zijn niet de enige instellingen die kunnen worden gewijzigd.

De volgende links zijn handig:


118
2017-08-09 03:31



U moet de variabele wissen voordat u deze instelt voor services die niet van het type zijn. Dit loste mijn probleem op. - Colin
Kan iemand me wijzen naar waar ik in de systeemdocumenten informatie kan vinden over het "wissen" van de geërfde waarde met ExecStart= zoals getoond in dit antwoord? - Mark Edington
@MarkEdington van de systemd.service(5) manpage, sectie op ExecStart: "Tenzij Type = niet beschikbaar is, moet exact één opdracht worden gegeven.Wanneer Type = oneeshot wordt gebruikt, kunnen nul of meer opdrachten worden opgegeven.Commando's kunnen worden opgegeven door meerdere opdrachtregels in dezelfde richtlijn op te geven, of anders kan deze richtlijn meerdere keren worden opgegeven met hetzelfde effect Als de lege reeks aan deze optie is toegewezen, wordt de lijst met te starten opdrachten opnieuw ingesteld, eerdere toewijzingen van deze optie hebben geen effect. " - muru
@Orient dat kan sudo rm het override-bestand en dan systemctl daemon-reload, of je kan systemctl edit en vervang alles in de opheffing door opmerkingen. Opmerkingen in servicebestanden beginnen met #. - muru
@Oriënteren systemctl revert foo - Ayell