NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
NAS not starting any services #25220444
I had a hard time coming up with a good subject for this problem, since I don't really know what's wrong and how to describe it. Here's the story: Suddenly I noticed that CIFS was not behaving norm...
Thanks for your replies! If you're interested, I did a little more digging and thinking. :)
I found out that every time Crashplan starts it puts one of those jna1234567890123456789.tmp files of exactly 136883 bytes in tmp. They're definitely related to Java. From my googling it seems it might have to do with how Java is installed and that there might be a way to stop this from happening by unpacking some jar file to somewhere and pointing some config towards that instead. Well... not for me... :)
I'm not sure how such files could constitute 2.5GB though. That would be 18.000+ of them. Perhaps the files grow over time? Perhaps they are created at other times as well? Were there that many or of larger sizes in there? In any case, if deleted, Crashplan still works.
I did not find any specific temp path in the Crashplan config. Only for cache. The only references to "tmp" are for files/folders that should be hidden in the GUI I think so you don't select them for backup.
Right now the total Crashplan cache size is small, but I'll keep an eye on it in parallel with the tmp folder.
Would it be possible to force the creation of these jna*.tmp files on the data volume via some symbolic link or something? I found this, but I'm not sure I'm understanding it. Running what program?
http://stackoverflow.com/questions/1010 ... -io-tmpdir
I found out that every time Crashplan starts it puts one of those jna1234567890123456789.tmp files of exactly 136883 bytes in tmp. They're definitely related to Java. From my googling it seems it might have to do with how Java is installed and that there might be a way to stop this from happening by unpacking some jar file to somewhere and pointing some config towards that instead. Well... not for me... :)
I'm not sure how such files could constitute 2.5GB though. That would be 18.000+ of them. Perhaps the files grow over time? Perhaps they are created at other times as well? Were there that many or of larger sizes in there? In any case, if deleted, Crashplan still works.
I did not find any specific temp path in the Crashplan config. Only for cache. The only references to "tmp" are for files/folders that should be hidden in the GUI I think so you don't select them for backup.
Right now the total Crashplan cache size is small, but I'll keep an eye on it in parallel with the tmp folder.
Would it be possible to force the creation of these jna*.tmp files on the data volume via some symbolic link or something? I found this, but I'm not sure I'm understanding it. Running what program?
http://stackoverflow.com/questions/1010 ... -io-tmpdir
I don't know how well this will work, but I just moved /usr/local/crashplan to /c/.crashplan and then created a sym link to it:
ln -s /c/.crashplan /usr/local/crashplan
Crashplan seems to be working ok that way
I did the same thing for the /tmp dir, moved it to /c/.tmp/ and sym linked to it. That one I am not as confident I won't run into some strange problem sooner or later, but I'm trying it for a while.
This should prevent either /tmp nor /usr/local/crashplan from ever filling up the root partition again.
Dewdman42 wrote:
I don't know how well this will work, but I just moved /usr/local/crashplan to /c/.crashplan and then created a sym link to it:
ln -s /c/.crashplan /usr/local/crashplan
Crashplan seems to be working ok that way
I did the same thing for the /tmp dir, moved it to /c/.tmp/ and sym linked to it. That one I am not as confident I won't run into some strange problem sooner or later, but I'm trying it for a while.
This should prevent either /tmp nor /usr/local/crashplan from ever filling up the root partition again.
I moved the cache by changing my.service.xml (look for <cachePath>) but left the rest alone.
If /c/ couldn't be mounted you might have some issues running w/o /tmp. So I'm not confident in that one either.
It sounds like you ran out of memory?
Yea i put tmp back.. I will just live with that one. but having /usr/local/crashplan sym linked to somewhere under /c is fine by me and I won't have to worry at all about any of crashplan's caching, logs or other things. I think it works either way. Most of my other apps like plex and so forth all install under /c/. I think crashplan should have also.
There is supposedly a way to edit the run.conf file under /usr/local/crashplan/run/run.conf, and you can add a -D option to specify an alternate tmp file location for java to use while running crashplan. I tried it once, but didn't work and didn't have time to try further.
Djava.io.tmpdir=/c/tmp
Something like that.
There is supposedly a way to edit the run.conf file under /usr/local/crashplan/run/run.conf, and you can add a -D option to specify an alternate tmp file location for java to use while running crashplan. I tried it once, but didn't work and didn't have time to try further.
Djava.io.tmpdir=/c/tmp
Something like that.
I tried that briefly when Crashplan ran out of memory a few months ago. At least I set up a crashtmp folder on C. But I must have undone it, because its not in run.conf. I wasn't seeing many files there anyway - and the real issue was crashplan restarting all the time, and failing to back up. Its resolved now (crashplan did take the support case even though I was running headless).
I see no risk to linking the main crashplan directory, and it also lets you look at the logs w/o needing ssh.
I suggest setting the retention for deleted files on CrashPlan central (instead of leaving it at the default "never"). Then try consolidating the archive to reduce the storage there. Deduplication memory requirements scale with the archive, not with the local store.
I also set deduplication to minimal and compression off. Not sure if that helps memory or not. You can't go above ~3.5 GB for crashplan, no matter how much memory you have in the NAS - it only runs on the 32 bit jvm.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
