How to Reliably Restart Remote Network Service via SSH Without Losing Connection


3 views

When administering remote Linux servers, we often encounter situations where we need to restart network services. The standard approach would be:

ssh admin@serverB 'service network stop && sleep 5 && service network start'

However, this fails because stopping the network service immediately terminates our SSH connection, leaving the server inaccessible with no way to bring the network back up.

Before presenting the solution, let's examine why common alternatives fail:

# Option 1: Using restart command (not always available)
service network restart
# Many Linux distributions don't support this
# Option 2: Background process (still gets terminated)
ssh admin@serverB 'service network stop & sleep 5; service network start'
# The ampersand doesn't solve the connection drop issue

The most robust method uses nohup to detach the process from the SSH session:

ssh admin@serverB 'nohup bash -c "service network stop; sleep 5; service network start" &'

Breaking this down:

  • nohup makes the command immune to hangup signals
  • bash -c executes the commands as a single unit
  • The trailing & backgrounds the process

For production environments, we should add proper error handling:

ssh admin@serverB 'nohup bash -c "
if service network stop; then
    sleep 5
    if ! service network start; then
        echo \"Network failed to start\" > /var/log/network_restart.log
        exit 1
    fi
else
    echo \"Network failed to stop\" > /var/log/network_restart.log
    exit 1
fi" &'

If you have tmux or screen available, this provides another reliable approach:

ssh admin@serverB 'tmux new-session -d -s network_restart \
"service network stop && sleep 5 && service network start"'

Advantages of this method:

  • Session persists after SSH disconnect
  • You can reattach to monitor progress
  • Output is captured in the session

After initiating the restart, you can verify success with:

# Wait 30 seconds then attempt to reconnect
sleep 30 && ssh admin@serverB 'service network status'

Or check the log file if using our error-handling example:

ssh admin@serverB 'tail /var/log/network_restart.log'

For systems using systemd, we have more elegant options:

ssh admin@serverB 'systemctl restart NetworkManager.service'
# Or for network interfaces specifically:
ssh admin@serverB 'nmcli connection down eth0 && sleep 5 && nmcli connection up eth0'

When administering Linux servers remotely, we often encounter this frustrating scenario:

ssh admin@serverB "service network stop && sleep 5 && service network start"

The moment network stop executes, your SSH session terminates abruptly because:

  • The network interface goes down
  • TCP connections including SSH are dropped
  • No way to execute subsequent commands

While service network restart seems like the obvious solution, there are valid cases where separate stop/start is needed:

# When you need custom delay between operations
# When troubleshooting specific init scripts
# When working with legacy systems using older init systems

1. Using nohup with Command Chaining

The most reliable method I've found:

ssh admin@serverB "nohup bash -c 'service network stop; sleep 10; service network start' >/dev/null 2>&1 &"

Key points:

  • nohup prevents SIGHUP from terminating the process
  • Background execution (&) allows SSH to exit
  • Output redirection avoids hanging

2. Systemd-specific Alternative

For modern systems using systemd:

ssh admin@serverB "systemctl restart NetworkManager.service"

Or with delayed execution:

ssh admin@serverB "systemctl stop NetworkManager && sleep 5 && systemctl start NetworkManager"

3. The Screen/Tmux Approach

For complex multi-step network operations:

ssh admin@serverB
tmux new -s networkfix
service network stop
# [network goes down, reconnection happens]
ssh admin@serverB
tmux attach -t networkfix
service network start

After any network restart, always verify:

ssh admin@serverB "ip a; systemctl status network"

When these methods fail:

  • Check for firewalls blocking SSH on restart
  • Verify SSH server starts before networking completes
  • Consider console access as fallback