Estou usando porta-patters de CrashPlan na minha Synology Diskstation DS213j (CPU ARM). Recentemente, atualizei o sistema operacional DiskStation para o DSM 6.0.
Como parte da atualização, o serviço CrashPlan atualizou-se para a versão mais recente durante a reinicialização. Eu tive um pequeno problema ao reiniciar o CrashPlan, porque esta versão vem com seu próprio JRE não-ARM, então eu apontei para o Java 8 JRE que vem com o DSM 6.0.
Agora o CrashPlan começa em OK, mas não faz backup. A GUI diz "Backup inicial não concluído". Nos logs eu vejo
ERROR 95988_AUTH-1 .service.backup.BackupController] Exception setting up BackupController! , java.lang.UnsatisfiedLinkError: /volume1/@tmp/jna-3506402/jna7016685188129052391.tmp: /volume1/@tmp/jna-3506402/jna7016685188129052391.tmp: internal error
STACKTRACE:: java.lang.UnsatisfiedLinkError: /volume1/@tmp/jna-3506402/jna7016685188129052391.tmp: /volume1/@tmp/jna-3506402/jna7016685188129052391.tmp: internal error
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1938)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1821)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:761)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:736)
at com.sun.jna.Native.<clinit>(Native.java:131)
at com.code42.jna.LinuxPlatform.<init>(LinuxPlatform.java:76)
at com.code42.jna.PlatformFactory.getLinuxPlatform(PlatformFactory.java:41)
at com.code42.jna.inotify.InotifyManager.<clinit>(InotifyManager.java:47)
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.<init>(JNAInotifyFileWatcherDriver.java:22)
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:417)
at com.code42.backup.path.BackupSetsManager.setUp(BackupSetsManager.java:153)
at com.code42.backup.BackupManager.setUp(BackupManager.java:141)
at com.backup42.service.backup.BackupController.setUp(BackupController.java:456)
at com.backup42.service.CPService.changeLicense(CPService.java:2809)
at com.backup42.service.CPService.authorize(CPService.java:2705)
at com.backup42.service.peer.Authorizer.doWork(Authorizer.java:927)
at com.code42.utils.AWorker.run(AWorker.java:148)
at java.lang.Thread.run(Thread.java:745)
/volume1/@tmp/jna-3506402/jna7016685188129052391.tmp é um binário ELF e o diretório está dentro do tmpdir da JVM do CrashPlan.
Eu estou interpretando isso como a nova versão do CrashPlan vem com algumas bibliotecas nativas, e estas não são construídas para CPUs ARM. Eu também vejo o CrashPlan 4.5 requer o kernel Linux 2.6.32 ou maior , e se não estiver lá, pode problemas com inotify chamadas. Estes são vistos na pilha acima.
Estou cheio? Sem as bibliotecas nativas do CrashPlan para minha plataforma, não vejo uma maneira de iniciá-lo. Eu tenho dois anos de assinatura do CrashPlan, e executá-lo do meu PC está longe de ser tão bom quanto executá-lo do meu NAS por vários motivos.
Substituir o jna.jar fornecido pelo CrashPlan por um novo baixado do Maven faz o truque. Veja Martin Kleinman :
- Download: https://maven.java.net/content/repositories/releases/net/java/dev/jna/jna/4.2.2/jna-4.2.2.jar
- go to
/var/packages/CrashPlan/target/binand make a backup from jna.jar (mv jna.jar jna.backup)- rename the downloaded jna-4.2.2.jar to jna.jar 13 copy the jna.jar you downloaded to the
/var/packages/CrashPlan/target/bindirectory