Systemd 260 fjerner SysV og omdefinerer oppstart i Linux

Ankomsten av systemd 260 markerer et vendepunkt for Linux-økosystemet. Denne nye versjonen av det mest utbredte init-systemet og tjenestebehandleren i moderne distribusjoner kommer fullpakket med dyptgripende endringer, noen av dem banebrytende, som påvirker alt fra kompatibilitet med eldre programvare til hvordan sikkerhet, nettverk, containere og til og med integrering av AI-agenter administreres. Hvis du administrerer servere eller jobber med Linux daglig, er dette en av disse versjonene verdt å undersøke nøye.

Utover overskriftene er hovedfokuset den definitive fjerningen av støtte for de klassiske SysV init-skriptene , noe som avslutter et historisk kapittel i Linux og nødvendiggjør en gjennomgang av eldre tjenester. Ved siden av dette tiltaket introduserer systemd 260 nye verktøy, øker minimumskravene til kjernen, forbedrer integrasjonen med TPM2, styrker tjenesteisoleringen, utvider nettverks- og containerfunksjoner og forbedrer en rekke detaljer designet for skrivebordsmiljøer, servere og skydistribusjoner.

Slutt på støtte for SysV init: hva endres i praksis

En av de mest omtalte nye funksjonene i systemd 260 er fullstendig fjerning av støtte for oppstartsskript i System V-stil, de typiske skriptene som er lagret i /etc/init.d/ som i årevis har vært grunnlaget for lansering av tjenester på Linux. Denne støtten hadde lenge blitt stemplet som foreldet, og det ble advart om at den til slutt ville forsvinne; nå er det øyeblikket kommet.

Med denne versjonen, Komponentene som er ansvarlige for å oversette SysV-skript til systemd-enheter er fjernet.Slike deler forsvinner systemd-sysv-generator, som genererte enheter «på farten» fra /etc/init.dOg også systemd-sysv-install, i tillegg til andre kompatibilitetselementer som systemd-rc-local-generator y rc-local.service, som støttet den klassiske /etc/rc.local.

Denne bevegelsen innebærer at Enhver tjeneste som fortsatt utelukkende er avhengig av SysV-skript, vil slutte å starte riktig når distribusjonen tar i bruk systemd 260.med mindre en innebygd enhet er opprettet .serviceI moderne infrastrukturer vil effekten være relativt lav, men i miljøer med gammel eller spesialutviklet programvare kan det være mer enn én overraskelse hvis det ikke utføres en forhåndsrevisjon.

I mellomtiden, noen Meson-byggesystemalternativer relatert til SysV er merket som foreldet eller fjernet.Parametere som -Drc-local=, -Dsysvinit-path= y -Dsysvrcnd-path= De forblir utdaterte, mens alternativer som -Dintegration-tests= y -Dcryptolib= De forsvinner direkte fra kompileringstreet, noe som forenkler kodebasen.

I operative termer betyr dette også at systemd fokuserer nå utelukkende på native enheteruten mellomlag eller automatisk generering av tjenester fra eldre skript. Budskapet er ganske klart: hvis noe viktig i systemet ditt fortsatt eksisterer som skript i /etc/init.d/Det er på tide å migrere det eksplisitt.

Hvorfor SysV ble fjernet: teknisk opprydding og økosystemets fremtid

Beslutningen om å fjerne SysV init-støtte var ikke vilkårlig. Fra prosjektets perspektiv var det å opprettholde eldre kode for en praktisk talt foreldet init-mekanisme en byrde som kompliserte vedlikeholdet og utviklingen av rammeverket. Kompatibilitetsstøtte hadde blitt ansett som eldre kode i årevis, og den faktiske bruken i større distribusjoner ble stadig mer marginal.

Ved å fjerne dette laget reduserer systemd intern kompleksitet og eliminerer utførelsesbaner som er vanskelige å teste og sikre . Med færre spesialbaner for å håndtere eldre tjenester, kan utviklingsteamet fokusere på å forbedre den native kjerne-enhetsmotoren, forbedre sikkerhet, ytelse og integrasjon med nye kjerne- og brukerområde-API-er.

Det er også en klar komponent av samsvar med gjeldende standarder for tjenesteadministrasjon . I dag har så godt som alle større Linux-distribusjoner omfavnet systemd som sitt primære init-system og tilbyr native enheter for pakkene sine. Å opprettholde SysV som en krykke var i praksis å støtte opp om en oppstartsmodell som ikke lenger passet med moderne metoder for å beskrive avhengigheter, cgroups, strukturerte logger og ressurskontroller.

Fra et ytelsesperspektiv reduserer fjerning av kompatibilitetslag overhead og unngår unødvendige transformasjoner under oppstart. Selv om effekten i millisekunder kanskje ikke er dramatisk, kan det i svært veljusterte systemer eller systemer med mange tjenester bidra til å opprettholde mer forutsigbar oppførsel. Videre er det nyttig å vite hvordan man endrer tidsavbruddet for oppstartsmenyen for testing og validering.

For systemadministratorer er det praktiske budskapet at SysV er nå historie i systemd-baserte miljøerVi må anta at referansemodellen er enhetene .service, sammen med de andre enhetstypene (stikkontakter, tidtakere, mål osv.), og tilpasse interne verktøy, dokumentasjon og opplæring til denne virkeligheten.

Slik sjekker du om systemet ditt fortsatt er avhengig av SysV, og hva du skal gjøre

Før distribusjonen din hopper til systemd 260, anbefales det på det sterkeste Sjekk om du fortsatt har tjenester som er avhengige av klassiske skript.Den grunnleggende kontrollen innebærer å liste opp innholdet i /etc/init.d/, der disse åpningsskriptene tradisjonelt befinner seg:

ls /etc/init.d/

Hvis du ser skript der som ikke har tilsvarende i /etc/systemd/system eller på typiske enhetsruter, Det er et tydelig tegn på at det er arbeid som må gjøres.Det er ikke nok at skriptet eksisterer: det som betyr noe er om det fortsatt brukes til å starte eller stoppe tjenester i praksis.

Et annet nyttig triks er å se etter enheter generert fra SysV i tidligere versjoner av systemd . Selv om de ikke lenger finnes i versjon 260, kan dette være nyttig på nåværende systemer for å identifisere hva som gikk i stykker etter oppgraderingen.

systemctl list-unit-files | grep generated

Hvis den kommandoen viser tjenester merket som «generert», kommer de vanligvis fra eldre skript. Det anbefales å finne dem og planlegge erstatningen med native enheter , helst før versjonsoppgraderingen går i produksjon.

Når det gjelder migrasjon, innebærer en rask tilnærming midlertidig pakke SysV-skriptet inn i en systemd-enhet, spesifiserer i ExecStart y ExecStop skriptkall med argumenter start y stopDet er ikke den mest elegante løsningen, men den lar deg kjøpe tid mens du omskriver tjenesten på en mer idiomatisk måte.

På mellomlang sikt er den anbefalte handlingsplanen definere enheter som direkte kaller binærfilen eller hovedkommandoen til tjenesten, og utnytter moderne direktiver som Restart=Ressursbegrensninger, cgroup-integrasjon og avanserte sandkassealternativer, i stedet for å fortsette å stole på eldre skript fulle av spesifikk logikk.

Nye funksjoner og viktige tekniske endringer i SystemD 260

Selv om bortfallet av SysV får mye av oppmerksomheten, kommer systemd 260 med en god del nye funksjoner som dekker sikkerhet, nettverk, kjernen, containere, tjenesteportabilitet og til og med hvordan systeminformasjon presenteres. Det er en spesielt kompakt utgivelse når det gjelder interne endringer, designet for å fortsette å utnytte funksjonene til nyere kjerner.

Et av de viktige punktene er økningen i minimum støttet kjerneversjon . Systemd 260 kjører ikke lenger på kjerner så gamle som Linux 5.4: minimumsversjonen er nå Linux 5.10 . Videre anbefaler prosjektet selv å bruke minst Linux 5.14 , og bemerker at en 6.6-kjerne er det ideelle valget hvis du vil dra full nytte av alle funksjonene i denne utgivelsen.

Denne økningen i krav er ikke triviell, fordi den tvinger frem en forlatelse av distribusjoner eller miljøer som fortsatt er forankret i svært gamle kjerner , noe som er vanlig i visse bedrifts- eller innebygde distribusjoner. Til gjengjeld lar den systemd utnytte mer moderne kjerne-API-er, bedre utnytte cgroups v2, implementere nye planleggingspolicyer og innlemme sikkerhetsforbedringer som rett og slett ikke finnes i eldre kjerneserier.

Parallelt, en nytt felt FANCY_NAME= i filen /etc/os-releaseDette feltet ligner på det som allerede er kjent PRETTY_NAMEmen med den unike funksjonen at den kan inkludere ANSI-sekvenser og spesialtegn, som emojier. Systemd manager, systemd-hostnamed og verktøyet hostnamectl De kan vise denne verdien for å tilby en mer visuelt tiltalende presentasjon av fordelingen, spesielt i interaktive grensesnitt eller diagnostiske verktøy.

Utover kosmetiske forbedringer fortsetter systemd 260 å fordype bruken av Varlink som kommunikasjonsmekanisme og API, og utvider tilstedeværelsen på tvers av ulike komponenter. Dette forenkler programmatisk interaksjon med systemet, integrasjon med eksterne verktøy og generelt en mer strukturert måte å spørre og endre tilstanden til tjenester og ressurser på.

Det er også forbedringer på områder som Ressurshåndtering basert på cgroups v2, optimaliseringer av oppstartstiden bedre integrasjon med containere og virtuelle maskiner og forbedringer i logghåndtering gjennom journaldMange av disse endringene er imidlertid trinnvise og er mer merkbare i store eller svært raffinerte implementeringer.

Sikkerhet og isolasjon: TPM2, PrivateUsers og nye minnepolicyer

På sikkerhetsfronten gjør systemd 260 fremskritt på flere områder. For det første styrker den integrasjonen med TPM2 , Trusted Platform Module som finnes på mange moderne UEFI-hovedkort og -enheter. Disse brikkene brukes blant annet til å beskytte krypteringsnøkler og automatisere opplåsing av disker eller partisjoner ved oppstart.

spesifikt, udev har nå en ny innebygd funksjon kalt tpm2_idDenne funksjonen muliggjør automatisk uttrekking og identifisering av produsent og modell av tilkoblede TPM2-enheter i løpet av maskinvareoppdagelsesfasen. Denne informasjonen kan deretter brukes til mer spesifikke sikkerhetspolicyer, revisjonsskript eller lagerverktøy som trenger å vite nøyaktig hvilken TPM hver maskin har.

En annen viktig forbedring kommer med full implementering av PrivateUsers=fullDette er et isolasjonsalternativ som tillater tilordning av hele spekteret av bruker-ID-er i en tjeneste. Denne endringen eliminerer løsningen som brukes til å oppdage nestede forekomster av systemd basert på versjoner før 257, noe som forenkler virkemåten når containere eller nestede miljøer er til stede.

For de som ikke er kjent med det, er PrivateUsers en sandkassefunksjon som isolerer en tjenestes brukerområde , slik at prosesser i den ser et annet UID-kart enn vertssystemet. Dette styrker isolasjonen mot rettighetseskalering og bidrar til å begrense virkningen av sårbarheter på spesifikke tjenester.

I tillegg introduserer systemd 260 en nytt tjenestedirektiv kalt MemoryTHP=Dette lar deg kontrollere bruken av Transparent Huge Pages (THP-er) på enhetsnivå. THP-er kan forbedre ytelsen i visse minneintensive arbeidsbelastninger, men kan også forårsake problemer i andre. Å ha en spesifikk knapp for å aktivere, deaktivere eller justere oppførselen per tjeneste bidrar til å finjustere ytelsen mye mer effektivt uten å måtte bruke globale policyer.

Hva er nytt i systemd-logind, systemd-udevd og enhetstilgangskontroll

Innen økt- og enhetsadministrasjon legger systemd 260 til et interessant konsept kalt "xaccess", implementert i systemd-logind y systemd-udevdFrem til nå var logikken at "uaccess", som ga tillatelser til enheter (for eksempel et webkamera eller en inndataenhet) til brukere med forgrunnsøkter på den lokale konsollen.

Den nye xaccess-mekanismen lar deg delegere tilgang til bestemte enheter til spesielt merkede økter , selv når brukere ikke er fysisk til stede ved maskinen. Et typisk brukstilfelle er å gi tilgang til GPU-gjengivelsesenheter til lokale grafikkøkter som brukes av eksterne brukere som ikke har en tilknyttet fysisk plass.

Disse øktene konfigureres ved hjelp av miljøvariabel PAM XDG_SESSION_EXTRA_DEVICE_ACCESS=Dette spesifiserer hvilke tilleggsenheter som skal gis til økten under denne logikken. Dette utfyller uaccess og gir større fleksibilitet i scenarioer med eksternt skrivebord, lett virtualisering, delte laboratorier eller ekstern grafisk tilgang.

Samlet sett tar disse endringene sikte på å gi finere og mer dynamisk kontroll over hvem som har tilgang til hvilken maskinvare , uten å utelukkende stole på statiske grupper eller globale tillatelser. Dette er spesielt nyttig i flerbrukersystemer eller servere med delte GPU-er, der det er ønskelig med en balanse mellom sikkerhet og brukervennlighet.

systemd-networkd og ModemManager: Mobilnettverk og nye koblingsalternativer

Når det gjelder nettverk, bringer systemd 260 noen interessante forbedringer. Den mest bemerkelsesverdige er at systemd-networkd nå er integrert med ModemManager ved hjelp av "simple connect"-protokollen , som forenkler administrasjonen av mobile datatilkoblinger (3G, 4G, 5G) direkte fra systemd-konfigurasjonen.

For dette formålet er det innført en ny paragraf. i networkd-konfigurasjonsfilene, som aksepterer parametere som APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Dette lar deg deklarativt definere hvordan mobilforbindelsen skal opprettes, hvilke påloggingsinformasjoner som skal brukes og hvilken oppførsel som skal følges under roaming, blant andre aspekter.

Videre systemd-networkd utvider alternativene som er tilgjengelige i filene .link å konfigurere Ethernet-grensesnittBlant de nye direktivene er kapasitetstilpasninger som f.eks. ScatterGather=, ScatterGatherFragmentList=, TCPECNSegmentationOffload=, TCPMangleIdSegmentationOffload=, GenericReceiveOffloadList= y GenericReceiveOffloadUDPForwarding=som gir mye mer detaljert kontroll over nettverksoptimaliseringer på lavt nivå.

En annen bemerkelsesverdig forbedring er at systemd-networkds Varlink- og JSON-grensesnitt nå kan rapportere IP-adresser i menneskelig lesbart strengformat , i tillegg til det eksisterende heltallsarrayformatet. Dette forenkler ting betraktelig for eksterne verktøy og skript som spør etter nettverksstatus, og eliminerer tungvinte konverteringer.

Samlet sett forsterker disse endringene systemd-networkds posisjon som en nettverksadministrator som er i stand til å håndtere alt fra grunnleggende serverkonfigurasjoner til avanserte scenarier med mobilnettverk, finjustering av avlastning på moderne nettverkskort og integrasjon med eksterne API-er som ModemManager.

Containere, tjenesteportabilitet og nye verktøy

Innen lett virtualisering og containere introduserer systemd 260 flere betydelige forbedringer. En av de mest bemerkelsesverdige er tillegget av en ny kommandolinje kalt systemd-mstackdesignet for å fungere interaktivt med den nye «mstack»-funksjonaliteten.

Det karakteristiske mstack lar deg definere en OverlayFS ved å strukturere innholdet i en katalog .mstack/ etter en spesifikk spesifikasjon. Denne funksjonaliteten er en del av systemds innsats for å utvide containeriserings- og sandboksverktøyene sine, inkludert støtte for nedlasting og administrasjon av OCI-bilder gjennom systemd-importdI hovedsak gjør det det enklere å sette sammen filsystemlagstabler uten å stole utelukkende på eksterne verktøy.

Forbedringer er også innført i systemd-vmspawnVerktøyet er utviklet for å starte virtuelle maskiner på en integrert måte med systemd. Blant de nye funksjonene skiller følgende seg ut: støtte for registrering av maskiner i systemd-machined i brukerøkten, samt muligheten for å lage flyktige maskiner gjennom opsjonen --ephemeral, som forsvinner når arbeidet deres er ferdig.

Når det gjelder systemd-portabled , som er ansvarlig for å administrere bildebaserte bærbare tjenester, får den nå muligheten til å kjøre som en tjeneste på brukernivå . Dette betyr at brukere uten administratorrettigheter kan starte og administrere bærbare tjenester i sitt eget område, forutsatt at de bruker en tilstrekkelig nylig kjerne og at distribusjonen har aktivert dette alternativet.

Videre kan systemd-portabled nå generere en policy og fikse imaget som brukes for bærbare tjenester , og blokkere påfølgende modifikasjoner inntil det kobles til på nytt. Dette gir økt integritet og pålitelighet i miljøer der det er viktig å sikre at det kjørende imaget ikke endres stille.

Forbedringer av systemctl, CPU-planlegging og dokumentasjon for AI

I tjenesteadministrasjonsgrensesnittet, I denne versjonen inneholder systemctl et nytt verb kalt enqueue-marked, som internt kaller D-Bus-metoden EnqueueMarkedJobs()Denne funksjonen er utformet for å administrere jobber merket i systemd-køen mer presist, noe som gir mer kontroll til avanserte verktøy og automatiseringsskript.

Det er også en forbedring i CPU-planleggingsdelen: Direktiv CPUSchedulingPolicy= innrømmer nå verdien extsom aktiverer planleggeren SCHED_EXTDenne nye typen planlegging, som fortsatt er under utvikling i Linux-økosystemet, tilbyr mer fleksibilitet for spesielle arbeidsbelastninger og systemer som ønsker å eksperimentere med eksterne planleggingspolicyer.

En interessant, men viktig detalj er at prosjektet har lagt til spesifikk dokumentasjon for AI-agenter i systemd-repositoriet . Målet er å hjelpe AI-baserte roboter og skrapere med å bedre forstå koden, programmeringsstilen, retningslinjene for bidrag og prosjektets indre virkemåte, og dermed redusere vanlige misforståelser.

Relatert til dette, systemd-teamet Det krever at bidrag generert ved hjelp av AI har en åpenhetsetikett., som taggen co-developed-by i patchene, slik at det finnes bevis for at denne typen verktøy ble brukt i kodeutviklingen. Det er et eksempel på hvordan selv et så lavnivåprosjekt tilpasser seg virkeligheten med generativ AI.

Til slutt legger systemd-repart til støtte for å utføre grunnleggende integritetskontroller på krypterte volumer , noe som er nyttig i distribusjoner der du jobber med beskyttede partisjoner eller bilder og ønsker å validere statusen deres uten å ty til mer komplekse eksterne verktøy.

Innvirkning på distribusjoner og anbefalinger for brukere

Når det gjelder selve utrullingen av systemd 260, vil versjonen begynne å ankomme gradvis i større distribusjoner i løpet av første halvdel av året etter integreringen, vanligvis gjennom utviklingsgrener eller rullerende utgivelser. Distribusjoner som Arch Linux og openSUSE Tumbleweed tar vanligvis i bruk disse versjonene ganske raskt.

I motsetning til dette tar det vanligvis lengre tid for distribusjoner med fast syklus og LTS-utgaver å innlemme en hovedversjon av systemd, spesielt hvis endringen bryter kompatibiliteten med eldre teknologi som SysV init. Prosjekter som Fedora, for eksempel, oppdaterer vanligvis ikke hovedversjonen av systemd innenfor samme stabile utgivelsessyklus, men reserverer i stedet disse endringene for nyere versjoner av distribusjonen.

For den gjennomsnittlige desktopbrukeren føles det sjelden kritisk å oppdatere systemd , ettersom distribusjoner tar seg av å pakke alt slik at ingenting "bryter i stykker". Imidlertid finnes det alltid entusiaster som ønsker den nyeste versjonen for enhver pris, og i slike tilfeller er det best å velge rullerende utgivelsesdistribusjoner eller testarkiv, og akseptere risikoen.

I produksjonsmiljøer er anbefalingen klar: revidere eldre tjenester, gjennomgå skript i /etc/init.d/Testmigrering til native systemd-enheter i staging-miljøer og valider virkemåten grundig før distribusjon til kritiske maskiner. Hvis du hopper over dette trinnet, kan det føre til at tjenester ikke starter, feil i kryptert oppstartskjede eller nettverksproblemer i avanserte konfigurasjoner.

Kort sagt representerer systemd 260 et stort sprang mot et mer homogent og moderne Linux-økosystem , men det krever også at man forlater praksiser og komponenter som har eksistert i flere tiår. De som kommer i forkant og planlegger overgangen, vil ha en mye smidigere opplevelse når distribusjoner foretar overgangen og denne versjonen blir det nye fundamentet for systemene deres.