This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
After the upgrade to Crashplan 4.5.0 automatically ran on my Ultra 4 I get the following error:
ultra4p:~# cat /usr/local/crashplan/log/engine_error.log
Exception in thread "W18713692_ScanWrkr" java.lang.UnsatisfiedLinkError: Error looking up function 'inotify_init1': /usr/local/bin/java: undefined symbol: inotify_init1
at com.sun.jna.Function.<init>(Function.java:208)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:536)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:513)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:499)
at com.sun.jna.Library$Handler.invoke(Library.java:199)
at com.sun.proxy.$Proxy35.inotify_init1(Unknown Source)
at com.code42.jna.LinuxPlatform.inotifyInit1(LinuxPlatform.java:292)
at com.code42.jna.inotify.InotifyManager.start(InotifyManager.java:207)
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.<init>(JNAInotifyFileWatcherDriver.java:61)
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:417)
at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(BackupSetsManager.java:355)
at com.code42.backup.path.BackupSetsManager.access$1600(BackupSetsManager.java:72)
at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(BackupSetsManager.java:1148)
at com.code42.utils.AWorker.run(AWorker.java:157)
at java.lang.Thread.run(Thread.java:745)
Have tried upgrading Java without any change in Crashplan
ultra4p:~# java -version
java version "1.8.0_65"
Java(TM) SE Embedded Runtime Environment (build 1.8.0_65-b17, headless)
Java HotSpot(TM) Embedded Client VM (build 25.65-b01, mixed mode)
Any luck getting Crashplan 4.5.0 working on the Ultra 4? I'm getting the same error about undefined symbol: inotify_init1
I am seeing the error in the log also (dated 24 November, but the service might be running normally. I say "might" because the Crashplan Central was doing maintenance on my archive when the upgrade was pushed. The client isn't seeing my archive at the moment, but CrashPlan support believes that that will resolve when the maintenance completes.
How is your client behaving (apart from the exception report)?
The Crashplan client believes that 0% of its own backup set exist on Crashplan servers (no backup taken). Also the Crashplan instance on Readynas won't accept connections from other Crashplan instances on my network so it's impossible to backup to my Readynas now. As far as I can tell this seems to be confirmed by the e-mail reports I get from Crashplan.
So far I've been able to find out that "inotify_init1" might be included by the ReadyNAS kernel, but was only implemented in Glibc 2.9 and the ReadyNAS has libc6 2.7 as far as I can tell. This might be the issue, but I'm not sure. I sure hope Crashplan gets up and running again.
I just got the following email from CrashPlan. It looks like 4.5.0 isn't going to work unless we can somehow upgrade the kernel and glibc.
"Hello,
We're contacting you to let you know about some changes made to the newest version of CrashPlan that may affect the CrashPlan app on one of your devices. Starting with the release of CrashPlan version 4.5.0, the System Requirements with regards to Linux have changed. Here are the system requirements that have changed:
Linux kernel version:
CrashPlan app version 4.5.x or later: 2.6.27 or newer and glibc 2.9+ CrashPlan app version 4.4.1 or earlier: 2.6.13 or newer and glibc 2.4+ If you have a Linux device running kernel 2.6.26 or older and are still on CrashPlan version 4.4.1, CrashPlan on this device will not upgrade to version 4.5.0. If your device is on kernel 2.6.26 or older and has already upgraded to CrashPlan version 4.5.0, CrashPlan has likely stopped working.
To continue using up-to-date versions of CrashPlan, we recommend upgrading your operating system to a supported version of the Linux kernel. For instructions on upgrading your Linux device, refer to the documentation for your device or your Linux distribution.
An alternate solution to resolve this is to Uninstall CrashPlan 4.5.0, and install CrashPlan version 4.4.1, which can be found in this direct link:
Sadly that makes it almost useless since all of the Windows PCs I back up to it will auto-upgrade and then will no longer connect (according to the email). I am going to have to use the ReadyNAS just as network storage and mount it on a Windows system running CrashPlan.
(d) use my Dropbox add-on v2.0.x which has libc6 2.13 bundled 😉
(e) wait until I find the time to prepare a separate libc6 2.13 add-on bundle (current estimate would be this weekend, maybe earlier if my workload permits)
One can of course try option (c) but I can tell from experience that building eglibc 2.13 is no fun if you want to get it compatible with the ReadyNAS.
So it loks like from code42's email we should be able to downgrade crashplan to 4.4.1 and it should start working again. But how do we prevent it from auto updating to 4.5?
(d) use my Dropbox add-on v2.0.x which has libc6 2.13 bundled 😉
(e) wait until I find the time to prepare a separate libc6 2.13 add-on bundle (current estimate would be this weekend, maybe earlier if my workload permits)
-Stefan
I love those options.
Can you post back here when (e) is ready? Will you'll distribute it through rnxtras.com?
So it loks like from code42's email we should be able to downgrade crashplan to 4.4.1 and it should start working again. But how do we prevent it from auto updating to 4.5?
You can't. Their upgrade filter will block updates if the kernel is below their spec, but not if the issue is glibc (which is our situation). At least that is the info I've received from Crashplan Support.
But WhoCares_ has come to the rescue. He already has an add-on which upgrades the library, and will be unbundling the library upgrade if you are willing to wait a few days.
uname -a
Linux sdnas 2.6.37.6.RNx86_64.2.4 #1 SMP Wed Aug 20 11:41:34 PDT 2014 x86_64 GNU
ldd --version
ldd (Debian EGLIBC 2.13-38+deb7u3.5) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
and that I have WhoCares dropbox addon installed.
But for the life of me I am not able to locate the 4.5.0 download on crashplan website to install the gui on my windows 7 64 bit PC.
So the Pro is running 4.5.0 but my gui on my PC is still running 4.4.1.
But for the life of me I am not able to locate the 4.5.0 download on crashplan website to install the gui on my windows 7 64 bit PC.
Netgear posts the downloads first, and then puts them on their update servers. Crashplan seems to do it in the reverse order. They will eventually push an upgrade to the PC client, and since the 4.4.1 PC client works with 4.5.0 on the NAS, it should be fine to wait.
Do we just install it from the ReadyNas Web GUI like any other addon?
Yes. But as the site says, it won't show up in the installed list afterwards. You can confirm the glibc upgrade by entering ldd --version in ssh.
I installed it yesterday, then rebooted. Crashplan appears to be running normally (busy doing "block synchronization"), and I haven't seen side effects with other services on the Pro.
If anyone does see issues related to the library, it'd be good to post them here (as well as rnxtras.com).
Fantastic add-on! Thank you very much. Running ReadyNAS Pro 6 and just got the email from Crashplan saying my NAS hadn't backed up in 3 days. After a lot of research, your work has solved my problem completely.
Crashplan stopped working after the 4.5.0 upgrade on a ReadyNAS Ultra w/ RAIDiator 4.2.28. uname -r is 2.6.37.6.RNx86_64.2.4 but ldd (GNU libc) 2.7. Is there an addon for RAIDiator to upgrade glibc to 2.9+? Is there a DropBox add-on that will upgrade glibc? Thanks.
