Sim, sim. A maioria dos serviços não é executada no nível de execução 1.
Título diz tudo. mas aqui está o cenário:
Irá para o "modo de usuário único" via "init 1" kill e desconectará minha sessão ssh de raiz?
Deve estar tudo bem. Embora o daemon do ouvinte SSH seja interrompido no nível de execução 1 na maioria das distros, as conexões existentes devem permanecer ativas e a rede não deve ser afetada. Eu não estaria fazendo isso sem ter algum tipo de console remoto conectado, no entanto - você nunca sabe quando um surto solar invasor vai aparecer e soltar suas conexões de rede por tempo suficiente para matar sua sessão SSH.
EDIT : Alguns testes indicam que, nos sistemas Debian, pelo menos, /etc/rc1.d/S30killprocs derrubará as conexões SSH existentes (porque está eliminando tudo). Eu estaria inclinado a knobble esse script temporariamente e fazer o seu trabalho à mão (evitando as conexões SSH) se eu fosse tentar fazer o que você quer fazer. Eu ainda prefiro usar um console remoto, no entanto.
/etc/init.d/ssh stop parou o ssh sem matar minha sessão ssh existente, mas init 1 fez ...
Desculpem-me depois de tanto tempo. Eu precisava responder a essa mesma pergunta. As respostas atuais estão erradas para minha caixa. Minhas descobertas são para instalação baseada no Centos 5.11.
A razão pela qual o cliente ssh é desconectado é porque init 1 faz algo como service network stop .
O que eu observo é que todas as interfaces de rede ficam inativas e são desconfiguradas.
ip a e ifconfig -a confirmam isso.
init 1 pára o processo do listener sshd .
Ele não interrompe o processo sshd child que mantém a sessão para o cliente conectado.
A sessão é interrompida porque a rede cai, ela não é morta.
Se eu trazer a rede de volta service network start no console com rapidez suficiente
então meus clientes permanecem conectados mesmo que a caixa esteja no nível de execução 1.
A questão menciona VPN. Se o servidor VPN que você está indo embora estiver na caixa onde você está executando init 1
então sim, você normalmente será desconectado porque o servidor VPN por padrão NÃO será executado no nível de execução 1.
Meu trabalho é levar o sistema para o nível de execução 1 sem perder sessões ssh, é configurar temporariamente os serviços necessários para continuar executando no nível de execução 1. Tudo baseado no Centos 5.11. YMMV. Aviso: não gostaria de confiar nisso para funcionar.
# 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
É isso. Isso me permite levar a caixa para o init 1 remotamente, permanecendo no controle.
Depois de terminar, não se esqueça de desfazer as alterações:
chkconfig --level 1 network off
chkconfig --level 1 openvpn off
chkconfig --level 1 sshd off