- CrashPlan for Small Business
- Code42 CrashPlan (previously CrashPlan PROe)
If your CrashPlan app does not restart when its Linux machine 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 restart script in /lib/systemd/system/crashplan.service or to modify the existing script at /etc/init.d/crashplan.
The CrashPlan apps installed on Linux for all users (the default). When Linux reboots, the CrashPlan app fails to restart. Or a Linux upgrade process reports an error.
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.
The CrashPlan app 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:
No systemd script
Some Linux systems look for restart scripts in /lib/systemd rather than /etc/init.d. To make those systems restart the CrashPlan app when they reboot, you need to create a restart script at /lib/systemd/system/crashplan.service.
- 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/crashplan.
If you have only a systemd script, then upgrades may fail because the upgrade process cannot run the init.d script to stop the CrashPlan app before proceeding. Therefore, if you have a failed upgrade, try making the /etc/init.d/crashplan file LSB-compliant.
- Red Hat Enterprise Linux (RHEL)
Diagnose and solve
The CrashPlan app may fail to restart after its Linux machine reboots for either or both of the causes described above. Follow the instructions in the order presented below to:
- Determine whether your Linux machine uses systemd.
If it does, install the systemd script, then reboot the machine.
If the CrashPlan app restarts, the problem is solved.
- Determine whether your Linux distribution requires LSB compliance.
If it does, edit the init.d script.
Note that an LSB problem may not show up until after a systemd problem is solved and you reboot the system.
Verify and use systemd
Determine whether your Linux Machine 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.
Install the systemd script
- Copy the script below into a new file /lib/systemd/system/crashplan.service
[Unit] Description=Code42 CrashPlan app After=network.target [Service] Type=forking PIDFile=/usr/local/crashplan/CrashPlanEngine.pid WorkingDirectory=/usr/local/crashplan ExecStart=/usr/local/crashplan/bin/CrashPlanEngine start ExecStop=/usr/local/crashplan/bin/CrashPlanEngine stop [Install] WantedBy=multi-user.target
- Edit the file paths in the script, if necessary.
The script below points to the default paths. Only a nonstandard installation needs changes to the script.
- At the Linux command line, enter two commands:
sudo systemctl daemon-reload
sudo systemctl enable crashplan.service
- Verify that the second command returns results that report creating the symlink:
Created symlink from /etc/systemd/system/multi-user.target.wants/crashplan.service to /lib/systemd/system/crashplan.service
Do not create the symlink manually; that may lead to problems of ownership and privileges.
- Restart the CrashPlan app with the new crashplan.service script. The command is:
sudo systemctl restart crashplan
- Reboot your machine with this command:
sudo shutdown -r now
- Verify that the CrashPlan app restarted with this command:
sudo systemctl status crashplan.service
If the CrashPlan app restarts, the problem is solved.
If the CrashPlan app does not restart, go to Diagnosing And Implementing LSB Compliance.
Diagnose and implement LSB compliance
Determine whether your Linux machine requires LSB compliance
Search through your system logs using a command like the following:
sudo grep -r CrashPlanEngine /var/log/*
Look for a message like this one:
insserv: warning: script 'CrashPlanEngine' missing LSB tags and overrides
If you find such a message, edit the existing init.d script to comply with the LSB standard.
Edit init.d script to comply with LSB
- Open /etc/init.d/crashplan with a text editor.
- Copy the following 13 lines to the top of the file.
# Linux Standard Base comments
### BEGIN INIT INFO
# Provides: CrashPlanEngine
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: CrashPlan Engine
# Description: CrashPlan backup service engine
### END INIT INFO