Good morning all,
I've been working on getting my Pogoplug E02 running as a headless Crashplan server, and am having mixed results. My Windows and Linux clients (about 4 right now) can connect to the server, but will often have messages like "waiting for connection" or "connecting to backup server" for hours on end. After 4-6 hours they will generally finally connect and complete their backup. Once this connection occurs everything functions as desired - I can restore files, backup files, etc.. Once I reboot the client or the Pogoplug, I go back into the waiting pattern though.
On the commonly referenced Opticality blog i found reference to a fix for "timing issues" http://www.opticality.com/blog/2011/07/ ... oplug-pro/. I have installed NSS, but I was unable to run the denoted jar command. I think this is because I have Oracle JRE 7.x instead of OpenJDK6. I was unable to find OpenJDK6 for this platform anywhere, so I substituted with 7.x. I think this may be a contributing factor, so if anyone can send me OpenJDK6, it would be much appreciated!
$this->bbcode_second_pass_quote('', 'U')pdate: This next part solves the timing delays, apparently among a number of other issues that I wasn’t even aware of! Once again, thanks to Ankit for figuring this all out.
You will need the nss package installed. Mine was there after the major update above. If you don’t have it installed, type: pacman -Sy nss
The file that’s missing from openjdk, which is causing all of the problems with CrashPlan, is libjnidispatch.so. It’s part of the jna package (Java Native Access). You’ll have to download a Debian package and extract the file.
Select a location near you from this link: http://packages.debian.org/sid/armel/li ... a/download. In the US, I chose this link directly: http://ftp.us.debian.org/debian/pool/ma ... _armel.deb
Assuming you downloaded that file to /tmp, here are the commands to extract the file we’re interested in:
Type: cd /tmp
Type: ar vx libjna-java_3.2.7-4_armel.deb (this will extract three files, one of which contains the file we’re interested in)
Type: tar -xzf data.tar.gz (this will unpack the tar file, creating a series of directories in /tmp/usr)
First we need to create the target directory for this. Since mkdirs (make nested directories) doesn’t exist by default, we’ll execute a number of consecutive mkdir commands. Hint: you can hit up-arrow after each command and just append the next directory name in the series of mkdir commands.
Type: cd /usr/local/crashplan/lib
Type: mkdir com
Type: mkdir com/sun
Type: mkdir com/sun/jna
Type: mkdir com/sun/jna/linux-arm
Type: cp /tmp/usr/lib/jni/libjnidispatch.so com/sun/jna/linux-arm/ (now we have the file in the correct directory)
Type: cp -p jna-3.2.5.jar jna-3.2.5.jar-ORIGINAL (this isn’t strictly necessary. Aside from documenting our change, it allows us to recover from errors more easily)
Type: jar uf jna-3.2.5.jar com/sun/jna/linux-arm/libjnidispatch.so (this is the critical step, inserting the library into the jar file that CrashPlan uses. I’m not sure the com/sun/jna/linux-arm directory creation is necessary, but better safe than sorry)
It seems that in addition to solving the timing issues (long delays in starting up), this actually dispatches (duh) maintenance tasks like pruning, synchronizing, etc. It’s all good, but there is a side-effect (well worth it!) that the Java process now takes up a significant amount of CPU, even when backups aren't active, since it appears to actively mai
