Mike's Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== JDownloader — Updates, Restart & Troubleshooting ======

JDownloader runs directly on Ubuntu as a **systemd service**. It is **not a Docker container**.

Permanent installation directory:

<code>
/opt/jdownloader
</code>

Systemd service:

<code>
jdownloader.service
</code>

The established JDownloader configuration is stored under:

<code>
/opt/jdownloader/cfg
</code>

===== Normal Update Procedure =====

It is okay to initiate a JDownloader update through **MyJDownloader / the web interface**.

JDownloader may stop and restart itself while applying an update. Give it a couple of minutes to complete before intervening.

After an update, verify that the service came back:

<code bash>
systemctl is-active jdownloader
</code>

Normal result:

<code>
active
</code>

For more detail:

<code bash>
sudo systemctl status jdownloader --no-pager
</code>

The running process can also be checked with:

<code bash>
pgrep -af 'java.*JDownloader'
</code>

A healthy installation should show Java running:

<code>
/opt/jdownloader/JDownloader.jar
</code>

For example:

<code>
/usr/bin/java -Djava.awt.headless=true -jar /opt/jdownloader/JDownloader.jar
</code>

===== Starting and Stopping JDownloader =====

Start JDownloader:

<code bash>
sudo systemctl start jdownloader
</code>

Stop JDownloader:

<code bash>
sudo systemctl stop jdownloader
</code>

Restart JDownloader:

<code bash>
sudo systemctl restart jdownloader
</code>

Check whether it is running:

<code bash>
systemctl is-active jdownloader
</code>

Detailed status:

<code bash>
sudo systemctl status jdownloader --no-pager
</code>

===== If JDownloader Does Not Restart =====

First check its status:

<code bash>
sudo systemctl status jdownloader --no-pager
</code>

If the service is simply stopped, try starting it:

<code bash>
sudo systemctl start jdownloader
</code>

Then verify:

<code bash>
systemctl is-active jdownloader
</code>

If the service fails again, **do not immediately reinstall JDownloader, delete files, or replace the configuration**.

Check that the main application files still exist:

<code bash>
ls -lh /opt/jdownloader/JDownloader.jar /opt/jdownloader/Core.jar
</code>

Check whether another JDownloader Java process is already running:

<code bash>
pgrep -af 'java.*JDownloader'
</code>

If ''JDownloader.jar'' is missing or the service still will not start, stop here and investigate the updater logs before changing the installation.

===== Configuration =====

The established JDownloader configuration is stored under:

<code>
/opt/jdownloader/cfg
</code>

This directory contains the settings used by the established installation.

**Preserve this directory during troubleshooting or recovery.**

Do not replace it with the configuration from a newly created or temporary JDownloader installation.

===== .jd_home Warning =====

During an update failure, troubleshooting, or recovery, another JDownloader installation may appear under:

<code>
/home/mike/.jd_home
</code>

Do **not** assume this is the permanent installation.

The systemd-managed installation is:

<code>
/opt/jdownloader
</code>

A ''.jd_home'' installation may contain newly downloaded JDownloader application files while having a new or default configuration.

In particular, do **not** replace:

<code>
/opt/jdownloader/cfg
</code>

with:

<code>
/home/mike/.jd_home/cfg
</code>

unless there is a specific, verified reason to do so.

The presence of newer ''JDownloader.jar'' or ''Core.jar'' files under ''.jd_home'' does not by itself mean that JDownloader should be moved there.

===== Logs =====

Show the most recent systemd log entries:

<code bash>
journalctl -u jdownloader -n 100 --no-pager
</code>

Follow the service log live:

<code bash>
journalctl -u jdownloader -f
</code>

Press ''Ctrl+C'' to stop following the log.

JDownloader's own logs are stored under:

<code>
/opt/jdownloader/logs
</code>

These logs can be useful when diagnosing an update or restart failure.

===== September 21, 2026 Update Failure =====

On September 21, 2026, an update initiated through JDownloader resulted in the service becoming unavailable.

Investigation established that JDownloader was operating from the correct installation:

<code>
/opt/jdownloader
</code>

At approximately 13:28, JDownloader deliberately initiated its normal update/restart process and launched itself with:

<code>
JDownloader.jar -forceupdate
</code>

The updater continued to operate against the correct ''/opt/jdownloader'' installation.

Its updater self-test used:

<code>
/opt/jdownloader/tmp/update/self/JDU/JDownloader.jar
</code>

and reported:

<code>
Validate: OK
SelfTest Results: OK
Self Update successful
</code>

JDownloader subsequently performed a normal shutdown. At 13:31:59, systemd recorded:

<code>
jdownloader.service: Deactivated successfully.
</code>

However, by the next attempt to start the service at 13:32:55:

<code>
/opt/jdownloader/JDownloader.jar
</code>

was no longer available.

Systemd therefore reported:

<code>
Error: Unable to access jarfile /opt/jdownloader/JDownloader.jar
</code>

and subsequent automatic restart attempts failed for the same reason.

The exact reason the updater failed to leave a usable replacement ''JDownloader.jar'' in ''/opt/jdownloader'' was not established.

The investigation **did not find evidence that initiating the update through MyJDownloader was incorrect**, nor did it establish systemd's ''Restart=on-failure'' setting as the cause.

A separate fresh JDownloader installation was discovered under:

<code>
/home/mike/.jd_home
</code>

It contained newer application files, but its ''cfg'' directory contained only a small/default configuration.

The established configuration under:

<code>
/opt/jdownloader/cfg
</code>

was therefore preserved.

For this specific recovery, fresh copies of ''JDownloader.jar'' and ''Core.jar'' were restored to ''/opt/jdownloader'' while retaining the existing ''cfg'' directory.

After recovery:

<code bash>
systemctl is-active jdownloader
</code>

returned:

<code>
active
</code>

and the running Java process again used:

<code>
/opt/jdownloader/JDownloader.jar
</code>

MyJDownloader also reconnected using the existing configuration.

**Important:** Copying application files from ''.jd_home'' was an incident-specific recovery procedure. It should not be treated as the normal JDownloader update procedure.

===== Quick Post-Update Check =====

After initiating a JDownloader update or restart, wait a couple of minutes and run:

<code bash>
systemctl is-active jdownloader
ls -lh /opt/jdownloader/JDownloader.jar
cat /opt/jdownloader/JDownloader.pid
pgrep -af 'java.*JDownloader'
</code>

Normal results should show:

* ''jdownloader'' is ''active''
* ''/opt/jdownloader/JDownloader.jar'' exists
* ''JDownloader.pid'' contains a process ID
* the same process ID is running Java with ''/opt/jdownloader/JDownloader.jar''

If ''JDownloader.jar'' is missing, **do not repeatedly restart the service, reinstall JDownloader, or replace ''/opt/jdownloader/cfg''**.

Stop the service first:

<code bash>
sudo systemctl stop jdownloader
</code>

Then investigate the updater state before restoring any files.