Debian systemd network-online.target non funziona?

24

Sto cercando di creare un servizio systemd su Debian Jessie. Ho bisogno che inizi dopo che network-online.targetè stato raggiunto.

Il problema si presenta network-online.targetcontemporaneamente network.targete al momento le mie interfacce non sono ancora configurate, ma ho appena avviato la query DHCP.

Sembra che questo problema sia specifico di Debian perché usa una configurazione di rete legacy.

Come aggirare questo problema o come far network-online.targetfunzionare?

debian systemd systemd-networkd

— 10robinho
fonte

Qual è l'output di systemctl list-dependencies network-online.target? Inoltre, notare che network-online.targetpotrebbe non essere necessario significare che esiste un accesso a Internet. Vedi questa pagina per maggiori informazioni.

— saiarcot895,

L'output del comando è: network-online.target ● └─systemd-networkd-wait-online.service ho già letto quella pagina, ho capito il concetto di base lì, ma è comunque molto strano non avere un punto definito da cui possano iniziare i servizi critici di rete. Almeno potrebbe attendere una corretta assegnazione DHCP.

— 10robinho,

Ciò significa che network-online.targetdipende solo dal systemd-networkd-wait-online.servicedire che è pronto. Non dipende dal fatto che NetworkManager affermi che è pronto, né verifica che ifuptutti i collegamenti siano stati attivati correttamente (se usi questo metodo per configurare la tua rete). Ubuntu, d'altra parte, dipende da ifupe NetworkManager, ma non per systemd-networkd-wait-online..

— saiarcot895,

Come stai configurando la tua rete: file /etc/network/interfacessystemd .networko NetworkManager?

— saiarcot895,

Hai ragione network-online.targete network.targetvengono attivati subito dopo ifup. Uso debian default, quindi /etc/network/interfacescon indirizzo dhcp. Sembra che networkd possa essere la soluzione migliore, ma non è semplice da implementare.

— 10robinho,

18

Dal momento che stai usando /etc/network/interfaces, avrai bisogno di un servizio systemd per monitorare lo stato di ciascuna interfaccia. Controlla se hai /lib/systemd/system/ifup-wait-all-auto.service(installato dal ifupdownpacchetto in Ubuntu 15.04). In caso contrario, crea /etc/systemd/system/ifup-wait-all-auto.servicee incolla quanto segue:

[Unit]
Description=Wait for all "auto" /etc/network/interfaces to be up for network-online.target
Documentation=man:interfaces(5) man:ifup(8)
DefaultDependencies=no
After=local-fs.target
Before=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutStartSec=2min
ExecStart=/bin/sh -ec '\
  for i in $(ifquery --list --exclude lo --allow auto); do INTERFACES="$INTERFACES$i "; done; \
  [ -n "$INTERFACES" ] || exit 0; \
  while ! ifquery --state $INTERFACES >/dev/null; do sleep 1; done; \
  for i in $INTERFACES; do while [ -e /run/network/ifup-$i.pid ]; do sleep 0.2; done; done'

[Install]
WantedBy=network-online.target

Questo è il file di servizio presente su un sistema Ubuntu 15.04, ma con la [Install]sezione aggiunta per rendere le cose un po 'più facili. Spero che il comportamento di ifupUbuntu 15.04 sia lo stesso di ifupDebian Jessie. In caso contrario, saranno necessarie alcune modifiche (in particolare con l'ultima riga).

Quindi, corri sudo systemctl enable ifup-wait-all-auto.service. Dopo aver riavviato il computer, dovresti vedere che network-online.targetviene raggiunto dopo che le interfacce sono state visualizzate (almeno).

— saiarcot895
fonte

Grazie per lo sforzo, fammi provare ora e ti darò un feedback

— 10robinho,

Ho finito per eseguire la versione leggermente modificata ExecStart = /bin/bash -c 'while [ -z "$(hostname -I)" ]; do sleep 1; done;'. Dipende hostnameda verificare se l'indirizzo IP è stato assegnato.

— luka5z,

Non provare a girare il dottore. non è perché sta usando / etc / network / interfaces. È perché systemd è così sciatto e il lavoro viene scaricato su ogni utente invece di risolvere il problema in cui è stato creato.

— Florian Heigl,

1

prima ifup-wait-all-auto.serviceè stato rilasciato nella ifupdownversione 0.8.5ubuntu1: ”Rilascia ifup-wait-all-auto.service. Questo è stato implementato in modo più elegante creando network-online.target Wants = networking.service direttamente. “ [

— Log delle modifiche

0

Attenzione! L'ho appena capito su una Raspbian Jessie: rimuovi TUTTE le righe commentate nelle interfacce / etc / network e funzionerà! Sembra essere un bug di analisi =) Nel mio caso specifico ho lasciato un commento iface eth0 inet dhcpe me ne sono appena dimenticato eoni fa, ma dopo l'aggiornamento a Raspbian Jessie e la ricostruzione di un kernel ho un comportamento molto strano: ha usato DHCP e si è rifiutato di fare un tuning da / etc / network / interfaces. Quindi l'ho rimosso da qualsiasi commento - solo linee di lavoro, riavvio - e funziona! NESSUNA PATCH DI SCRIPT / MODIFICA NECESSARIA!

— Alexey Vesnin
fonte

Interestin, devo provare questo. Anche se non ha molto senso :)

— 10robinho,

2

Hai qualche riferimento al riguardo? Mi piacerebbe leggere le segnalazioni di bug e vedere il codice di errore.

— ʇsәɹoɈ

No, non ho aperto un ticket bug. Per riprodurlo basta aggiungere alcuni commenti nel tuo /etc/network/interfacesfile - si accenderà se è ancora lì.

— Alexey Vesnin,

0

Per https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ il modo consigliato per avviare un servizio DOPO che la rete è di livello è utilizzare " network-online.target " nelfile .service :

 "After=network-online.target"
 "Wants=network-online.target"

Tuttavia dopo aver usato " network-online.target " e il mio servizio non è riuscito perché la rete non era completamente a livello, ho scoperto che c'era un bug ( https://github.com/coreos/bugs/issues/1966 ): non garantito essere al 100% infallibile.

In effetti, dove strumenti di configurazione della rete dinamica come " NetworkManager vengono utilizzati " come in questo caso, lo stato della rete non può mai essere preciso o prevedibile al 100%. Apparentemente dal link che descrive il bug, " network-online.target " può comportarsi in modo incoerente a seconda delle diverse applicazioni con cui viene utilizzato.

Soluzione alternativa :
è necessario analizzare l'ordine di avvio dei servizi e utilizzarne uno che inizia dopo " network-online.target ":

 systemd-analyze plot > /home/pi/graph.svg

Questo è un processo iterativo che modifica gli obiettivi in modo incrementale in servizi successivi e successivi fino a quando non trovi quello che garantisce che la rete sia a livello e che il tuo servizio inizi senza errori. Nel mio caso ho persino dovuto inserire sleep 10nel mio script il servizio SystemD chiamato.

— F1Linux
fonte

0

Una volta ho trovato una risposta su Github che l'ha risolto cercando continuamente di eseguire il ping di un server. Solo quando arriva il ping, il servizio continua:

[Service]
ExecStartPre=/bin/sh -c 'until ping -c1 google.com; do sleep 1; done;'
ExecStart=<your command>

Ho sostituito google.comcon il mio server perché il mio script principale doveva connettersi al mio server.

— Sam
fonte