generate-app-cds: line 19: Aborted (core dumped)

[Stellarat]

Hi,

I have just installed Filebot and Filebot Node using the Synology package and have successfully got it running. I also purchased the 1 year license.

I notice I always get this core dump error:

Code: Select all

/var/packages/filebot/target/jsa/generate-app-cds: line 19: 12729 Aborted                 (core dumped) java -Xshare:dump -XX:SharedClassListFile="$CDS_ARCHIVE.lst" -XX:SharedArchiveFile="$CDS_ARCHIVE" -jar "$CDS_CLASSPATH" > "$CDS_ARCHIVE.log" 2>&1

I read somewhere in the forum that this shouldn't be a problem and will be fixed in a later release. However, that was some time ago and I have only just installed it (on 2024-07-25) so it is the latest.

Ideally I would like to run Filebot from the "Run External Program" option in qBitTorrent. However qBitTorrent is running in a container so doesn't have access to it.

Are there any tips on getting around this? Presumably Filebot could be installed in the qBitTorrent container as well - but would that mean it would have to be readded every time qBitTorrent is updated?

Or is there another way to call Filebot, perhaps running it as some sort of service or daemon that could be reached from the qBItTorrent container?

As a last resort I could use FileWatcher to watch a "Completed" folder instead. What's the best way to install this on a Synology NAS.

[rednoah]

I notice I always get this core dump error:

Code: Select all

/var/packages/filebot/target/jsa/generate-app-cds: line 19: 12729 Aborted                 (core dumped) java -Xshare:dump -XX:SharedClassListFile="$CDS_ARCHIVE.lst" -XX:SharedArchiveFile="$CDS_ARCHIVE" -jar "$CDS_CLASSPATH" > "$CDS_ARCHIVE.log" 2>&1

Your are using FileBot 5.1.3 which is the current latest release. FileBot 5.1.3 and prior are not fully compatible with JDK 21 and as a result of something not working you get the error message above.

FileBot 5.1.4 is fully compatible with JDK 21 and a beta builds are available for testing:
viewtopic.php?t=1609

Ideally I would like to run Filebot from the "Run External Program" option in qBitTorrent. However qBitTorrent is running in a container so doesn't have access to it.

Are there any tips on getting around this? Presumably Filebot could be installed in the qBitTorrent container as well - but would that mean it would have to be readded every time qBitTorrent is updated?

Or is there another way to call Filebot, perhaps running it as some sort of service or daemon that could be reached from the qBItTorrent container?

You have found a hard limitation of docker. Each container is effectively a separate computer and one computer cannot call commands on another computer. There are many many ways to get around this. None of them is trivial. All of them will involve some kind of network protocol, SSH, HTTP, etc. You will find many discussions on the topic here in the forums.

The typical solution here would probably be FileBot Node running and listening to network requests, then have qBT use curl to trigger a scheduled / prepared task via a HTTP request.

As a last resort I could use FileWatcher to watch a "Completed" folder instead. What's the best way to install this on a Synology NAS.

filebot-watcher is available as docker container:
https://www.filebot.net/linux/docker.html

Checking the file system for changes is probably the easiest solution overall, as it doesn't require network communication. Just make sure qBT moves files to the Completed folder in a single atomic move operation. DO NOT watch your active Downloads folder.

[Stellarat]

Thanks for the quick reply. I hadn't appreciated that as soon as I set a schedule for FileBot Node it creates a Task and gives me a very useful curl command to use to kick it off.

I will use this in qBitTorrent when a torrent downloads. It isn't as ideal as passing what had downloaded as an argument but it is much better than having to wait for the scheduled Task.

My slight concern is that the curl command includes "x-syno-token" which will presumably expire at some point?

[rednoah]

My slight concern is that the curl command includes "x-syno-token" which will presumably expire at some point?

You have a keen eye. That may indeed cause an issue in the future. Unfortunately, not much we can do about that, since FileBot Node uses DSM authentication.

That said, I don't know if cookie / x-syno-token actually ever expire, so I wouldn't worry about it for now. If you like the FileBot Node approach, then you can always run a separate instance with docker and configure it to use username + password authentication.