[Seven.issimo]

I've been running JD2 Headless on my BananaPi (RaspberryPi clone) for long time.
JD2 has been running as sandboxed service (Systemd service with its own user)[1]

A recent update broke my JD2 setup: no more connection to my.jdownloader.org means JD2 is unusable.

I tryed to replicate the behaviour causing this.

1) Clean install, first run as root:

# /usr/bin/curl -s -O http://installer.jdownloader.org/JDownloader.jar
# /usr/bin/java -Djava.awt.headless=true -jar JDownloader.jar -- -console -norestart

2) When restart is needed: I copied myjd config (with login and pass), then second run:

# cp -f org.jdownloader.api.myjdownloader.MyJDownloaderSettings.json ./cfg/
# /usr/bin/java -Djava.awt.headless=true -jar JDownloader.jar -- -console -norestart

--> Ok, connection to MyJD working. Here's a sample log: jdlog://1351311370661

3) Change Ownership to appropriate user, third run as root

# chown -R jdownloader: -- *
# /usr/bin/java -Djava.awt.headless=true -jar JDownloader.jar -- -console -norestart

--> Ok, login/pass are read from cfg. Connection to MyJD working.

4) Fourth run: run as Systemd service for 1st time (no console attached)

dic 01 14:24:04 bananapi java[2518]: java.lang.ExceptionInInitializerError
dic 01 14:24:04 bananapi java[2518]:         at jd.SecondLevelLaunch$9$1.run(SecondLevelLaunch.java:747)
dic 01 14:24:04 bananapi java[2518]: Caused by: java.lang.RuntimeException: No Console Available!
dic 01 14:24:04 bananapi java[2518]:         at org.appwork.console.ConsoleDialog.<init>(ConsoleDialog.java:54)
dic 01 14:24:04 bananapi java[2518]:         at org.appwork.console.ConsoleDialog.<init>(ConsoleDialog.java:60)
dic 01 14:24:04 bananapi java[2518]:         at org.jdownloader.api.myjdownloader.MyJDownloaderController.askLoginsOnConsole(MyJDownloaderController.java:273)
dic 01 14:24:04 bananapi java[2518]:         at org.jdownloader.api.myjdownloader.MyJDownloaderController.start(MyJDownloaderController.java:125)
dic 01 14:24:04 bananapi java[2518]:         at org.jdownloader.api.myjdownloader.MyJDownloaderController.<init>(MyJDownloaderController.java:112)
dic 01 14:24:04 bananapi java[2518]:         at org.jdownloader.api.myjdownloader.MyJDownloaderController.<clinit>(MyJDownloaderController.java:37)
dic 01 14:24:04 bananapi java[2518]:         ... 1 more

5) Run again in console, again as root:

# /usr/bin/java -Djava.awt.headless=true -jar JDownloader.jar -- -console -norestart

48|org.jdownloader.api.myjdownloader.MyJDownloaderController.log 01/12/22, 14:32:56 - INFO [ jd.http.Browser(setProxySelector) ] -> Use local proxy: org.jdownloader.api.myjdownloader.api.MyJDownloaderAPI$MyJDownloaderAPIBrowser$1@ce44cc wished: org.jdownloader.api.myjdownloader.api.MyJDownloaderAPI$MyJDownloaderAPIBrowser$1@ce44cc
48|UncaughtExceptionHandler.log 01/12/22, 14:32:56 - SEVERE [ jd.SecondLevelLaunch$4(uncaughtException) ] -> Uncaught Exception in: 48=validateLogins|'org.appwork.utils.net.HTTPHeader org.appwork.utils.net.HeaderCollection.add(org.appwork.utils.net.HTTPHeader)'
48|UncaughtExceptionHandler.log 01/12/22, 14:32:56 - SEVERE [ UncaughtExceptionHandler.log ] -> Exception thrown at jd.SecondLevelLaunch$4.uncaughtException(SecondLevelLaunch.java:526):
java.lang.NoSuchMethodError: 'org.appwork.utils.net.HTTPHeader org.appwork.utils.net.HeaderCollection.add(org.appwork.utils.net.HTTPHeader)'
        at jd.http.RequestHeader.put(RequestHeader.java:96)
        at jd.http.RequestHeader.put(RequestHeader.java:100)
        at jd.http.Request.getDefaultRequestHeader(Request.java:457)
        at jd.http.Request.<init>(Request.java:282)
        at jd.http.requests.PostRequest.<init>(PostRequest.java:79)
        at jd.http.Browser.createPostRequest(Browser.java:874)
        at jd.http.Browser.createPostRequest(Browser.java:859)
        at org.jdownloader.api.myjdownloader.api.MyJDownloaderAPI.post(MyJDownloaderAPI.java:84)
        at org.jdownloader.myjdownloader.client.AbstractMyJDClient.cryptedPost(AbstractMyJDClient.java:416)
        at org.jdownloader.myjdownloader.client.AbstractMyJDClient.connect(AbstractMyJDClient.java:376)
        at org.jdownloader.api.myjdownloader.MyJDownloaderController$3.run(MyJDownloaderController.java:332)

|---------------------------Headless Information-------------------------------
|       MyJDownloader
|       Il tuo accesso a 'My.JDownloader' non è corretto.
|       Verifica utente/email e password!
|       Enter y -> Enter Logins
|       Enter n -> Exit JDownloader

--> JD gets stuck here *forever*. Typing correct login/pass doesn't work.
Also cfg/org.jdownloader.api.myjdownloader.MyJDownloaderSettings.json still contains correct login/password.

6) Clean cfg directory, copy backed-up myjd config (that worked before), run again in console as root

# rm -rf ./cfg
# mkdir ./cfg
# cp -f org.jdownloader.api.myjdownloader.MyJDownloaderSettings.json ./cfg/

--> JD still does not work. JD still stucked at login prompt.
The only solution seems to start again from clean installation.

Any thought about this behavior?

I attached a copy of log folder, extracted from lates run.


[1] Systemd service: **External links are only visible to Support Staff****External links are only visible to Support Staff**

[Jiaz]

@Seven.issimo: You have to connect via ssh and not via telnet!
Also your Installation is broken/incompatible. You're trying to use incompatible JDownloader.jar with rest.

java.lang.NoSuchMethodError: 'org.appwork.utils.net.HTTPHeader org.appwork.utils.net.HeaderCollection.add(org.appwork.utils.net.HTTPHeader)'

See https://support.jdownloader.org/Know...r-installation
Whenever you use different/older JDownloader.jar, ALWAYS delete tmp, update folder and the Core.jar file

[Seven.issimo]

Thank you Jiaz for your quick reply but i don't understand what you mean about telnet vs ssh.
Of course I connect to the bananaPi via ssh, but that just takes me to my bash console. From here I used the commands mentioned above.

Maybe you mean that when JD is run in the Systemd environment it doesn't find an ssh terminal? However, theoretically, it can't even find a telnet connection, at least an available tty.

By the way, when I write that I start from a clean installation I mean that I delete everything, the whole folder, including (and not limited to) cfg/ tmp/ all the jar files. Everything.

My issue is: a clean installation works as long is run from bash console.
Just a single run from Systemd environment doesn't work and broke the working installation.

[Jiaz]

Originally Posted by Seven.issimo

My issue is: a clean installation works as long is run from bash console.
Just a single run from Systemd environment doesn't work and broke the working installation.

Thanks for the feedback! This part I did oversaw, sorry!

The systemd file will not work and is prone o fail. ExecStartPre always replaces your up2date JDownloader.jar file with older/incompatible version of it on every start. That breaks your JDownloader installation.
You either update the file and remove/change that part, or use different systemd, for example
https://support.jdownloader.org/Know...tostart-script

You should also remove
Restart=on-failure
and add
Type=simple
RemainAfterExit=yes

because JDownloader does auto restart itself several times on update and systemd else *thinks* JDownloader has crashed/exited but it's still running but just installing the update.

[Seven.issimo]

I edited systemd service according to your suggestions.

A fully clean installation plus backed-up mydj config file, works with the following:

#Restart=on-failure # removed
Type=simple # already default on systemd
RemainAfterExit=yes

But after first JD's autonomous restart, Systemd lost control over JD and output stopped to be directed to systemd journal. Honestly, I really didn't understand where the output was directed... Also StandardOutput= and StandardError= didn't help.

So, my issue seems to have originated by Restart=on-failure
However this setup worked for years flawlessly.

Just to test my old configuration, I reverted it to use Restart= but in combination with JD's -norestart option.
This setup works somehow, maybe not as intended by JD, but it's more systemd-ish

[Jiaz]

Originally Posted by Seven.issimo

output stopped to be directed to systemd journal.

You can disable JDownloader own logging by setting Settings->Advanced Settings->Log.maxlogfilesize to 0 and restart JDownloader. But that way you no longer will be able to send logs via https://support.jdownloader.org/Know...d-session-logs

Originally Posted by Seven.issimo

This setup works somehow, maybe not as intended by JD, but it's more systemd-ish

It would be great to have a good systemd script that can properly handle update cycle.
Maybe you can test your changes with the next updates and would be great if you can share it with community
For example we could update our own kb entry with more *advanced* one
https://support.jdownloader.org/Know...tostart-script

[Jiaz]

@Seven.issimo:
I will try to address your questions.
The initial version of the script was *kinda* okay but it has two major flaws. The first one, the one that caused your problem, is that it always downloaded/replaced JDownloader.jar in ExecStartPre with older/incompatible version.
explanation: JDownloader.jar is the launcher of JDownloader and also contains the update client and some core parts like for example http client. That way you can use any (even many years old) JDownloader.jar file for initial setup/installation of JDownloader because it will auto update itself(JDownloader.jar). So once installed/setup, JDownloader.jar and the rest will be latest available version. But by replacing it with older version (that happens on ExecStartPre) it now is old/incompatible JDownloader.jar that no longer matches rest of your JDownloader installation. I rarly update that JDownloader.jar to newer one because it's not necessary. You did not encounter (or note) issues before because there have been no/only little incompatible changes between JDownloader.jar and rest, but recently I did many major changes and now they are incompatible. So removing that part of the script will solve the main problem with incompatible/broken installation.

Now the next flaw of the script. JDownloader has a two stage update system. Whenever JDownloader wants to update itself (JDownloader.jar) it first creates a copy JDownloader.jar and some other files (eg config) and applies the update to this copy. Then this copy will run some self tests (eg check if still able to reach/download/install updates) and only if all tests are okay, it will signal the running JDownloader installation to stop/exit itself, so it can replace the JDownloader.jar file.
That part a.) will lose the stdout/stderr streams as the process stops and a new process will start and b.) may create problems with start/systemd scripts that do not take proper care of this. So for example JDownloader tries to update itself and main process stops and then systemd might auto restart the process while the update is still in progress which can easily end in a broken installation. Also the JDownloader.pid will only contain PID of main running process but during the time window when main process stops and test process is applying the update to installation, there is no JDownloader.pid and scripts will *think* JDownloader no longer runs and also may show unwanted behaviour with unknown results.

Originally Posted by Seven.issimo

Just to test my old configuration, I reverted it to use Restart= but in combination with JD's -norestart option.

That would be one way to *solve/workaround* the situation with the update cycle AND also make sure that stdout/stderr are always redirected/written to wanted destination.
With the -norestart parameter, JDownloader no longer will auto restart and the whole update will take place on startup of JDownloader but might require multiple restarts to apply/install
all updates.

For example this developer spend time to write a startscript (for his docker image) that properly handles the update cycle situation
github.com/antlafarge/jdownloader

Also see
https://support.jdownloader.org/Know...bedded-devices
https://support.jdownloader.org/Know...r-installation

[Seven.issimo]

@Jiaz:
Thank you for your kind and thorough explanation of how JD update/restart cycles work

I tested a bit more the combination of Restart=on-failure and -norestart option.
It's working surprisingly well: as soon as I hit update in JDApp/MyJD, the running JD instance goes for a clean exit. Systemd gets the exit status and starts a new JD process connecting its output stream to journald.
In "normal" conditions this behaviour seems to work and grant a restart anytime JD needs it.
From my perspective, I see no downsides. But I'm probably still missing out on something. Extensive tests for sure.

However, I'm still looking for a cleaner way to handle that.
I'm looking to **External links are only visible to Support Staff**RestartPreventExitStatus= to let JD restart itself whenever it's supposed to, without triggering Systemd; but let Systemd handle restart in case of true failure.
Obviously, this requires a different exit code whenever JD terminates to update/restart itself.

But the logs/output issue still remains. So, I'm deepening my knowledge of Systemd in managing the output stream when the main PID changes...

Because my objective is not to suppress JD output, rather the opposite: to ensure correct and reliable access to it

[Jiaz]

Originally Posted by Seven.issimo

@Jiaz:
Thank you for your kind and thorough explanation of how JD update/restart cycles work

You're welcome.

Originally Posted by Seven.issimo

From my perspective, I see no downsides. But I'm probably still missing out on something. Extensive tests for sure.

I don't see any downsides other than the restart is done externally by systemd instead of JDownloder itself.

Originally Posted by Seven.issimo

But the logs/output issue still remains.

Hmm,but why do you still have this issue? with -norestart parameter, systemd is the one that starts JDownloader process and gets hold on stdout/stderr.
Only the output from *test update background process* are currently not written to stdout/stderr. see next answer.

Originally Posted by Seven.issimo

....managing the output stream when the main PID changes...
Because my objective is not to suppress JD output, rather the opposite: to ensure correct and reliable access to it

Currently restart does not inherit stdout/stderr from parent process to avoid issues when multiple different processes
write to streams at the same time. The streams are redirected to JDownloader logging framework.
Maybe in future we can change this to inherit streams and also write to JDownloader logs. At the moment
it's not possible to keep/inherit the streams when using JDownloader restart, eg for update cycle or user request
a restart of JDownloader. (tickets are currently not public available)

[Seven.issimo]

Originally Posted by Jiaz

Hmm,but why do you still have this issue? with -norestart parameter, systemd is the one that starts JDownloader process and gets hold on stdout/stderr.
Only the output from *test update background process* are currently not written to stdout/stderr. see next answer.

No issue with that configuration

I just wonder if Systemd is intended/capable of hook the new stdout/stderr if main pid change.

Certainly a change from JD's side, as per issue 90295, would solve the problem.

[Jiaz]

Originally Posted by Seven.issimo

I just wonder if Systemd is intended/capable of hook the new stdout/stderr if main pid change.

systemd can't do anything about this because the child process is started with different streams for stdout/stderr. can't be changed outside the process.

[Jiaz]

Originally Posted by Seven.issimo

Obviously, this requires a different exit code whenever JD terminates to update/restart itself.

Yes, but such a change might also break existing scripts/usage and thus we have to make it optional.
At first I think we should check/work on streams inheritance