Da Upstart først ble unnfanget av kanonisk, var det rådende systemet fremdeles sysvinit, som startet alt i rekkefølge og mer eller mindre stoppet etter det. Det sørget for at systemet også stengte grasiøst. Dette gjorde det nødvendig å ha andre løsninger for varmt pluggende enheter som USB-pinner og lignende. Hovedideen fra designerne var å gjøre den hendelsesdrevet, dette gjorde det enkelt å håndtere de nevnte hot-plugging-hendelsene. Upstart kan også kjøre umodifiserte sysvinit -skript, slik at du kan migrere til upstart med bare en installasjon. Dette prosjektet er bare i vedlikeholdsmodus, så bruk dette innlegget som et interessant stykke. Du kan komme inn i dette systemet i gamle oppdaterte systemer.

Hvordan skiller upstart seg?

Upstart har en modell for å starte enhver tilgjengelig jobb når arrangementet skjer. Sammenlign dette med SystemD, som starter prosesser som har alle de andre systemene som kjører. Hovedforskjellen er at Upstart venter på hendelser og SystemD koordinerer avhengigheter. Begge systemene kan kjøre vanlige skript og begge prøver å starte parallelt. Fordi forskjellene er så små, kan upstart -skript vanligvis bare kalles med en SystemD -tjenestefil. De kan også, begge kjøre uendrede SystemV -filer. Faktisk ser begge etter en gammel systemv -filstruktur som standard. Den store forskjellen er at Upstart ser etter definerte hendelser for å starte noe. Så hvis du vil legge til din egen tjeneste, må du finne ut i hvilken sammenheng du trenger tjenesten din. Vanligvis er dette enkelt siden du vil ha noe som for eksempel kjører på skrivebordet ditt. Skrivebordet starter med arrangementet RunLevel 5, så du angir det i skriptet. For SystemD er dette derimot det grafiske målet. I Upstart har du også andre hendelser du kan bruke, for eksempel montering, montert og tastaturforespørsel. Disse håndteres med SystemD gjennom stikkontakter og DBU -er.

Hvordan migrerer du skript?

Dere har alle upstart -skript i /etc /init, navnene deres er jobbnavn med en "Conf" -utvidelse. Skriptene er ikke kjørbare, de peker bare på en kjørbar eller mer som bør kjøres. I eventuelle upstart -skript har du definert om hvilken hendelse manuset skal starte og når det skal stoppe. Du bør også ha start- og post-stop-oppføringer. Disse vil forberede miljøet og rydde opp etter utførelse. Et eksempelskript er nedenfor

Beskrivelse "Et enkelt manus"
Start på RunLevel [2345]
Stopp på RunLevel [06]
respawn
env script_env_var = '/path/to/file.konfigurasjon '
chdir/sti/til/manus/
Exec Bash -skript.sh

"Exec" -erklæringen sier hva som vil skje når du starter det manuelt. Start- og stoppdirektivene definerer når skriptet starter automatisk. Som du ser, kan du også angi katalogen den vil kjøre inn. Det er mange flere aspekter å upstart, men du bør lære å migrere ut.

For at dette skriptet skal fungere i SystemD, må du opprette en tjenestefil.

Enhet]
Beskrivelse = et enkelt skript
[Service]
Miljø = script_env_var =/sti/til/fil.konfigurasjon
WorkingDirectory =/Path/To/Script
ExecStart =/usr/bin/bash -skript.sh
Start på nytt = alltid
[Installere]
WantedBy = Multi-User.mål

Her kan du se at de samme tingene skjer, men med andre nøkkelord. Formatet er enkelt og til poenget. I stedet for å ha runlevels, peker du på hvilket mål vil ha skriptet ditt. Dette fremhever at SystemD handler om avhengighet og å starte ting for det spesifikke miljøet. Legg også merke til at execstart peker på en global vei, den bruker aldri en lokal vei.

Hvor utmerker det seg?

Upstart ble designet, for parallell oppførsel, men den var også designet for å være liten. Hvis du finner dette hvor som helst fremdeles, vil det være i innebygde systemer og kromoer. Ja, Chromeos hadde det. Årsaken er at den ble bygget på toppen hvis Ubuntu fra begynnelsen, på det tidspunktet da Ubuntu hadde Upstart som standard innledende system. Chromeos har siden gått videre til å bruke gentoo som base.

Konklusjon

Upstart er et interessant tema, men hovedsakelig historisk. Du trenger det bare hvis du støter på gamle systemer. Det vanligste alternativet på Linux er nå systemd. Hvis du har reservasjoner angående SystemD, bør du se etter andre minimale systemer. En interessant er den sugerløs, sinit. Den støtter tre signaler, og du må skrive alle skript for det selv, eller endre skriptene fra noen andre. Dette kan være en interessant øvelse, men er bare nyttig hvis du jobber med et veldig minimalt og spesialisert system.