DroboApp announcement: CrashPlan 3.4.1

Forum History DroboApps
1

Newest update of CrashPlan now available as DroboApp.

You can find it here: http://www.droboports.com/app-repository/crashplan-3-4-1

This is a major change from the previous version. I reorganized the app so that (hopefully) future updates should happen smoothly.

This version requires Oracle’s JVM instead of OpenJDK, and adds the locale DroboApp as a new dependency to run. With the locale app we should no longer have problems with Unicode characters.

I suggest a clean install. I.e., stop crashplan, rename it to crashplan.old, install the new one, stop it, and then move the backupArchives subfolder from crashplan.old to crashplan. This will preserve your backups.

2

Just out of curiosity, does this improve the service.sh script to no longer depend on the working directory? Looks like it does, but I’m not positive (and I don’t want to make a mess to find out). Also, I assume I’ll have to reset things to write the service log to somewhere other than the disk pack if I ever want the drives to spin down.

3

Yes. I was missing a “cd ${prog_dir}” in the start function.

The only way to change the location of the log files is to symlink the app/log folder somewhere else. Although you can edit service.sh and change the location of droboapp.log, engine_output.log, and engine_error.log, all the other files in app/log seem to hardcoded to that path in the JAR files.

4

Unless they changed it since 3.2.1, the location for the rest of the files can be changed in my.service.xml. I just haven’t bothered to do it yet. I think I’m done messing with stuff for a couple weeks. :smiley:

5

Oops. You’re absolutely right. I forgot about that file.

6

I downloaded crashplan 3.4.1 from DroboPorts, put it in the DroboApps share and ran DroboApps.sh install. It extracted but then gave an error:

CrashPlan cannot be launched due to locale creation failure with error code 1

I went ahead and copied backupArchives over, but it gave the same error when I tried to launch the service.

7

This means you also have to install the locale app from here:

http://www.droboports.com/app-repository/locale-2-5

I just noticed I forgot to mention that in the page. Sorry about that.

8

I read that but I guess it didn’t click that I needed to download it separately. Thanks!

9

Important note for windows users - if you want to change the inbound backup path - you have to use linux (OSX?) client. The windows client somehow changes the path in a way that it does not work. (I have seen “C” added to the path…)

10

Looks like the default memory settings for Crashplan are crushing my DroboFS (system loads of 8+ and the app was taking 355% of memory). I’ve changed it to 192 megs of RAM maximum for the app (in run.conf) and I changed the Java heap max to 64m (in my.service.xml). Anyone know what the “right” numbers to use are? I also increased my swap file to be 1gig (in case anyone is wondering, the file to change this is /etc/init.d/enable_swap).

11

To be honest, I don’t think anyone knows. My guess is that these values should work:

  1. -Xms128m (in run.conf)
  2. -Xmx128m (in run.conf)
  3. 128m (in my.service.xml)

I’m not quite sure why that value exists in the XML file, since that exact parameter is defined using Xmx, but hey, who knows what’s going on inside the application.

In any case, everyone please post your values so that we can try to find an optimal set for the FS.

12

I’ve upped my numbers some. -Xms at 20m (from the default), -Xmx at 256m, and 128m in my.service.xml. My /proc/meminfo shows just under 2m of free RAM and system loads are under 3 so it’s reasonably responsive. But then I’m in an ongoing scan and sync right now so it may get better once things settle in.

13

Ricardo, Thanks a million. Finally got around to updating crashplan after it being down for a bit since 3.4.1 came out and with the switch from openjdk to java I am seeing 100% better responsiveness in the application.

Previously I wasn’t able to back-up Drobo to Crashplan Central and it usually took a couple of hours at least after a Drobo restart for any of my computers to see the Drobo in crashplan and start backing up to it. Now the Drobo is backing up to crashplan central and as soon as i started the service all my computers immediately saw it and started doing their back-ups.

I am glad i bothered you all those months ago about getting Crashplan ported. Going to be sending some refreshment money your way next paycheck.

14

Just had to change mine, noticed it was running at 380% or so, didn’t bother me much until i came back a couple of days later to check on how much crashplan has uploaded and i couldn’t ssh into the drobo.

  1. -Xms40m (in run.conf)
  2. -Xmx128m (in run.conf)
  3. 128m (in my.service.xml)

Will report back in a couple of days to see if i can still ssh into the drobo or not.

15

I have been up and running on the update to crashplan for a while now - much appreciated.

16

::UPDATE::

So 6 days later I am still able to SSH into the Drobo and everything seems to be working. I did notice that by lowering the amounts it did increase the “scanning” time by a ton. It’s been scanning the same folder for 6 days now, but I am in no rush as long as it gets uploaded.

::UPDATE 2::
So went to check on it today and SSH is no longer working. I believe it is still uploading to crashplan, so maybe i will just let it sit for awhile. Anyone know what could be causing the problem?

17

hello!,I really like your writing Discount Ugg Boots so much! proportion we keep in touch extra approximately your post on AOL? ugg boots clearance I purchased these UGG for my 12 year old daughter and she or he absolutely loves them. They are great now, however i am concerned about how they will hold up. We also purchased the UGG Boot Care Kit, and my daughter faithfully applied the many appropriate conditioners, therefore i am hoping it can prolong living of the boot. My only complaint was in regard thus to their price. I don’t know they are worth $[…], in case they last 2 winters, I can’t complain. , I require an expert in this area to solve my problem. May be that’s you! Looking ahead to peer you.

18

Does changing swap file size in that config file actually work? I’ve seen people in other threads saying the DroboFS doesn’t seem to touch its swapfile for apps at all (saying that maybe it’s reserved for NAS duties somehow…). If it’s confirmed to work, I’ll make this change tomorrow…

…as I’m currently having issues using the DroboFS as a crashplan destination (and the above may or may not help, but if anyone has experienced similar issues, let me know):

It seems to always want to “compact versions (deep)” everytime crashplan starts (takes about an hour to compact the inbound computer’s backup in question), then it just stops at 100% (stating < 1 minute remaining) as if it’s not finished, which is confirmed as the inbound computer’s progress notifier just says “maintaining backup files”. Sometimes if I leave it on for a few days, the inbound computer gets a chance to backup for an hour or two, then crashplan on the Drobo decides to go back into its maintenance cycle. There’s still around 80Gb to go, so two hours every couple of days isn’t exactly going to do it quickly…

Of note is I have maintenance times set to long values (i.e. only every 14 days for normal and 28 days for deep), to try to make sure it does this infrequently - although I suspect it never realises it’s finished, hence it just tries again and again.

Aside from the swap size (if it actually helps), anyone else have any ideas? I’ve not found any info on the crashplan site or forums, and I’m guessing they won’t be much help anyway as they probably wouldn’t support it on such low specced devices (and if that’s the reason for this issue, I doubt many people over at the forums will have seen the same problem).

Oh, and in any case - big thanks to Ricardo for all his work with DroboPorts :smiley:
The Drobo itself is backing up to Crashplan central just fine :-)[hr]
^ for reference, although it seems to be using a lot of memory, it’s not using much CPU at the point it hangs:

top:
485 1 root S N 654m353.8 0 6.2 /mnt/DroboFS/Shares/DroboApps/java7/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=true -Dsun.net.inetadd

free:
total used free shared buffers
Mem: 189028 186620 2408 0 4592
Swap: 262136 0 262136
Total: 451164 186620 264544

Hmm, actually, I’m now wondering if there’s a deadlock-type condition going on here (crashplan waiting for another process that needs more memory that it can’t get because crashplan has used it all).

Well, if anyone cares to comment or make suggestions, let me know :slight_smile:

19

My hypothesis so far is that the OOM-Killer ( http://linux-mm.org/OOM_Killer ) is nuking some important processes (including SSH). This has happened to me as well and I couldn’t find a good explanation either.

Absolutely.

I don’t mean to offend, but that is crazy talk. Sure, the FS’s default swapiness ( http://en.wikipedia.org/wiki/Swappiness ) is low enough that the OS will avoid swapping as much as possible, but if you run something big like MySQL or Plex, you’ll see your swap usage skyrocket. I’ve seen as much as 400 MB of swap being used when I did something (admittedly) pretty crazy: I ran Crashplan, the whole NZB stack (NZBGet, SickBeard, Couchpotato), the torrent stack (rtorrent + rutorrent), Plex, minidlna, Kernel NFS, and all the default services (AFPD, SMB, Avahi, …). You could hear the grinding from across the room.

Yup. My bet is that you need to increase the swap and then increase the values in the Crashplan config. My FS is working both as a source and as a destination. I backup my laptop to it, and some select folders from the FS to the Crashplan servers.

You’re very welcome. :slight_smile:

Your Xmx is a bit too big, I think. The VM is probably butting heads with the OS when asking for that much heap space. My feeling is that you shouldn’t specify a maximum heap size (Xmx) larger than your actual physical memory. In the case of the FS, the maximum should be something lower than 180 MB.

20

No offense taken, and I agree with it being crazy talk. It didn’t make any sense to me that swap can be “reserved” for particular applications - I’m sure there’s more to it than my basic understanding, but the O/S should page things in and out of it as/when required, regardless of what the app is.

I do wonder, however, when I see figures such as I posted above (and below now, in fixed width), what is going on. Is this just a bug in “free”, or perhaps the OS somehow misreporting things?

[quote=“grazanaut, post:18, topic:18813”]
free:

..... total used free shared buffers Mem: 189028 186620 2408 0 4592 Swap: 262136 0 262136 Total:451164 186620 264544 [/quote]

… this must be the reason people in other threads were talking about swap not being used. In fairness, the above, which is roughly what I see every time crashplan is running, does look a bit odd (it’s zero swap use, but only 2Mb of physical ram free). Am I misinterpreting the output from “top”, when I say that it appears that crashplan is using more memory than the total shown as used by “free”?

In any case, reducing the java heap allocation to 128Mb has got crashplan past the maintaining files stage. I haven’t yet changed swap size, but will report back with some settings that seem to work once I’ve adjusted things a but more.