Skip to main content
Code42 Support

Enterprise server does not restart after Linux reboots or upgrades

Applies to:
  • Code42 CrashPlan (previously CrashPlan PROe)

Overview

If your enterprise server does not restart when its Linux host server reboots or upgrades, follow these instructions to determine whether a new or revised restart script will solve the problem. If so, follow the instructions to create a enterprise server restart script in /etc/systemd/system/proserver.service or to modify the existing script at /etc/init.d/proserver.

Affects

Enterprise servers installed on Linux hosts as the root user (the default). When Linux reboots, the Code42 server fails to restart. Or a Linux upgrade process reports an error.

Unsupported process
The information presented here is intended to offer information to advanced users. However, Code42 does not design or test products for the use described here. This information is presented because of user requests.

Our Customer Champions cannot assist you with unsupported processes, so you assume all risk of unintended behavior. You may want to search our support forum for information from other users.

Causes

A enterprise server writes its restart script to a file in /etc/init.d, a long-time standard for Linux systems. Two Linux variations require a new or revised script:

Missing systemd script

Some Linux systems (see the list below) look for restart scripts in /etc/systemd rather than /etc/init.d. To make those systems restart a enterprise server when they reboot, you need to create a restart script at /etc/systemd/system/proserver.service.

Linux Distributions That Implement Systemd:

  • CentOS 7.14.04, April 2014
  • Debian v8, April 2015
  • Fedora v15, May 2011
  • openSUSE 12.2, Sept. 2012
  • Red Hat Enterprise Linux (RHEL) 7.0, June 2014
  • SUSE Linux Enterprise Server v12, Oct. 2014
  • Ubuntu 15.04, April 2015

For details see this Wikipedia article on systemd, Adoption and reception.

Non-compliant init.d script

In addition, some Linux systems that use init.d scripts, or both systemd and init.d, require compliance with a standard called Linux Standard Base (LSB). To meet that standard, you need to add some header information to the file /etc/init.d/proserver.

Users Have Reported LSB Problems On These Linux Distributions:

  • CentOS
  • Debian
  • Red Hat Enterprise Linux (RHEL)
  • Ubuntu

Diagnosing and solving

A enterprise server may fail to restart after its Linux host reboots for either or both of the causes described above.
Follow the instructions below to:

  1. Determine whether your Linux host uses systemd.
    If it does, install the systemd script, then reboot the Linux host.
    If your enterprise server restarts, the problem is solved. You are finished.
  2. Determine whether your Linux host requires LSB compliance.
    If it does, edit the init.d script.

Understand the importance of taking those steps in the order presented. An LSB problem may not show up until after a systemd problem is solved and the system rebooted.

Diagnosing and implementing systemd

Determining whether your Linux host uses systemd

At the Linux command line, enter the command:

sudo stat /proc/1/exe | head -1

If the command returns a reference to a systemd directory, as in the example below, then your Linux distribution does use systemd to manage services. Proceed with Installing The systemd Script, immediately below.

>$ sudo stat /proc/1/exe | head -1
>$ File: '/proc/1/exe' -> '/usr/lib/systemd/systemd'

If your Linux distribution does not use systemd, skip ahead to Diagnosing And Implementing LSB Compliance.

Installing the systemd script

  1. Copy the script below into a new file /etc/systemd/system/proserver.service

[Unit]
Description=Code42 Server
After=network.target

[Service]
Type=forking
PIDFile=/opt/proserver/proserver.pid
WorkingDirectory=/opt/proserver
ExecStart=/opt/proserver/bin/proserver start
ExecStop=/opt/proserver/bin/proserver stop

[Install]
WantedBy=multi-user.target

  1. Edit the file paths in the script, if necessary.
    The script above points to the default paths. Only a nonstandard installation needs changes to the script.
  2. At the Linux command line, enter two commands:
    sudo systemctl daemon-reload
    sudo systemctl enable proserver.service
  3. Verify that the second command returns results that report creating the symlink:
Created symlink from /etc/systemd/system/multi-user.target.wants/proserver.service to /etc/systemd/system/proserver.service
Warning:
Do not create the symlink manually; that may lead to problems of ownership and privileges.
  1. Restart your enterprise server with the new proserver.service script. The command is:
    sudo systemctl restart proserver.service
  2. Reboot the Linux host with this command:
    sudo shutdown -r now
  3. Test whether the enterprise server restarted with this command:
    sudo systemctl status proserver.service
    If the enterprise server restarts, the problem is solved. Your work is done.
    If the enterprise server does not restart, proceed with Diagnosing And Implementing LSB Compliance.

Diagnosing and implementing lsb compliance

Determining whether your Linux host requires lsb compliance

Search through your system logs using a command like the following:

sudo grep -r proserver /var/log/*

Look for a message like this one:

insserv: warning: script 'proserver' missing LSB tags and overrides

If you find such a message, edit the existing init.d script to comply with the LSB standard.

Editing init.d script to comply with lsb

  1. Open /etc/init.d/proserver with a text editor.
  2. Copy the following 13 lines to the top of the file.

#!/bin/sh
# Linux Standard Base comments
### BEGIN INIT INFO
# Provides: proserver
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Should-Start:
# Should-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: PROserver service
# Description: PROserver service
### END INIT INFO

  1. Reboot the Linux host with this command:
    sudo shutdown -r now
  2. Verify that the enterprise server restarted by connecting with a web browser, or with a command like the following:
    service --status-all
    If the enterprise server does not restart, contact our Customer Champions for CrashPlan PROe support or CrashPlan PRO support.