Om du inte har bott under en sten eller värre - du bryr dig inte mycket om hur Linux fungerar, du måste ha hört talas om systemd, det (relativt) nya initsystemet som ersätter den gamla och föråldrade SysV init som nyligen antagits av de flesta stora Linux distributioner.

Vad är ett init-system?

När din Linux-maskin startar kommer den först att köra någon "inbyggd" kod, laddad från BIOS eller UEFI först, följt av bootloader, som enligt sin konfiguration laddar en Linux-kärna. Kärnan laddar upp drivrutiner, och som dess första jobb startar init-processen, vilken är den första får PID (Process ID) 1 tilldelat den.

Ur användarens synvinkel ser det ut som att man startar upp nätverk och databaser etc., men i verkligheten finns det en ganska komplicerad process som äger rum under huven. Tjänsterna startas, stoppas och startas om, ofta parallella med varandra. Vissa drivs under olika privilegier än andra, servicestatuser rapporteras och loggas och många andra uppgifter utförs som gör att den olika delen av ditt system fungerar och kan interagera med sina användare och miljö.

Hur detta genomförs är emellertid långt ifrån enhetligt, och det här är verkligen det där allt slutar vara vanligt och väldefinierat.

Det gamla init systemet

Det init-system som används av de flesta vanliga Linuxdistroverna till sist var System V init (eller SysV init kortfattat), vilket har fått sitt namn form UNIX System V (uttalat "System Five"), det första kommersiellt tillgängliga UNIX-systemet. System V OS har haft ett specifikt sätt att köra sin init-process, och SysV init har hållit lojala mot detta under åren.

Och det har varit många år. UNIX System V släpptes ursprungligen 1983, vilket gjorde init SysV init en över 30 år gammal inställning för att starta Linux-maskiner.

Behovet av en förändring

Som det har noterats har SysV init varit föråldrad och lång tid för att ersättas. Några av anledningarna till detta är:

  • SysV init använder / sbin / init för att starta init-processen, men init själv har en mycket begränsad roll. init gör lite mer än att starta /etc/init.d/rc, enligt konfigurationen läst från / etc / inittab, som i sin tur kommer att köra skript för att göra det verkliga arbetet med init-processen. Detta, om inte explicit panelerats (som med startpar på Debian), kommer att hända i följd, ett skript som börjar efter det andra, vilket gör hela processen långsam, eftersom varje skript måste vänta på att den tidigare ska slutföras.
  • SysV init har inte tillgång till PID eller processerna som den har (indirekt) startat. Den läser endast PID och associerar dem med faktiska processer på ett omständligt, komplicerat sätt.
  • För systemadministratörer som försöker ändra miljön under vilken en viss process skulle börja är det ganska svårt med SysV init. (För att uppnå detta måste de modifiera init strcipt som är ansvarigt för att starta den givna processen.)
  • Det finns viss funktionalitet som är gemensam för varje tjänst som SysV inte implementerar, men varje process skulle behöva implementera sig istället, som att "demonera" sig själva (bli en systemdemon), vilket är en detaljerad och lång process. I stället för att genomföra dessa steg en gång kräver SysV varje process att göra jobbet själv.
  • SysV lämnar också vissa funktioner till externa program och vet ingenting om tjänster som startas av dem.

Allt ovanstående, och många fler designfel, eller snarare den föråldrade systemdesignen av SysV, har skapat ett modernt init-system för länge senast.

Ange systemd

Det fanns många försök att skapa ett alternativt init-system, vilket systemd bara är en av dem. Ubuntu brukade springa ett eget init system kallat upstart. Gentoo använder fortfarande OpenRC. Andra init-system inkluderar initng, busybox-init, runit och Mudur och andra.

Anledningen systemd är en tydlig vinnare är att den har antagits av de flesta stora distributioner. RHL och CentOS gick naturligtvis systemd-sättet, eftersom Fedora var den första distro som officiellt antog systemd 2011. Men systemd har verkligen blivit det enda init-systemet för att styra dem alla, när Debian 8 officiellt bytte till systemd, vilket ger Ubuntu och derivat med det, övervinna Canonicals (eller mer exakt Mark Shuttleworths) inledande motstånd mot systemd.

Hur är systemd annorlunda?

  • Systemd syftar till att tillhandahålla ett enda, centraliserat sätt att hantera init-processen från början till slut.
  • Det startar och stoppar processer och tjänster samtidigt som man håller reda på deras beroende. Det kan till och med starta en process som ett svar på ett annat processberoende.
  • Förutom att starta och stoppa processer under starttiden, kan Systemd också starta när som helst när systemet är uppe som svar på vissa utlösande händelser, t.ex. när en enhet är inkopplad.
  • Det kräver inte heller processer att demonisera sig själva. Till skillnad från SysV init kan systemd hantera tjänster som körs utan att behöva gå igenom den långa processen att bli daemoner.
  • Till skillnad från SysV init känner systemd och spårar alla processer, inklusive PID, och att få information om processer är mycket enklare för systemadministratörer under systemd.
  • Systemd stöder behållare som är i grunden isolerade service miljöer utan krav på virtuella maskiner. Detta har stor potential mot säkra och enklare systemdesigner i framtiden.

Naturligtvis är det bara några av de stora fördelarna. För en fullständig diskussion om systemds fördelar bör du läsa Debian 8s "Systemd Position Statement"

Kontrovers

Naturligtvis var systemd inte välkomnat av alla. Faktum är att många har och fortfarande gör sig rynka på det, kallar det monolitiskt och besvärligt, vissa till och med anklagar det för att gå "windows-vägen" för att ha allt centraliserat. Många hävdar att det inte är "Linux-vägen", och det verkar som om systemd inte överensstämmer med POSIX-standarderna, och om vi anser systemd som en verktygslåda (bortom bara binären) är det definitivt hugae.

Systemd är dock tydligt ett steg framåt, och medan det inte är perfekt, har mycket av kritiken den fått tagits upp av sin ursprungliga författare och utvecklare Lennart Poettering. Det är definitivt en välbehövlig framsteg och ett steg upp från det gamla init systemet. Linus Torvalds, skaparen av Linux, verkar inte tänka systemd för mycket, och vem ska vi argumentera med "Skaparen".

Slutsats

Efter att ha antagits av alla större Linux-distributioner, är systemd här för att stanna. Vad som helst systemadministratörer säger av vilken anledning som helst, är systemd framtiden för den vanliga Linux, huruvida enskilda användare tycker om det eller inte, vilket, med tanke på dess olika fördelar, inte nödvändigtvis är en dålig sak.

För den genomsnittliga användaren ger det snabbare uppstartstider och förmodligen mer tillförlitliga system, medan distribueringar i framtiden kan bli mer "kompatibla" med varandra. På användaränden kommer vi definitivt att dra nytta av den mer aktuella och samtida systemdesignen som det tar med på våra stationära datorer.