docker-crashplan
docker-crashplan copied to clipboard
JrCs
Request for more documentation on "Automatic version upgrade" feature
How is the automatic version upgrade supposed to work? I just started this image for the first time and it ran CrashPlan 4.4.1 (whereas 4.5.2 seems to be the latest version for Linux).
I also set the environment variable CRASHPLAN_VERSION to 4.5.2 and started a new container from the image, but that didn't seem to make any difference.
I don't see any of the scripts calling the crashplan.exp?
After reading the Dockerfile, seems like the install.sh is actually called during image build. So there isn't really an 'automatic' upgrade, is there? I understood this as a container upgrading itself, without requiring an image rebuild. Guess that was a misunderstanding.
Will you push an update to DockerHub? Or do I need to fork and build myself?
If you bind mount /var/crashplan on a dedicated volume (or on the host) crashplan will selfupdate automatically (like a crashplan not in a container). No need to create new images. Look in the history.log file. This is what i have in it:
I 01/17/16 03:14AM CrashPlan started, version 4.5.0, GUID 713740696857812047
I 01/17/16 03:14AM Backup scheduled to always run
I 01/17/16 03:14AM Downloading a new version of CrashPlan.
I 01/17/16 03:14AM Download of upgrade complete - version 1435726800452.
I 01/17/16 03:14AM Installing upgrade - version 1435726800452
I 01/17/16 03:14AM Upgrade installed - version 1435726800452
I 01/17/16 03:14AM CrashPlan stopped, version 4.5.0, GUID 713740696857812047
I 01/17/16 03:14AM CrashPlan started, version 4.5.2, GUID 713740696857812047
@JrCs You're right, that's how I had already mounted it, and apparently it did eventually self-update.
I 03/14/16 08:21PM CrashPlan started, version 4.4.1, GUID 733559765922898832
I 03/14/16 09:03PM CrashPlan started, version 4.5.2, GUID 733559765922898832
It just took 45 minutes and I hadn't waited that long with my test container. Is this update interval to be expected? Shouldn't it self-update immediately once before the first start?
Mind documenting all of this? I think that would help adoption and prevent misinterpretations like mine. Thanks!
Btw., the above is my entire history.log.0 file. I don't have any Downloading a new version or Upgrade installed or CrashPlan stopped. I probably restarted the image a couple of times in between though, trying to get the self-update working. At least once I also remember clearing the volume, hoping that that might trigger the update somehow.
So this is still all fairly confusing behavior to me, mostly because I didn't find any documentation that would say how/when the update is supposed to happen, so there's nothing I could compare the actual behavior against.
I will update the documentation. For the selfupdate functionnality i don't know how it works. It's crashplan that decided when it need to be updated, and i don't know the algorithm that it use.
@JrCs I see. You might want to also link to Using CrashPlan On A Headless Computer, which has some useful information as well.
I've tested this again now, starting a new container with a volume with everything but the conf and id directories removed. It's been running for more than two hours now, but hasn't updated yet. Here's the history.log.0:
I 03/15/16 08:52AM CrashPlan started, version 4.4.1, GUID 733556053290072213
I 03/15/16 08:52AM Backup scheduled to always run
I 03/15/16 08:52AM [7543ce56a4da Backup] Scanning for files to back up
I 03/15/16 08:52AM [7543ce56a4da Backup] Scanning for files completed in < 1 minute: 9 files (3.50MB) found
It bugs me a bit that it runs for so long on the old version, and will do so everytime I'm restarting the container. I just don't know what the consequences of that might be. I might restart the container quite often, and it can't be a good thing that my backup service will switch back and forth between 4.4.1 and 4.5.2 all the time.
In my service.log.0, I see a lot of PeerConnector] PC:: Cancelling connection attempt due to timeout. No idea if that's part of the cause, or just to be expected when running in a dockerized environment where there's no network 'peers'.
Actually, maybe there's something else going on, this is from my service.log:
[03.15.16 10:15:47.782 INFO main om.code42.net.ConnectivityTester] Connectivity testing localhost, port=4242, connectionTimeout(ms)=100, retryDuration(ms)=100
[03.15.16 10:15:47.889 INFO main om.code42.net.ConnectivityTester] Failed to connect after duration=102, retryDuration=100, address=localhost, connectTimeout=100, e=Connection refused
[03.15.16 10:15:47.889 INFO main om.code42.net.ConnectivityTester] Connectivity testing localhost, port=4243, connectionTimeout(ms)=100, retryDuration(ms)=100
[03.15.16 10:15:47.990 INFO main om.code42.net.ConnectivityTester] Failed to connect after duration=101, retryDuration=100, address=localhost, connectTimeout=100, e=Connection refused
[03.15.16 10:15:47.992 INFO main om.code42.net.ConnectivityTester] Connectivity testing localhost, port=4244, connectionTimeout(ms)=100, retryDuration(ms)=100
[03.15.16 10:15:48.094 INFO main om.code42.net.ConnectivityTester] Failed to connect after duration=102, retryDuration=100, address=localhost, connectTimeout=100, e=Connection refused
[03.15.16 10:15:48.105 INFO main ackup42.service.ui.UIInfoUtility] Loaded address=0.0.0.0, port=4243, and token from location=/var/lib/crashplan/.ui_info
[…]
[03.15.16 10:15:48.490 INFO main p42.service.upgrade.PatchManager] SKIP applying client upgrades, server didn't give us patches
[03.15.16 10:15:48.490 INFO main com.backup42.service.CPService] Not authorized, skip setting up backup layer.
[…]
[03.15.16 10:16:47.688 INFO ystemWatcher p42.service.peer.CPCConnectCheck] Connect to CPC after 0ms
[03.15.16 10:16:47.799 INFO ystemWatcher up42.service.peer.PeerController] Attempting to connect to CPC. delay=60000
[03.15.16 10:17:07.782 WARN DefaultGroup .code42.messaging.peer.PeerGroup] PG::DefaultGroup PeerException attempting to connect. RemotePeer-[guid=42, server=true, state=CONNECTING, mode=PRIVATE, location=central.crashplan.com:443, public=na, transportPbK=null, transportPbKRequestable=true, connecting=2016-03-15T10:17:07:776, connected=0, disconnected=2016-03-15T10:16:47:699, attempts=1, connectActivity=2016-03-15T10:17:07:776, keepAliveSent=0, minRetry=31542, retryDelay=0, reflector=na, #nat=0, session=null] e=com.code42.peer.exception.PeerException: IOExcepton opening remote session. guid=42, remoteLocation=[[[email protected]:443(server)], pbKRequestable=true], timeout=30000, java.io.IOException: Unexpected Exception in connect() for remoteAddress=central.crashplan.com:443, java.nio.channels.UnresolvedAddressException
I'm still investigating what this means…
I think the last one was just a connection issue of boot2docker. After restarting that, it could reach central.crashplan.com:443 again.
However, the auto-update is just not working for me. I've had the container running for multiple hours now, it's been running backups just fine and I could connect the UI to it, but it keeps sticking to 4.4.1.
The one time it had suddenly been running 4.5.2 before (without ever mentioning the upgrade) must have been a fluke. I cannot reproduce it anymore.
I see that you updated your DockerHub builds to start out at 4.5.2, thanks! I'll try those tomorrow.
I think this may be related, but it seems there is an issue upgrading as of late. I'm getting an error when it tries to upgrade/update the Java version inside the container:
Mon Mar 7 12:09:08 EST 2016 : Current CrashPlan Backup Engine:
root 27 1 0 Mar03 ? 00:00:00 /opt/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx1024m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -classpath /usr/local/crashplan/lib/com.backup42.desktop.jar:/usr/local/crashplan/lang com.backup42.service.CPService
Mon Mar 7 12:09:08 EST 2016 : Stopping using /etc/init.d/crashplan...
Stopping CrashPlan Engine ... OK
Mon Mar 7 12:09:18 EST 2016 : Ensuring the UpgradeUI is not running.
Mon Mar 7 12:09:18 EST 2016 : UpgradeUI is shut down.
Mon Mar 7 12:09:18 EST 2016 : JAVACOMMON is set: /opt/jre/bin/java
Mon Mar 7 12:09:18 EST 2016 : Current Java Version: 1.8
Mon Mar 7 12:09:18 EST 2016: The Current java is not compatible. Embedding a compatible version.
Mon Mar 7 12:09:18 EST 2016 : Download JVM from http://download.code42.com/installs/proserver/jre/jre-7-linux-x64.tgz
Mon Mar 7 12:09:18 EST 2016 : downloading the JRE using /usr/bin/wget
Connecting to download.code42.com (216.17.8.19:80)
Connecting to download.code42.com (216.17.8.19:443)
wget: can't execute 'ssl_helper': No such file or directory
wget: error getting response: Connection reset by peer
Mon Mar 7 12:09:19 EST 2016 : Unable to download JRE from http://download.code42.com/installs/proserver/jre/jre-7-linux-x64.tgz; please check network connection
Mon Mar 7 12:09:19 EST 2016 : Starting using /etc/init.d/crashplan...
Starting CrashPlan Engine ... Using standard startup
It would seem that this has been happening for awhile, and when it fails, it still leaves the binaries it downloaded and inflated the size of my container. I finally found this and cleaned it out, but its been failing to upgrade for quite some time. Wouldn't have known if I didn't open the actual GUI and saw the failed upgrade notifications.
I can confirm that my container (which has been running for seven days without interruption) is still running 4.5.2 (the version built into the image).
I don't see any attempts of it to update, however. Not sure how to spot them, but I did a full-text search for UpgradeUI in /log/service.log.0 and nothing came up. There's also nothing relevant for the search terms update or upgrade. Am I looking at the right log? All the other ones appear to be empty or unrelated.
At any rate, it definitely doesn't automatically upgrade to 4.6.0.
Wouldn't have known if I didn't open the actual GUI and saw the failed upgrade notifications.
@1activegeek: Where do you see these in the GUI?
@1activegeek update to the lastest image and you don't see the wget: can't execute 'ssl_helper': No such file or directoryerror
@hheimbuerger same here: no update. But crashplan take times to detect that an update is necessary/available
I thought I had done that the first time, but I guess I hadn't. Wasn't aware I had to always explicitly PULL the newer image from the hub. Got it running now and the errors look to have subsided with the upgrade. Thanks for the great work @JrCs