Hoe kan ik services automatisch opstarten bij het opstarten in RHEL / CentOS 7?

Vraagt ​​u zich af hoe u services op de achtergrond of tijdens het opstarten kunt beheren?


Het mechanisme voor het beheren en starten van processen bij het opstarten is gewijzigd. Tot RHEL / CentOS 6.x zou je een script in /etc/init.d/ hebben gemaakt en ingeschakeld met behulp van chkconfig, maar de zaken zijn anders op RHEL 7.

Het is vervangen door systemd en aangezien het min of meer de standaardprocesbeheerder is op de belangrijkste Linux-versies, voelt System Admin thuis in andere smaken zich meteen thuis. In dit artikel zullen we onderzoeken wat systemd is, wat de redenen voor de overstap waren en hoe systemd gebruikt kan worden om hiermee achtergrondprocessen op te zetten, uit te voeren en te beheren.

Wat is systemd?

Aangezien elk proces in Linux transparant zichtbaar is, laten we eens kijken waar systemd op de loer ligt. Op mijn systeem krijg ik het volgende:

~ $ ps -ef | grep systemd
root 1 0 0 nov11? 00:01:02 / lib / systemd / systemd –system – deserialize 22
bericht + 768 1 0 nov11? 00:05:46 / usr / bin / dbus-daemon –system –address = systemd: –nofork –nopidfile –systemd-activation –syslog-only
root 805 1 0 nov11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 1 0 nov11? 00:00:00 / lib / systemd / systemd –user
ankush 1176 1132 0 nov11? 00:04:50 / usr / bin / dbus-daemon –session –address = systemd: –nofork –nopidfile –systemd-activation –syslog-only
ankush 9772 20029 0 21:11 ptn / 6 00:00:00 grep –color = auto systemd
systemd + 17298 1 0 nov19? 00:00:12 / lib / systemd / systemd-resolved
systemd + 17303 1 0 nov19? 00:00:00 / lib / systemd / systemd-timesyncd
root 17307 1 0 nov19? 00:00:02 / lib / systemd / systemd-journald
root 18182 1 0 nov19? 00:00:00 / lib / systemd / systemd-udevd

Ik wed dat je het meteen opmerkte. het eerste proces in de lijst is gestart als de root van de gebruiker en heeft de pid 1.

Zeker, dit was het eerste proces dat het systeem opstartte tijdens het opstarten. Zeg hallo tegen systemd. ��

Dus, heel eenvoudig, systemd is het ‘moeder’-proces dat andere processen in het systeem start, beheert en beëindigt, naast het verstrekken van informatie over hun logging, bestandssysteemstatussen, enz..

Een opmerking over de naam. De naam is inderdaad systemd en niet System D of iets anders. De “d” staat voor daemon, een standaard Linux-proces dat op de achtergrond werkt (schuilt?) En niet aan een terminalsessie is gekoppeld.

Waarom RHEL is overgestapt op systemd?

Zoals we al hebben besproken, is systemd een systeem- en procesmanager en vervangt in RHEL 7 het bekende programma Upstart. Waarom heeft RHEL (Oracle?) Deze beslissing genomen? Welnu, daar zijn heel goede redenen voor, dus laten we even kijken.

Parallelle service-initialisatie

In tegenstelling tot het SysV init-programma, kan systemd services parallel starten. Het init-programma start ze daarentegen een voor een. In een tijdperk waarin zelfs mobiele apparaten multi-core CPU’s hebben, is het gebrek aan parallelle initialisatie een grote afknapper.

Dynamisch (hot) servicemanagement

Als je hebt gemerkt dat USB-drives expliciet moeten worden gemonteerd op eerdere Fedora-systemen, terwijl ze automatisch zouden opengaan op Ubuntu en soortgelijke distributies, is de reden systemd. Het kan live veranderingen in hardware detecteren en services beëindigen / starten indien nodig. Sommigen kunnen beweren dat het niet nodig is, maar voor velen is alles dat de cognitieve belasting vermindert, zeer welkom.

Uitgestelde servicelancering

systemd maakt opstarttijden korter omdat het de lancering van de service kan uitstellen tot wanneer het echt nodig is. Een eenvoudig voorbeeld zijn netwerkbestandssysteemgerelateerde services. Als er geen netwerkschijf beschikbaar is, heeft het geen zin om een ​​service actief te hebben.

Snellere procescommunicatie

De parallelle mogelijkheden van systemd gaan over op communicatie tussen processen. systemd biedt parallelle toegang tot sockets en systeembus, waardoor de wachttijden voor communicatiebronnen aanzienlijk worden verkort.

Automatische herstart

Als een service crasht, kan systemd dat detecteren en proberen het opnieuw op te starten. Meestal is een eenvoudige herstart alles wat nodig is om een ​​applicatie weer te laten functioneren, tenzij er meer fundamentele problemen zijn.

Hoe dan ook, systemd maakt het leven van een systeembeheerder hier gemakkelijker.

systemd in RHEL7 – Wat verandert er voor Sysadmins?

Als je een zeurderig gevoel hebt dat het systeem niet allemaal toeters en bellen zal zijn, heb je gelijk. Er zijn een paar belangrijke onverenigbaarheden die RHEL-sysadmin kunnen verrassen. Laten we even kijken.

Beperkte runlevel-ondersteuning

systemd heeft een behoorlijk armoedige herkenning van en ondersteuning voor runlevels. Niet alle runlevels worden ondersteund en voor sommige doelen zijn er misschien zelfs geen. In dergelijke gevallen retourneert systemd “N” als antwoord op de runlevel-opdrachten, wat aangeeft dat het geen overeenkomstig runlevel heeft voor dit doel. Al met al adviseert Red Hat ons om de runlevel-commando’s niet te gebruiken (!).

Geen aangepaste opdrachten

Deze gaat pijn doen. Een groot pluspunt van SysV was de mogelijkheid om aangepaste opdrachten te definiëren om betere functionaliteit te bieden voor het beheren van processen. Met systemd is er niet zo’n optie en zit je vast met start, stop, status, herstart, enz.

Alleen voor gezinnen en niet-interactief

systemd houdt (natuurlijk) de processen bij die het heeft gestart en slaat hun PID’s op. De uitdaging is echter dat systemd niet overweg kan met processen die niet door haar zijn opgestart. Verder is het voor een gebruiker niet mogelijk om te interageren met een door systemd gestart proces. Alle uitvoer gaat naar / dev / null, waardoor de hoop die u had op het vastleggen van uitvoer effectief wordt stopgezet.

Geen context

In tegenstelling tot init-services, nemen de door systemd gestarte services geen omgeving over van gebruikers in het systeem. Met andere woorden, informatie zoals PATH en andere systeemvariabelen zijn niet beschikbaar en elk nieuw proces wordt in een lege context gestart.

Als deze lijst met beperkingen je aan het huilen maakt, ben je niet alleen. systemd is een polariserende kracht geweest in de Linux-wereld, en Googelen op “systemd sucks” zal veel leesmateriaal opwerpen. ��

De service automatisch starten wanneer deze niet beschikbaar is?

Hier is een vrij algemeen gebruik bij implementaties. We moeten een programma daemoniseren in een taal die geen langlopende processen heeft: PHP! Laten we aannemen dat ik een PHP-script schrijf om inkomende websocket-verbindingen af ​​te handelen (we hebben tenslotte een chat-app gebouwd!) En het script wordt op /home/ankush/chat_server/index.php geplaatst.

Aangezien websocket-verbindingen de server op elk moment kunnen raken, moet dit proces te allen tijde actief zijn en binnenkomende verbindingen controleren. We kunnen hier niet de traditionele PHP-levenscyclus hebben, omdat WebSockets stateful verbindingen zijn en als het script sterft, is de verbinding een lijst. In ieder geval genoeg op websockets; laten we eens kijken hoe we dit script via systeemd gaan demonen.

Alle systemd-services bevinden zich in / etc / systemd / system, dus laten we daar een bestand maken om ons websocket-serverscript te beschrijven. Ervan uitgaande dat u bent aangemeld als rootgebruiker.

# vi /etc/systemd/system/chat_server.service

en dan is het volgende nodig.

[Eenheid]
Beschrijving = Chat Server-service
After = network.target

[Onderhoud]
Type = eenvoudig
Gebruiker = ankush
ExecStart = php /home/ankush/chat_server/index.php
Herstarten = afbreken

[Installeren]
WantedBy = multi-user.target

Sla het bestand op en de volgende stap is het opnieuw laden van de systemd daemon

# systemctl daemon-herladen

en om de service te starten die we zojuist hebben gemaakt:

# systemctl start chat_server

Als je geen fouten ziet, was dat het!

Laten we ook snel kijken wat de verschillende richtlijnen in het bestand betekenen:

  • Het deel [Unit] definieert een nieuwe service-eenheid voor systemd. In het systeemgebruik worden alle services ook wel service-units genoemd.
  • De After-richtlijn (voorspelbaar) vertelt systemd om deze service alleen te starten nadat de netwerkservices zijn gestart (anders, wie doet de afhandeling op lager niveau van socketverbindingen ?!).
  • De Type = simple vertelt systemd dat deze service niet mag vorken. Met andere woorden, er zal altijd maar één exemplaar worden uitgevoerd.
  • User = ankush betekent dat deze service wordt uitgevoerd als de gebruiker “ankush”. We kunnen dit wijzigen in ‘root’, maar dit wordt ten zeerste afgeraden vanuit beveiligingsoogpunt.
  • ExecStart is, zoals u kunt zien, het daadwerkelijke commando dat moet worden uitgevoerd.
  • Restart = on-abort betekent dat de service opnieuw moet worden gestart wanneer deze wordt afgebroken. In PHP lekken langlopende processen geheugen en exploderen uiteindelijk, dus dit is nodig.
  • De WantedBy = richtlijn vertelt systemd van welk doel (denk aan groepen) deze dienst deel uitmaakt. Dit resulteert in symbolische links die binnen dat doel worden gemaakt om naar de service te verwijzen.

Over het algemeen is dit voldoende om achtergrondprocessen uit te voeren met systemd in RHEL 7.

Meer optie voor herstartlogica

In het bovenstaande voorbeeld heb ik Restart = on-abort geconfigureerd, maar dat is niet de enige optie. Er zijn er meer en kies op basis van de vereiste.

  • bij mislukking – zal opnieuw worden opgestart als de code of het signaal onrein is
  • altijd – herstart wanneer gevonden, schoon of onrein signaal
  • on-abnormaal – onrein signaal, waakhond of time-out
  • op succes – alleen wanneer het werd gestopt door een schoon signaal of exitcode

Service configureren om te starten bij opstarten

Zodra u tevreden bent met het script en ervoor zorgt dat het werkt, wilt u dat vervolgens configureren zodat het wordt geactiveerd bij het opstarten en starten.

Ga naar / etc / systemd / system en voer de onderstaande opdracht voor inschakelen uit (vergeet niet de .service-bestandsnaam te wijzigen met degene die je hebt)

# systemctl chat_server.service inschakelen

Je ziet een bevestiging dat er een symlink is gemaakt.

Symlink gemaakt van /etc/systemd/system/multi-user.target.wants/chat_server.service naar /etc/systemd/system/chat_server.service.

Start uw server opnieuw op en u zou moeten zien dat service begint bij het opstarten.

Dat was gemakkelijk! Is het niet?

Helpen! Ik heb enorm geïnvesteerd in Upstart. ��

Ik begrijp dat je me vertrouwt, je zaak is eerder de norm dan de uitzondering. RHEL gebruikt Upstart al zo lang dat de switch bijna aanvoelt als verraad. Maar goed, systemen blijven veranderen en we mogen niet over kleinigheden kibbelen. Red Hat erkent dat veel mensen vastzitten aan oudere versies en een migratie gids waar je zeker naar moet verwijzen.

Een reddende genade bij dit alles is dat systemd compatibel is met de SysV init-scripts, dus voor het grootste deel hoef je alleen maar je bestanden te verplaatsen en dezelfde services te laten draaien.

Wilt u meer weten over Linux-beheer en probleemoplossing? Kijk hier eens naar online cursus.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map