Riavvio della rete tramite SSH


11

Sul server A, desidero inviare i seguenti comandi al server B tramite ssh.

service network stop
sleep 5
service network start

Il problema è perché ho emesso un "arresto" di rete, quindi anche la mia connessione SSH persa. Pertanto non posso eseguire i comandi successivi (sleep 5 e avvio della rete di servizio). Si noti che non riesco a utilizzare (riavvio della rete di servizio).

Qualcuno ha una soluzione / soluzione per questo?


5
perché non dovresti semplicemente usare l'opzione "riavvia"? perché interrompere separatamente e quindi iniziare?
SpacemanSpiff

Questa è l'unica soluzione che funziona con le moderne versioni di Debian e Ubuntu: serverfault.com/a/731120/10361 l'approccio al servizio è diventato "difettoso" in entrambe le distribuzioni negli ultimi anni.
sorin,

Risposte:


8

Se lo stai facendo in modo interattivo, perché non iniziare una screensessione? Sarebbe simile a questo:

screen

(inizia lo scren shell)

service network restart

(La sessione SSH si disconnette, ma il riavvio della rete continua nella sessione dello schermo)

(Aspetta qualche secondo)

(SSH torna nell'host al termine del riavvio)

screen -r

(Riconnetti allo schermo e verifica la presenza di errori)

IMHO, è sempre spaventoso riavviare un'interfaccia di rete da remoto. Cosa succede quando non torna indietro? Hai una console o altri mezzi nell'host se succede qualcosa di brutto?


1
Opero sempre attraverso screenquando lavoro su macchine remote. In caso di disconnessioni non pianificate può essere un salvavita. Anche avere più shell attive nella stessa sessione può essere utile. Potresti anche guardare anche tu tmux, non l'ho usato da solo, ma alcuni lo preferiscono screene la sua funzione principale offre gli stessi vantaggi.
David Spillett,

Non aggiornato: non funziona più: Failed to restart network.service: Unit network.service failed to load: No such file or directory.funziona: serverfault.com/a/731120/10361
sorin

@sorin Quale piattaforma? Questo presupponeva una variante RedHat.
Corey S.

systemctl restart networkingnon ha funzionato per me per qualche motivo nella tmuxsessione su Ubuntu Xenial. systemctl restart networkha funzionato su CentOS 7 (OpenVZ) nemmeno in tmux/ screensession. Senza perdere la connessione.
x-yuri,

5

I comandi esatti disponibili per farlo variano in base alla distribuzione Linux. L'opzione che è piuttosto standard è quella di pianificare e "a" lavoro per 5 secondi in futuro per riavviare la rete. Un altro è usare il nohupcomando.

echo "sleep 5; /etc/init.d/networking start" | at now
nohup sh -c 'sleep 5; /etc/init.d/networking start' &

Altre distribuzioni hanno il comando daemon per trasformare il programma risultante in un demone che non è più associato alla shell.


2

Un modo molto semplice per farlo è usare l'operatore e:

service network stop && sleep 5 && service network start

2
Preferirei interrompere la rete di servizio; dormire 5; avvio della rete di assistenza. Se uno qualsiasi dei comandi fallisce, eseguirà comunque il resto.
ghm1014

@ ghm1014 Sì, anche questa è un'ottima forma alternativa. In realtà, questo è ciò che uso di solito.
Jordan S. Jones,

1
Qual è il vantaggio rispetto service network restart?
Caleb,

Quando lo fai service network stopl'interfaccia si arresta, bashriceve SIGHUPe nessun altro comando viene eseguito. Mi sto perdendo qualcosa?
x-yuri,

1

Perché non inserirlo in uno script di shell ed eseguirlo tramite SSH?


Se lo inserisco in uno script, allora accadrà: sul server A, ssh server_B "execute_script". Ma non perderò ancora la mia connessione ssh da A a B? Spero di poter ancora preservare la connessione SSH ...
Carmen,

1
Non è possibile conservare la sessione SSH se si interrompe l'interfaccia di rete su un server.
Christopher Armstrong,

quindi, sembrerebbe che la mia sessione SSH si bloccherà mentre eseguo lo script di riavvio. C'è un modo per fingere questo? Per esempio. uscire dalla sessione ssh corrente e riconnetterti ad essa?
Carmen,

1
Sì, schermo, come notato dalla risposta di oggi.
mfinni,

Sì, non funzionerà. Il "riavvio della rete di servizio" in realtà chiama uno script di shell, ma internamente esegue solo stop e poi avvia. La sessione SSH viene interrotta dopo l'arresto e l'inizio non si verifica mai. Schermo o nohup è la risposta. Nota, l'ho fatto attraverso lo schermo e in realtà ha conservato la sessione SSH esistente per me (solo un po 'di ritardo), ma non sarà senza schermo. PERICOLO WILL ROBINSON: questo è un buon modo per perdere completamente l'accesso al sistema remoto (se perdi la connessione, non esegui il debug, sei solo bucato).
Jared,

1

Prova questo (magari installando cron se necessario):

$ at now+5min
at> service network stop
at> sleep 5
at> service network start
at> [control-D]

Quindi disconnettersi, attendere 6 minuti e accedere nuovamente


1
Lo atscheduler non è nel pacchetto cron sulla maggior parte delle distribuzioni, prova a cercare atdirettamente un pacchetto.
Caleb,

1

Funziona con Debian e Ubuntu moderni, mentre tutte le altre risposte non funzioneranno.

screen
sudo ifdown --exclude=lo -a && sudo ifup --exclude=lo -a

Tieni presente che può essere necessario un po 'di tempo per ripristinare l'interfaccia. Nel mio caso circa ~ 15 secondi poiché ho un legame.


0

Sembra che tu voglia uno schermo o un tmux . Ciò ti consentirà di preservare la sessione attraverso la perdita di una connessione di rete. Sono davvero molto utili, quasi tutte le mie sessioni terminali sono sullo schermo.


0
#!/bin/sh

# CentOS Linux release 7.4.1708 (Core) 

# 1. restart the network service
# 2. take the NIC [ens32] down
# 3. bring the NIC [ens32] up

systemctl restart network \
  && ifdown ens32 \
  && ifup ens32
#!/bin/sh

# Linux far-seer-01 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux

/etc/init.d/networking restart \
    && ifdown eth0 \
    && ifup eth0

per esempio

[root@localhost tmp]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:b3:74:da brd ff:ff:ff:ff:ff:ff
    inet 192.168.224.129/24 brd 192.168.224.255 scope global dynamic ens32
       valid_lft 1796sec preferred_lft 1796sec
    inet6 fe80::f06e:8b57:23fc:b25/64 scope link 
       valid_lft forever preferred_lft forever
[root@localhost tmp]# cat /etc/redhat-release 
CentOS Linux release 7.4.1708 (Core) 
[root@localhost tmp]# cat net.sh 
#!/bin/sh

# 1. restart the network service
# 2. take the NIC [ens32] down
# 3. bring the NIC [ens32] up

systemctl restart network \
  && ifdown ens32 \
  && ifup ens32
[root@localhost tmp]# sh net.sh 
Device 'ens32' successfully disconnected.
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/17)
$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
$ cat net.sh 
#!/bin/sh

# Linux far-seer-01 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux

/etc/init.d/networking restart \
    &&ifdown eth0 \
    && ifup eth0
$ sh net.sh 
[ ok ] Restarting networking (via systemctl): networking.service.
ifdown: interface eth0 not configured
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:0c:29:8a:67:72
Sending on   LPF/eth0/00:0c:29:8a:67:72
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPREQUEST of 192.168.224.128 on eth0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.224.128 from 192.168.224.254
DHCPACK of 192.168.224.128 from 192.168.224.254
bound to 192.168.224.128 -- renewal in 847 seconds.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.