Hvordan starte auto-tjenester på Boot i RHEL / CentOS 7?

Lurer på hvordan du kan administrere tjenester i bakgrunnen eller på oppstart?

Mekanismen for å styre og starte prosesser på oppstart er endret. Inntil RHEL / CentOS 6.x, ville du ha opprettet et skript i /etc/init.d/ og aktivert ved hjelp av chkconfig, men ting er annerledes på RHEL 7.

Det er erstattet av systemd, og siden det mer eller mindre er standard prosessbehandler på større Linux-versjoner, vil systemadministrator med andre smaker føles som hjemme. I denne artikkelen skal vi utforske hva systemd er, hva årsakene til bryteren var, og hvordan du bruker systemd til å sette opp, kjøre og administrere bakgrunnsprosesser med det.

Hva er systemd?

Siden hver prosess i Linux er transparent synlig, la oss se hvor systemd lurer. På systemet mitt får jeg følgende:

~ $ ps -ef | grep systemd
root 1 0 0 Nov11? 00:01:02 / lib / systemd / systemd – system – deserialize 22
melding + 768 1 0 nov11? 00:05:46 / usr / bin / dbus-daemon –system – adresse = systemd: –nofork –nopidfile – systemd-aktivering – bare logistisk
root 805 1 0 Nov11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 1 0 nov11? 00:00:00 / lib / systemd / systemd – bruker
ankush 1176 1132 0 nov11? 00:04:50 / usr / bin / dbus-daemon – sesjon – adresse = systemd: –nofork –nopidfile – systemd-aktivering – bare logistikk
ankush 9772 20029 0 21:11 pts / 6 00:00:00 grep – farge = auto systemd
systemd + 17298 1 0 nov19? 00:00:12 / lib / systemd / systemd-løst
systemd + 17303 1 0 nov19? 00:00:00 / lib / systemd / systemd-timesyncd
rot 17307 1 0 nov19? 00:00:02 / lib / systemd / systemd-journald
rot 18182 1 0 nov19? 00:00:00 / lib / systemd / systemd-udevd

Jeg vedder på at du la merke til det med en gang. den første prosessen i oppføringen ble lansert som brukerrot, og har pid 1.

Visst nok, dette var den første prosessen som systemet startet ved oppstart. Si hei til systemd. ��

Så ganske enkelt, systemd er “mor” -prosessen som lanserer, administrerer og avslutter andre prosesser i systemet, i tillegg til å gi informasjon om deres logging, filsystemstatus osv..

En merknad om navnet. Navnet er faktisk systemd og ikke System D eller noe annet. “D” står for daemon, en standard Linux-prosess som fungerer (lurer?) I bakgrunnen og ikke er knyttet til noen terminaløkt.

Hvorfor RHEL byttet til systemd?

Som vi allerede har diskutert, systemd er en system- og prosessleder, og i RHEL 7 erstatter det velkjente programmet Upstart. Hvorfor tok RHEL (Oracle?) Denne avgjørelsen? Det er veldig gode grunner til dette, så la oss ta en rask titt.

Parallell serviceinitialisering

I motsetning til SysV init-programmet, er systemd i stand til å lansere tjenester parallelt. Init-programmet, derimot, lanserer dem en etter en. I en tid der selv mobile enheter har flerkjernede CPUer, er mangelen på parallellinitiering en stor avkjøring.

Dynamisk (hot) service management

Hvis du har lagt merke til at USB-stasjoner må være eksplisitt montert på tidligere Fedora-systemer mens de automatisk åpnes på Ubuntu og lignende distribusjoner, er grunnen systemd. Det er i stand til å oppdage live endringer i maskinvare og avslutte / lansere tjenester etter behov. Noen kan hevde at det er unødvendig, men for mange er alt som reduserer kognitiv belastning hjertelig velkommen.

Utsatt tjeneste lansering

systemd gjør oppstartstiden kortere ettersom den er i stand til å utsette tjenestelansering til når den faktisk er nødvendig. Et enkelt eksempel er nettverksfilsystemrelaterte tjenester. Hvis det ikke er noen nettverksdisk tilgjengelig, er det ikke fornuftig å ha en tjeneste i gang.

Raskere prosesskommunikasjon

De parallelle mulighetene til systemd overfører til prosess-kommunikasjon. systemd kan tilby parallell tilgang til stikkontakter og systembuss, noe som reduserer prosessens ventetid for kommunikasjonsressurser betydelig.

Automatisk omstart

Hvis en tjeneste krasjer, kan systemd oppdage det og prøve å starte den på nytt. Som oftest er en enkel omstart alt som trengs for at en applikasjon skal begynne å fungere igjen, med mindre det er mer grunnleggende problemer.

Uansett gjør systemd livet til en sysadmin enklere her.

systemd i RHEL7 – Hva endres for Sysadmins?

Hvis du har en irriterende følelse av at systemd ikke kommer til å være alle bjeller og fløyter, har du rett. Det er noen få betydelige uforenligheter som kan fange RHEL-sysadmin overraskende. La oss ta en rask titt.

Begrenset løpestøtte

systemd har en ganske loslitt anerkjennelse av og støtte for runlevels. Ikke alle runlevels støttes, og for noen mål kan det til og med være ingen. I slike tilfeller returnerer systemd “N” som svar på løpekommandoer, noe som indikerer at det ikke har noe tilsvarende løpespeil til dette målet. Alt i alt råder Red Hat oss til å ikke bruke (!) Kommandoene for løpestrøm.

Ingen tilpassede kommandoer

Denne kommer til å gjøre vondt. Et stort pluss med SysV var muligheten til å definere tilpassede kommandoer for å gi bedre funksjonalitet for styring av prosesser. Med systemd er det ikke noe slikt alternativ, og du sitter fast med start, stopp, status, omstart osv.

Familie-bare og ikke-interaktive

systemd (selvfølgelig) holder oversikt over prosessene den har lansert og lagrer PID-ene deres. Utfordringen er imidlertid at systemd ikke kan håndtere prosesser som ikke er startet av den. Videre er det ikke mulig for en bruker å samhandle med en prosess startet av systemd. All produksjon går til / dev / null, og stopper effektivt alle forhåpninger du måtte ha for å fange ut.

Ingen kontekst

I motsetning til init-tjenester, arver de som er lansert av systemd ikke noe miljø fra noen brukere i systemet. Med andre ord, informasjon som PATH og andre systemvariabler er ikke tilgjengelig, og hver nye prosess blir lansert i en tom kontekst.

Hvis denne listen over begrensninger får deg til å gråte, igjen, er du ikke alene. systemd har vært en polariserende kraft i Linux-verdenen, og Googling på “systemd sucks” vil avdekke rikelig med lesestoff. ��

Hvordan starte tjenesten automatisk når du er nede?

Her er en ganske vanlig brukssak i distribusjoner. Vi må demonisere et program på et språk som ikke har langvarige prosesser: PHP! La oss anta at jeg skriver et PHP-skript for å håndtere innkommende websocket-tilkoblinger (vi bygde tross alt en chatte-app!) Og skriptet er plassert på /home/ankush/chat_server/index.php.

Siden nettkontaktforbindelser kan treffe serveren når som helst, må denne prosessen være oppe til enhver tid og overvåke innkommende tilkoblinger. Vi kan ikke ha den tradisjonelle PHP-livssyklusen her fordi WebSockets er tilstrekkelige forbindelser, og hvis skriptet dør, er forbindelsen en liste. Uansett, nok på nettstikk; la oss se hvordan vi skal gjøre om å demontere dette skriptet via systemd.

Alle systemtjenester er bosatt i / etc / systemd / system, så la oss lage en fil der for å beskrive websocket server-skriptet. Forutsatt at du er logget inn som rotbruker.

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

og så er følgende nødvendig.

[Enhet]
Beskrivelse = Chat Server Service
Etter = network.target

[Service]
Type = enkel
User = Ankush
ExecStart = php /home/ankush/chat_server/index.php
Restart = on-abort

[Installere]
WantedBy = multi-user.target

Lagre filen, og neste trinn er å laste inn systemdemonken på nytt

# systemctl daemon-reload

og for å starte tjenesten vi nettopp opprettet:

# systemctl start chat_server

Hvis du ikke ser noen feil, var det det!

La oss også raskt se på hva de forskjellige direktivene i filen betyr:

  • [Enhet] -delen definerer en ny tjenesteenhet for systemd. I systemdeparlance er alle tjenester kjent som service-enheter.
  • Etter-direktivet (forutsigbart) ber systemd om å starte denne tjenesten først etter at nettverkstjenestene er lansert (ellers, hvem vil gjøre lavere håndtering av socketforbindelser ?!).
  • Type = simple forteller systemd at denne tjenesten ikke er ment å gaffel seg selv. Med andre ord, bare en forekomst kjører når som helst.
  • Bruker = ankush betyr at denne tjenesten kjøres som brukeren “ankush”. Vi kan endre dette til “rot”, men det er sterkt anbefalt fra et sikkerhetsperspektiv.
  • ExecStart er, som du kan si, den egentlige kommandoen som skal kjøres.
  • Restart = on-abort betyr at tjenesten skal startes på nytt når den avbryter. I PHP lekker langvarige prosesser minne og eksploderer til slutt, så dette er nødvendig.
  • WantedBy = -direktivet forteller systemd hvilket mål (tenk på grupper) denne tjenesten er en del av. Dette resulterer i at det opprettes symbolske lenker i det målet for å peke på tjenesten.

Generelt er dette nok for å kjøre bakgrunnsprosesser ved å bruke systemd i RHEL 7.

Mer alternativ for omstartlogikk

I eksemplet ovenfor har jeg konfigurert Restart = on-abort, men det er ikke det eneste alternativet. Det er flere og velge ut fra kravet.

  • on-fiasko – vil bli startet på nytt når uren exit-kode eller signal
  • bestandig – start på nytt når det er funnet nede, rent eller urent signal
  • på-unormal – urent signal, vakthund eller timeout
  • on-suksess – bare når det ble stoppet av et rent signal eller utgangskode

Konfigurere tjenesten til å starte på oppstart

Når du er fornøyd med skriptet og sørger for at det fungerer, vil du neste gang konfigurere det slik at det utløses ved oppstart og start.

Gå til / etc / systemd / system og utfør nedenfor aktiver kommando (ikke glem å endre .service-filnavnet med det du har)

# systemctl enable chat_server.service

Du vil se en bekreftelse på at den har opprettet en symlink.

Opprettet symlink fra /etc/systemd/system/multi-user.target.wants/chat_server.service til /etc/systemd/system/chat_server.service.

Start serveren din på nytt, og du skal se service starter på oppstart.

Det var lett! Er det ikke?

Hjelp! Jeg er massivt investert i Upstart. ��

Jeg forstår at du stoler på meg, saken din er normen snarere enn unntaket. RHEL har brukt Upstart så lenge at bryteren nesten føles som et svik. Men hei, systemer endrer seg stadig, og vi skal ikke kvele over bagateller. Red Hat erkjenner at mange mennesker sitter fast med eldre versjoner, og har laget en migrasjonsguide som du absolutt bør henvise til.

En reddende nåde med alt dette er at systemd er kompatibel med SysV init-skript, så for det meste trenger du ganske enkelt å flytte filene dine og få de samme tjenestene som kjører.

Er du interessert i å lære mer om Linux-administrasjon og feilsøking? Sjekk ut dette nettkurs.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Комментариев нет, будьте первым кто его оставит

    Комментарии закрыты.