UPSTART ha un modello di avvio di qualsiasi lavoro disponibile quando si verifica l'evento. Confronta questo con SystemD, che inizia i processi che hanno tutti gli altri sistemi in esecuzione. La differenza principale è che Upstart è in attesa di eventi e SystemD sta coordinando le dipendenze. Entrambi i sistemi possono eseguire script regolari ed entrambi cercano di iniziare in parallelo. Poiché le differenze sono così piccole, gli script ascendenti di solito possono essere chiamati con un file di servizio Systemd. Possono anche, entrambi eseguire file di sistema invariati. In effetti, entrambi cercano una vecchia struttura di file Systemv per impostazione predefinita. La grande differenza è che Upstart cerca eventi definiti per iniziare qualsiasi cosa. Quindi, se vuoi aggiungere il tuo servizio, devi capire in quale contesto hai bisogno del tuo servizio. Di solito questo è facile poiché vorrai qualcosa che funziona, ad esempio, sul tuo desktop. Il desktop inizia con Event Runlevel 5, quindi lo si imposta nel tuo script. Per SystemD, al contrario, questo è il bersaglio grafico. In UpStart, hai anche altri eventi che puoi utilizzare come il montaggio, il montato e la richiesta di tastiera. Questi sono gestiti con SystemD attraverso prese e dBus.
Come si migrano gli script?
Hai tutti gli script di partenza in /etc /init, i loro nomi sono il nome del lavoro con un'estensione "conf". Gli script non sono eseguibili, indicano solo un eseguibile o più che dovrebbe essere eseguito. In ogni script di partenza, hai definito quale evento dovrebbe iniziare lo script e quando dovrebbe interrompere. Dovresti anche avere voci pre-avviamento e post-stop. Questi prepareranno l'ambiente e ripuliranno dopo l'esecuzione. Uno script di esempio è sotto
Descrizione "uno script semplice"
Inizia su Runlevel [2345]
Stop su Runlevel [06]
Respiraggio
env script_env_var = '/path/to/file.configurazione
chdir/path/to/script/
Script di Bash Exec.sh
La dichiarazione "Exec" dice cosa accadrà quando lo inizi manualmente. Le direttive di avvio e arresto definiscono quando lo script avverrà automaticamente. Come puoi vedere, puoi anche impostare la directory in cui verrà eseguito. Ci sono molti altri aspetti da aprire ma dovresti imparare a migrare.
Affinché questo script funzioni in SystemD, è necessario creare un file di servizio.
Unità]
Descrizione = uno script semplice
[Servizio]
Environment = script_env_var =/path/to/file.configurazione
WorkingDirectory =/path/to/script
ExecStart =/usr/bin/bash script.sh
Riavvia = sempre
[Installare]
WANTEDBY = Multi-utente.bersaglio
Qui puoi vedere che accadono le stesse cose ma con altre parole chiave. Il formato è semplice e al punto. Invece di avere runlevels, punta a quale target desidera il tuo script. Ciò evidenzia che SystemD riguarda la dipendenza e l'avvio di cose per l'ambiente specifico. Si noti inoltre che Execstart indica un percorso globale, non utilizza mai un percorso locale.
Dove si eccellono?
Upstart è stato progettato, per un comportamento parallelo ma è stato anche progettato per essere piccolo. Se lo trovi ancora ovunque, sarà in sistemi incorporati e Chromeos. Sì, Chromeos ce l'aveva. Il motivo è che è stato costruito in cima se Ubuntu fin dall'inizio, nel momento in cui Ubuntu ha avuto parte come sistema iniziale predefinito. Da allora Chromeos è passato a usare Gentoo come base.
Upstart è un argomento interessante ma principalmente storico. Potresti averne bisogno solo se ti imbatti in vecchi sistemi. L'alternativa più comune su Linux è ora Systemd. Se hai prenotazioni su SystemD, dovresti cercare altri sistemi minimi. Uno interessante è il succhiare, sinit. Supporta tre segnali e devi scrivere tutti gli script per esso o modificare gli script da qualcun altro. Questo può essere un esercizio interessante ma è utile solo se stai lavorando su un sistema molto minimo e specializzato.