Perché dovrei usare "servizio sshd reload" preferibilmente a "servizio sshd restart"?

Question

Dai miei test su Linux, sembra che

service sshd reload

• funziona solo quando sshd è già in esecuzione
• Arresta sshd se il file sshd_config ha problemi
• Restituisce il codice di errore 0, anche se il il file sshd_config ha problemi

service sshd restart

• funziona indipendentemente dal fatto sshd è già in esecuzione
• Arresta sshd se il file sshd_config ha sintassi non valida o altri problemi
• restituisce il codice diverso da zero errore se il file sshd_config ha problemi

Capisco che stanno eseguendo diverse operazioni, ma mi sembra una cosa da poco che dovrei sempre usare service sshd restart. Ci sono motivi per cui service sshd reload è preferibile in alcune situazioni?

Answer 1

Quando si esegue lo sshd comando servizio dove opt potrebbe essere Ricarica/riavviarlo in realtà esegue un programma con un ambiente modificato proprio come questo:

env -i PATH="$PATH" TERM="$TERM" "${SERVICEDIR}/${SERVICE}" ${OPTIONS} 

esempio:

env -i PATH=/sbin:/usr/sbin:/bin:/usr/bin TERM=xterm /etc/init.d/sshd reload 

Il comando sshd fa quasi la stessa cosa in entrambi i casi (riavvio/ricarica):

ricarica: tenta di interrompere il processo inviando un segnale HUP e, come puoi vedere sullo snipet, ha bisogno del PID del processo per farlo. (Funziona indipendentemente dal fatto che sshd è già in esecuzione)

reload() 
    { 
     echo -n $"Reloading $prog: " 
     if [ -n "`pidfileofproc $SSHD`" ] ; then 
      killproc $SSHD -HUP 
     else 
      failure $"Reloading $prog" 
     fi 
     RETVAL=$? 
     echo 
    } 

riavvio: Sarebbe solo fare lo stesso, come se si dovesse eseguire uno stop> iniziare.

restart() { 
     stop 
     start 
    } 

    start() 
    { 
     [ -x $SSHD ] || exit 5 
     [ -f /etc/ssh/sshd_config ] || exit 6 
     # Create keys if necessary 
     if [ "x${AUTOCREATE_SERVER_KEYS}" != xNO ]; then 
       do_rsa1_keygen 
       do_rsa_keygen 
       do_dsa_keygen 
     fi 

     echo -n $"Starting $prog: " 
     $SSHD $OPTIONS && success || failure 
     RETVAL=$? 
     [ $RETVAL -eq 0 ] && touch $lockfile 
     echo 
     return $RETVAL 
    } 

    stop() 
    { 
     echo -n $"Stopping $prog: " 
     if [ -n "`pidfileofproc $SSHD`" ] ; then 
      killproc $SSHD 
     else 
     failure $"Stopping $prog" 
     fi 
     RETVAL=$? 
     # if we are in halt or reboot runlevel kill all running sessions 
     # so the TCP connections are closed cleanly 
     if [ "x$runlevel" = x0 -o "x$runlevel" = x6 ] ; then 
      trap '' TERM 
      killall $prog 2>/dev/null 
      trap TERM 
     fi 
     [ $RETVAL -eq 0 ] && rm -f $lockfile 
     echo 
    } 

Answer 2

solo per citarne: come negli esempi precedenti gente è abituata sshd, che è il demone, il servizio è ssh. La linea corretta dovrebbe essere:

service ssh reload 

Answer 3

Penso che questo "ricaricare" potrebbe essere utilizzato in uno script di shell per il multi servizi per il recupero di stato iniziale, in questo caso non sapevamo se un servizio è in esecuzione o meno , quindi lasciamo che tutti questi servizi "ricarichino".

Se in questo caso viene utilizzato il "riavvio", alcuni di quei servizi che non abbiamo utilizzato inizieranno.

Solitamente per problemi di debug (o modifica) su singolo servizio, vogliamo che questo servizio come "sshd" per iniziare, "riavvio" dovrebbe essere migliore per non abbiamo bisogno di controllare se questo servizio è in esecuzione con successo o meno.

Answer 4

Alcune app, inclusi diversi server Web, supportano il ricaricamento della configurazione senza riavviare. In questo caso, reload sarebbe il modo migliore per segnalarli.

Come un caso di utilizzo, sarebbe bello se sshd effettivamente ha fatto il supporto ricaricare la configurazione senza influire sulle connessioni esistenti. Ciò consentirebbe di verificare la nuova configurazione senza perdere la connessione ssh corrente (ad esempio quando si modificano le autorizzazioni, per assicurarsi di poter ancora accedere).

Ulteriori approfondimenti: List of all systemd unit actions