Sono relativamente nuovo in Systemd e sto imparando la sua architettura.

In questo momento, sto cercando di capire come eseguire uno script di shell personalizzato. Questo script deve essere eseguito dopo il livello di rete è stato avviato.

Sto eseguendo Arch, utilizzando sia systemd che netctl.

Per testare, ho scritto un semplice script che esegue semplicemente ip addr list > /tmp/ip.txt . Ho creato il seguente file di servizio per questo script.

(/etc/systemd/system/test.service)
[Unit]
Description=test service

[Service]
ExecStart=/root/test.script

[Install]
WantedBy=multi-user.target

Ho quindi abilitato lo script con,

systemctl enable test

Al riavvio, lo script viene effettivamente eseguito, ma viene eseguito prima dell'avvio della rete. In altre parole, l'output in ip.txt non visualizza alcun indirizzo IPv4 assegnato all'interfaccia primaria. Al momento dell'accesso, l'indirizzo IPv4 è stato effettivamente assegnato e la rete è attiva.

Immagino di poter alterare il punto in cui lo script viene eseguito scherzando con WantedBy parametro, ma non sono sicuro di come farlo.

Qualcuno potrebbe indicarmi la giusta direzione?

Risposta accettata:

Sulle dipendenze di configurazione della rete di sistema

È molto facile influenzare l'ordinamento delle unità di systemd. D'altra parte devi stare attento a ciò che garantisce un'unità completata.

Configura il tuo servizio

Sui sistemi attuali,
ordina dopo network.target garantisce solo che il servizio di rete sia stato avviato, non che ci sia una configurazione effettiva. Devi ordinare dopo network-online.target e tiralo dentro per ottenerlo.

[Unit]
Wants=network-online.target
After=network-online.target

Per la compatibilità con i sistemi precedenti, potrebbe essere necessario ordinare anche dopo network.target.

[Unit]
Wants=network-online.target
After=network.target network-online.target

Questo è per il file di unità del tuo servizio e per systemd.

Implementazione nelle versioni correnti del software

Ora devi assicurarti che network-online.target funziona come previsto (o che almeno puoi utilizzare network.target ).

La versione corrente di NetworkManager offre il NetworkManager-wait-online.service che viene inserito da network-online.target e quindi al tuo servizio. Questo servizio speciale garantisce che il tuo servizio attenda fino a quando tutte le connessioni configurate per essere avviate automaticamente hanno esito positivo, negativo o scaduto.

La versione corrente di systemd-networkd blocca il servizio fino a quando tutti i dispositivi non sono configurati come richiesto. È più semplice in quanto attualmente supporta solo le configurazioni che vengono applicate all'avvio (più specificamente l'ora di avvio di `systemd-networkd.service).

Per completezza, il /etc/init.d/network servizio in Fedora, come interpretato dalle versioni correnti di systemd, blocca network.target e quindi blocca indirettamente network-online.target e il tuo servizio È un esempio di implementazione basata su script.

Se la tua implementazione, basata su daemon o basata su script, si comporta come uno dei servizi di gestione della rete di cui sopra, ritarderà l'avvio del servizio fino a quando la configurazione della rete non viene completata correttamente, non riesce per una buona ragione o scade dopo un tempo ragionevole fotogramma da completare.

Correlati:cercare file i cui percorsi contengono più parole senza un ordine specifico tra di loro?

Potresti voler controllare se netctl funziona allo stesso modo e quell'informazione sarebbe un'aggiunta preziosa a questa risposta.

Implementazioni in versioni precedenti del software

Non credo che vedrai una versione sufficientemente vecchia di systemd in cui questo non funzionerebbe bene. Ma puoi verificarlo almeno network-online.target esiste e che viene ordinato dopo network.target .

In precedenza NetworkManager garantito solo che almeno una connessione sarebbe stata applicata. E anche per farlo funzionare, dovresti abilitare il NetworkManager-wait-online.service esplicitamente. Questo problema è stato risolto a lungo in Fedora, ma è stato applicato solo di recente a monte.

systemctl enable NetworkManager-wait-online.service

Note sulle implementazioni network.target e network-online.target

Non dovresti mai aver bisogno di fare in modo che il tuo software dipenda da NetworkManager.service o NetworkManager-wait-online.service né altri servizi specifici. Invece, tutti i servizi di gestione della rete dovrebbero ordinarsi prima di network.target e facoltativamente network-online.target .

Un semplice servizio di gestione della rete basato su script dovrebbe completare la configurazione della rete prima di uscire e dovrebbe ordinarsi prima di network.target e quindi indirettamente prima di network-online.target .

[Unit]
Before=network.target

[Service]
Type=oneshot
ExecStart=...
RemainAfterExit=yes

Un servizio di gestione della rete basato su daemon dovrebbe anche ordinarsi prima di network.target anche se non è molto utile.

[Unit]
Before=network.target

[Service]
Type=simple
ExecStart=...

Un servizio che attende il completamento del demone dovrebbe ordinarsi dopo il servizio specifico e prima di network-online.target . Dovrebbe usare Requisite sul servizio demone in modo che si interrompa immediatamente se il rispettivo servizio di gestione della rete non viene utilizzato.

[Unit]
Requisite=...
After=...
Before=network-online.target

[Service]
Type=oneshot
ExecStart=...
RemainAfterExit=yes

Il pacchetto dovrebbe installare un collegamento simbolico al servizio in attesa nel wants directory per network-online.target in modo che venga richiamato dai servizi che desiderano attendere la rete configurata.

ln -s /usr/lib/systemd/system/... /usr/lib/systemd/system/network-online.target.wants/

Documentazione correlata

• http://www.freedesktop.org/software/systemd/man/systemd.special.html#network-online.target
• http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Note finali

Spero non solo di aver aiutato a rispondere alla tua domanda nel momento in cui l'hai posta, ma anche di aver contribuito a migliorare la situazione nelle distribuzioni upstream e Linux, in modo da poter ora dare una risposta migliore di quella possibile al momento della stesura di quella originale .