Differences

This shows you the differences between two versions of the page.

--- tech:jdownloader_restart [2026/09/20 11:44] – created katsimbris
+++ tech:jdownloader_restart [2026/09/22 21:15] (current) – [Quick Post-Update Check] katsimbris
@@ Line 1: / Line 1: @@
-====== NewsBlur YouTube RSS Fix ======
+====== JDownloader — Updates, Restart & Troubleshooting ======
-===== Problem =====
+JDownloader runs directly on Ubuntu as a **systemd service**. It is **not a Docker container**.
-JDownloader will not restart on its own upon update.
+Permanent installation directory:
-===== Fix =====
+<code>
+/opt/jdownloader
+</code>
-Below is the code to restart:
+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>
-Looking for:
+===== 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>
-Loaded: ... enabled
+/opt/jdownloader/cfg
-Active: inactive (dead)
 </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.