[Suggestion] Add Healthcheck & Autoheal compatibility

[pchristod]

Hi,

as this is one of the Docker Images I'm using all the time I've been thinking of a possible enhancement for this container: Healthchecks in case of a network failure/outage I'm actually thinking of something similiar as to how the Transmission Container does it https://github.com/haugene/docker-transmission-openvpn Their healthcheck consists of two things:

1) define a healthcheck (every minute) in the Dockerfile pointing to a script which pings a specific host (in that case google.com) -> if this returns negative it's assumed there is a network failure 2) define a new label (LABEL autoheal=true) in the Dockerfile adding compatibility with https://hub.docker.com/r/willfarrell/autoheal/

This way in case of a network failure (whichever reason) the Container goes into "unhealthy" state itself. In addition if you choose to run the autoheal container from 2) alongside the unhealthy state gets picked up eventually. It will actually auto restart the unhealthy container giving it a chance to recover.

Maybe this is something that could be interesting/helpful?

[pchristod]

Hi,

just something to note after a while this issue is open. If you happen to use Docker Compose you can try to specify the healtheck yourself. As an example, I'm running this container behind the transmission-openvpn container so besides 'network_mode' and 'depends_on' which would point to the transmission container I'm adding the following:

   healthcheck: # Here you will check if transmission is reachable from the JDownloader container via localhost
        test: curl -f http://${RPCUSERNAME}:${RPCPASSWORD}@localhost:9091 || exit 1
        interval: 5m00s
        timeout: 10s
        retries: 2
    labels:
        - autoheal=true

This way it will curl to check if transmission container is reachable (which would be the same network since they are sharing) -> if not it will go in unhealthy state which will be picked up by the autoheal container linked in the OP and restart itself. If you don't use another container like I do you can modify the command and ping (instead of curl) any website for example to check network connectivity instead which should also work. But I haven't tried that yet.

[jlesage]

I'm not sure I see the benefit of having a health check for this container. If, for example, you can't ping a website, will restarting the JD container really fix the (network) issue ? Heart checks are usually used by a container to verify its own resources.

[pchristod]

Hi,

@jlesage yeah, I can totally understand the reasoning and I guess you are right. Initially I made this request because I'm using your container behind a VPN Container and in that case it is useful to have an indication when that host network is having issues and trigger an automatic restart so both containers can work again.

But in the meantime I found a good solution with just using compose (seen in my previous comment). This could easily be adapted by others with similar use cases. As said I would agree that using the container in standalone mode a healthcheck is less useful.

I would leave the decision to you, if you don't see usefulness for such a feature the request can be closed :) Thank you!

[JamesDavisMakes]

Just to jump in, using this with a vpn (like gluetun or nordlynx) makes sense. It also makes sense in general -- i.e. sometimes jDownloader can be slow to load or MyJDownloader is unresponsive and simply restarting the container can grease the wheels, so to speak. The ability to have it restart automagically before you realize it's an issue can be valuable.

I think the more realistic use case for me is if you ping jdownloader's web interface and it takes forever to load, and times out multiple times, I think that's a fair reason to restart the container.

That said, to better support autoheal and similar tools, I would recommend creating a /status or /ping API call. For instance, here's an example from Sonarr, Radarr, etc.:

http://sonarr:8989/ping

{
    "status": "OK"
}

Literally that's it, or it throws an HTTP error. And here's an example of how I would use it for JD:

gluetun:
    ports:
      # jDownloader
      - ${MACHINE_IP}:3129:3129
      - ${MACHINE_IP}:5800:5800

jdownloader-2:
    depends_on:
      - gluetun
    healthcheck:
      test: curl -sf http://localhost:5800/ping --stderr - | grep OK || exit 1
      interval: 5m
      timeout: 30s

This is something I wish we had for the Calibre docker image, which is VNC based and shits the bed often enough to need to be restarted. As we speak, mine just had an error where VNC loaded but calibre didn't and restarting manually just fixed it. If it had a status page that returned server disconnected or an internal VNC-related error, my life would be a lot easier.

I wouldn't call this a blocker by any means, but there's merit behind downloaders like JD or bittorrent clients autohealing themselves, especially alongside VPNs. More of a quality of life feature.

p.s. I found this page by googling something like "jdownloader gluetun autoheal" 😅