Access Your Linode After Maintenance

Traducciones al Español
Estamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.

This guide has been deprecated and is no longer being maintained.

Please refer to the updated version of this guide.

Create a Linode account to try this guide with a $ credit.
This credit will be applied to any valid services used during your first  days.

If you are having issues accessing your Linode after maintenance has been applied to your host, here are a few troubleshooting steps to follow.

Is the Linode Powered On?

Confirm that the Linode is fully booted.

  1. Log in to the Linode Manager. On the Linodes page, under the Status column look for Running as the status of your Linode.

  2. If your Linode’s status displays Powered Off, click on the Dashboard link. Under the Dashboard section, click the grey Boot button to boot your Linode.

  3. Once the Linode has booted, its Server Status should display Running.

Restore SSH Access with Lish

If you have ensured that your Linode is booted, but do not have SSH access, you can use Lish to access your Linode via SSH and continue any necessary troubleshooting steps.

  1. Log into the Linode Cloud Manager and click on your Linode to open the Dashboard.

  2. Click on the Launch Console link. This launches the Lish Console via your browser window and you will be prompted to enter your Linode user and password.

    If you have trouble logging in with your root password, consider resetting the root password to rule out any password issues.

The Using the Lish Console contains more information on Lish.

Lish is an out-of-band management tool, so you can use your root login credentials, if needed.

Network Helper

Your Linode’s Network Helper automatically creates a static networking configuration on your Linode at boot. This means you don’t have to worry about altering your network configuration. To enable Network Helper:

  1. Log in to the Linode Manager and click on the Dashboard link for your Linode.

  2. Under Configuration Profiles, click the Edit link for the profile you want to adjust.

  3. On the Configuration Profile page, scroll to the Filesystem/Boot Helpers section and select Yes next to Auto-configure Networking.

  4. Click Save Changes, then reboot your Linode.

For more information, refer to the Network Helper guide.

Checking Interfaces/Networking

Once you’ve rebooted your Linode and have SSH access via Lish, determine if a Linode’s networking interfaces have been configured and brought up properly.

  1. Display the contents of the network interfaces file to view the configuration applied by Network Helper:

    Debian / Ubuntu

    cat /etc/network/interfaces


    cat /etc/sysconfig/network-scripts/ifcfg-eth0
  2. Check the status of the networking service on the Linode:

    Debian / Ubuntu

    systemctl status networking.service


    systemctl status -l  network.service
  3. To display all available Ethernet interfaces, IP addresses and property information:

     ip a
  4. List all of the route entries in the Kernel:

     ip r

Failed to Raise Network Error Message Troubleshooting

This section provides troubleshooting steps for specific errors you may encounter if the status of networking.service reports the following error:

[FAILED] Failed to start Raise network interfaces. See 'systemctl status networking.service' for details.

Was Your Interface Renamed?

When viewing the output of the interfaces file, if you notice your interfaces have been renamed to something other than eth0 (for example, ensp) this may be due to the latest version of systemd (226-1+ as of writing this guide). The latest version of systemd uses Predictable Network Interface Names.

  1. Disable the use of Predictable Network Interface Names with the following command:

    ln -s /dev/null /etc/systemd/network/
  2. Reboot your Linode for the changes to take effect.


  1. Check the status of the networking service on the Linode:

    sudo systemctl status networking.service -l
  2. The journalctl command can be used to query the contents of the systemd journal. This command will show the last 20 messages for the networking unit:

    sudo journalctl -u networking --no-pager | tail -20

    If the networking journal entry output contains a similar line, there could be a firewall issue on the Linode:

    Apr 06 01:03:17 xlauncher ifup[6359]: run-parts: failed to exec /etc/network/if- Apr 06 01:03:17 xlauncher ifup[6359]: run-parts: /etc/network/if-up.d/iptables e
  3. Move the iptables file to your home directory to temporarily disable the firewall:

    sudo mv /etc/network/if-up.d/iptables ~
  4. The ifup -a and ifdown -a commands will execute all scripts defined within the /etc/network/if*.d directories and bring the network interface down and then back up:

    ifdown -a && ifup -a
  5. Manually reenable the firewall and restore the moved iptables file after running these commands.

Use the full output of the sudo systemctl status networking.service -l to determine if the failure is happening when executing the etc/network/if-up.d/iptables file or within the rules of the iptables. The exec codes provided in the output will help you determine which of the two is the source of failure.

See the Control Network Traffic with Iptables guide for more information.


If you have SendMail installed, and saw the Failed to start Raise network interfaces error message, the following commands will help you troubleshoot the issue.

  1. Check the status of the networking service on the Linode:

    sudo systemctl status networking.service -l
  2. The ifup -a and ifdown -a commands will execute all scripts defined within the /etc/network/if*.d directories.

    ifdown -a && ifup -a

    If after running those commands you encounter the following error, a SendMail version update may be at fault.

    /etc/network/if-up.d/sendmail: 44: .: Can't open /usr/share/sendmail/dynamic run-parts: /etc/network/if-up.d/sendmail exited with return code 2

    This issue is related to a known SendMail bug found in SendMail version 8.15.2-8 and fixed in version 8.15.2-9. /etc/network/if-up.d/sendmail calls for /usr/share/sendmail/dynamic, which may not exist as a result of the broken SendMail update or SendMail not cleaning itself up after removal of Sendmail.

  3. To resolve the described SendMail issue, move the sendmail file to the home directory:

    sudo mv /etc/network/if-up.d/sendmail ~
  4. The ifup -a and ifdown -a commands will execute all scripts defined within the /etc/network/if*.d directories and bring the network interface down and then back up:

    ifdown -a && ifup -a
    • If you do not need SendMail, you can remove the SendMail if-up script from the home directory:

        rm ~/sendmail
    • If you need to continue using SendMail, consider reinstalling SendMail or do further research before modifying the SendMail if-up script.

Did All of your Services Start After Reboot?

When troubleshooting it is helpful to determine which services are running on your Linode.

  1. Run ss with the following options to view all network connections with their corresponding address, state, PID and name:

    sudo ss -atpu
  2. To display all units of type service that the system manager knows about:

    systemctl list-units --type=service
  3. To view a list of the state of all the services controlled by the system:

    service --status-all

Restarting Services

If you expect a service to be running, but it is displayed as not running try restarting the service with the sudo systemctl restart servicename command, replacing servicename with the name of the service you’d like to restart. Below is a list of commands to restart the most common services on a Linode:


  • Debian and Ubuntu:

      sudo systemctl restart apache2
  • Fedora and CentOS:

      sudo systemctl restart httpd


sudo systemctl restart nginx


sudo systemctl restart mysqld


sudo systemctl restart sshd.service

Still Unable to Connect

If you have tried all the steps listed above and still cannot connect to your Linode, you may still be running into issues with your firewall.

Display your iptables ruleset:

sudo iptables-save

If you are unable to determine a specific rule that is causing issues with your firewall, flush your rules and start over:

  1. Create a temporary backup of your current iptables:

     sudo iptables-save > /tmp/iptables.txt
  2. Set the INPUT, FORWARD and OUTPUT packet policies as ACCEPT:

     sudo iptables -P INPUT ACCEPT
     sudo iptables -P FORWARD ACCEPT
     sudo iptables -P OUTPUT ACCEPT
  3. Flush the nat table that is consulted when a packet that creates a new connection is encountered:

     sudo iptables -t nat -F
  4. Flush the mangle table that is used for specialized packet alteration:

     sudo iptables -t mangle -F
  5. Flush all the chains in the table:

     sudo iptables -F
  6. Delete every non-built-in chain in the table:

     sudo iptables -X

    You can now begin rebuilding your firewall rules. See Control Network Traffic with iptables for more instructions.

  • Consult the Reboot Survival Guide for steps to prepare a Linode for any future maintenance.

  • For information on Linode Manager tools that can assist you in resolving unlikely system accidents and unplanned events, see the Rescue and Rebuild guide.

This page was originally published on

Your Feedback Is Important

Let us know if this guide was helpful to you.

Join the conversation.
Read other comments or post your own below. Comments must be respectful, constructive, and relevant to the topic of the guide. Do not post external links or advertisements. Before posting, consider if your comment would be better addressed by contacting our Support team or asking on our Community Site.
The Disqus commenting system for Linode Docs requires the acceptance of Functional Cookies, which allow us to analyze site usage so we can measure and improve performance. To view and create comments for this article, please update your Cookie Preferences on this website and refresh this web page. Please note: You must have JavaScript enabled in your browser.