Package Details: crashplan-pro 4.7.0-1

Git Clone URL: (read-only)
Package Base: crashplan-pro
Description: An business online/offsite backup solution
Upstream URL:
Keywords: backup crashplan
Licenses: custom
Submitter: glittershark
Maintainer: aboccia
Last Packager: aboccia
Votes: 5
Popularity: 0.002146
First Submitted: 2013-08-27 17:10
Last Updated: 2016-07-17 06:07

Latest Comments

aboccia commented on 2016-07-17 06:16


I have fixed the checksum, not sure what happened there. I recall testing the build after updating the version, it may be possible that crashplan changed the tarball on their end. I always test before committing. As for your missing file issue, I am not seeing that on my end. Also I don't see the file shown in your paste, I do however see the similarly named "/opt/crashplan-pro/bin/../lib/com.backup42.desktop.jar" I am guessing that is what you should be referencing.

All is running fine on my end.


twistedjoe commented on 2016-07-12 17:08

After a fresh reinstall (changed the sha256sum to force the install),

it failed with the following:

twistedjoe commented on 2016-07-12 16:59

CrashPlanPro_4.7.0_Linux.tgz is failing the sha256 sums on my end.

Maybe it has been updated ?.

aboccia commented on 2016-05-17 17:04


I'll add the Restart=always, it's a workaround for the crashes but if it keeps the service running for people than that is a plus.

I did test with RemainAfterExit=yes as you previously suggested, that seemed to help on my end.

Updating package to latest now.

Thanks for all your input.

twistedjoe commented on 2016-03-11 02:39

When auto updating the daemon will stop (but not the systemd service).
In the middle of downloading jre-1.7 usually, systemd kill the update process.
The update log show that it was killed in the middle of loading it with wget.

No crash, it just stop. Then the service does not restart.
On the crashplan package they have Restart=always, which would make it at least restart after trying the update.

Maybe if it does not have to load jre, systemd don't have the time to catch up before the daemon is back and that prevent it from being killed in your case.

If you want to test it remove crashplan-pro + the /opt/crashplan-pro folder then reinstall the 4.5.2 package and start the daemon, the first thing it does once you open the GUI would be updating. Then you should have a upgrade.<SOME ID>.log file in /opt/crashplan-pro/log/.

Though, I guess it would be too much trouble + you are risking losing your existing backup if you do it.

aboccia commented on 2016-03-11 02:19


I have updated to the latest 4.6.0, as for the auto update failure. I have not seen this same behaviour in my environment. I will look into testing it before applying your patch to the service file.


twistedjoe commented on 2016-03-11 01:24

Hi, the package seems to be outdated. 4.6.0 is out.
The auto-update is killing the service at the moment.
I tried to find a way to disable the auto-update, but was not able to.

I think we should disable auto-update and update the package instead (maybe if we ask code42 they will add an option).

In the meantime, I fixed the auto-update so it would not fail.

The problem seems to be that once the auto-update script stops the daemon, systemd catch up and kill the unit while the script is updating. This in turn kill the upgrade script mid completion.

The upgrade script is loaded with the upgrade itself by the java bin, so it will be hard to patch.

My temp fix is to add RemainAfterExit=yes to the service file. This way systemd will not kill the unit after the daemon has been stopped.

I am new to arch and systemd so this might have repercussions I don't know about.

Here is the patch file:

Just updating the package (without preventing auto update) is not really a solution in here case, because the daemon will just close silently every time there is an upgrade. I don't want to have to periodically check to be sure crashplan is still working. I need it to either upgrade automatically, or just don't try if it would crash.

glittershark commented on 2015-05-21 14:34

@aboccia fine by me - I don't use it anymore myself. Disowning now.

aboccia commented on 2015-05-21 14:24

@glittershark I currently require up to date versions of this package and will for the foreseeable future, I'd like to take over as the maintainer of this package if you are no longer able to keep things up to date. Please let me know.

Thank You

catwell commented on 2014-01-31 10:14

> e.g. add the following line to /etc/sysctl.conf
> fs.inotify.max_user_watches=1048576

Should be changed: sysctl.conf is no longer supported.

All comments