The log would indicate that no filebot process is currently locking the log file and doing things and writing things to the log. That would be most strange. The file lock on the log file. Note that if any of these filebot processes where to be locking the log file, then you wouldn't be able to run the same filebot command with the same log file either.
Memory looks fine. Plenty of free RAM available. You'll want to check if there's any available RAM at the point in time where you have lots of filebot processes and the system starts stalling though. 4 GB is plenty, but if you accidentally call
filebot dozens of times per second then you will run into bottlenecks in no time.
Note that FileBot shouldn't take multiple minutes. Which log line is followed by multiple minutes of nothing? That might be a hint.
What does your
/opt/filebot/filebot.sh custom shell script do? You'll want to name your custom script
/path/to/jdownloader-postprocess.sh so that you don't confuse your own
filebot.sh entry point script with the
filebot launcher script.
Note that your JD event script is also very different from the
ArchiveExtracted.js sample code. Your code is likely calling your
filebot.sh entry point script much much much more often
(dozens of times per completed download, in rapid succession, repeatedly with the same input arguments) than you think. You'll want to test your assumptions there.
The
ps output above also seems to indicate that you're running everything as
root which is generally a bad idea. If you accidentally DoS attack your own system by spawning lots of processes, then you definitely don't wanna do so as
root, because
root processes probably get priority over everything else.
You'll want to update your entry point script and add additional logging, e.g. print time, arguments, process id, etc and generally redirect all console output to a file
(different file for each call) so you can get more information for what's going on with each command, and track each time your script is called by JD.
You can do
kill -3 <pid> to make a
java process dump all stack traces to console output. That will tell you exactly what that process is currently doing and might give us a clue as to where it's stuck.