Init 1 da una sessione ssh remota (tramite VPN) interromperà la mia connessione ssh

Soluzione 1:

Sì, sì lo farà. La maggior parte dei servizi non viene eseguita nel runlevel 1.

Soluzione 2:

Dovrebbe essere OK. Mentre il demone del listener SSH viene arrestato nel runlevel 1 sulla maggior parte delle distribuzioni, le connessioni esistenti dovrebbero rimanere attive e la rete non dovrebbe essere influenzata. Non lo farei senza avere una sorta di console remota collegata, però:non sai mai quando arriverà un'eruzione solare canaglia che interromperà le tue connessioni di rete per juuuuust abbastanza a lungo da interrompere la tua sessione SSH.

MODIFICA :Alcuni test indicano che, almeno sui sistemi Debian, /etc/rc1.d/S30killprocs interromperà le connessioni SSH esistenti (perché sta uccidendo tutto). Sarei propenso a manipolare temporaneamente quello script e fare il suo lavoro a mano (evitando le connessioni SSH) se dovessi provare a fare quello che vuoi fare. Tuttavia, preferirei comunque utilizzare una console remota.

Soluzione 3:

Mi dispiace parlare dopo così tanto tempo. Avevo bisogno di una risposta alla stessa domanda. Le risposte attuali sono sbagliate per la mia macchina. I miei risultati riguardano l'installazione basata su Centos 5.11.

1. Il motivo per cui il client ssh viene disconnesso è perché init 1 fa qualcosa come service network stop .Quello che osservo è che tutte le interfacce di rete si interrompono e vengono deconfigurate.ip a e ifconfig -a conferma questo.

2. init 1 interrompe sshd processo di ascolto. Non si ferma sshd processo figlio che mantiene la sessione per il client connesso. La sessione ssh alla fine viene interrotta a causa del timeout TCP perché la rete si interrompe, la sessione ssh non viene terminata. Se ripristino la rete service network start alla console abbastanza velocemente, quindi i miei client rimangono connessi anche se la scatola è al runlevel 1.

3. La domanda menziona VPN. Se il server VPN a cui stai andando si trova sulla casella in cui stai facendo init 1 allora sì, normalmente verrai disconnesso perché il server VPN per impostazione predefinita NON funzionerà al runlevel 1.

Il mio lavoro per portare il sistema al runlevel 1 senza perdere sessioni ssh, consiste nel configurare temporaneamente i servizi richiesti per continuare a funzionare al runlevel 1. Tutto basato su Centos 5.11.YMMV.Disclaimer: Non vorrei fare affidamento su questo per funzionare.

    # keep network interfaces up
    chkconfig --level 1 network on
    # if you are connecting though VPN e.g. OpenVPN running on same server
    chkconfig --level 1 openvpn on
    # While at it, might as well keep SSHD running, so you can reconnect
    chkconfig --level 1 sshd on

    init 1
    # look for messages that indicate that run level has been reached
    tail -F /var/log/messages
    # Aug 31 14:21:19 pabx-demo kernel: Kernel logging (proc) stopped.
    # Aug 31 14:21:19 pabx-demo kernel: Kernel log daemon terminating.
    # Aug 31 14:21:20 pabx-demo exiting on signal 15

Ecco fatto. Questo mi permette di prendere box per init 1 da remoto mantenendo il controllo.

Dopo aver finito, non dimenticare di annullare le modifiche:

chkconfig --level 1 network off
chkconfig --level 1 openvpn off
chkconfig --level 1 sshd off