starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Update either documentation or docker file for audiobookshelf health test #2810

New Issue
Open
opened 2026-04-25 00:10:50 +02:00 by adam · 6 comments
adam commented 2026-04-25 00:10:50 +02:00
Owner
Copy Link
Copy Source

Originally created by @heinrich-k on GitHub (May 30, 2025).

Type of Enhancement

Documentation

Describe the Feature/Enhancement

Hi,
there is documentation for audiobookshelf as docker container under
https://github.com/advplyr/audiobookshelf/pkgs/container/audiobookshelf
but it is insufficient.

There is no valid documentation on how to set up a health check in the compose.yml file to have docker check the audiobookshelf container.
Apparently there is something like http://localhost:13378/healthcheck but it can't be curl-ed since there is no curl in the official audiobookshelf container and no sufficient other documentation, on how to use it.

Please, elaborate.

Best regards
Heinrich

Why would this be helpful?

I want to setup the healthcheck for the docker container.

Future Implementation (Screenshot)

Something like this should work in the docker compose.yml
healthcheck:
test: "curl -f --fail http://localhost:13378/healthcheck || exit 1"
interval: 30s
timeout: 3s
retries: 3

Audiobookshelf Server Version

v2.23.0 (docker)

Current Implementation (Screenshot)

No response

Originally created by @heinrich-k on GitHub (May 30, 2025). ### Type of Enhancement Documentation ### Describe the Feature/Enhancement Hi, there is documentation for audiobookshelf as docker container under https://github.com/advplyr/audiobookshelf/pkgs/container/audiobookshelf but it is insufficient. There is no valid documentation on how to set up a health check in the compose.yml file to have docker check the audiobookshelf container. Apparently there is something like http://localhost:13378/healthcheck but it can't be curl-ed since there is no curl in the official audiobookshelf container and no sufficient other documentation, on how to use it. Please, elaborate. Best regards Heinrich ### Why would this be helpful? I want to setup the healthcheck for the docker container. ### Future Implementation (Screenshot) Something like this should work in the docker compose.yml healthcheck: test: "curl -f --fail http://localhost:13378/healthcheck || exit 1" interval: 30s timeout: 3s retries: 3 ### Audiobookshelf Server Version v2.23.0 (docker) ### Current Implementation (Screenshot) _No response_
adam added the enhancement label 2026-04-25 00:10:50 +02:00
adam commented 2026-04-25 00:10:50 +02:00
Author
Owner
Copy Link
Copy Source

@DieselTech commented on GitHub (May 30, 2025):

Blindly running health checks in docker without having a way to fix any issues isn't recommended. Just restarting the "failing" container over and over when the health check fails is not a proper solution. curl is no longer included in the docker image because ABS does not use the program at all. It is more beneficial to trim out excess space from the image and shrink it so the greatest number of people get benefit from it.

@DieselTech commented on GitHub (May 30, 2025): Blindly running health checks in docker without having a way to fix any issues isn't recommended. Just restarting the "failing" container over and over when the health check fails is not a proper solution. `curl` is no longer included in the docker image because ABS does not use the program at all. It is more beneficial to trim out excess space from the image and shrink it so the greatest number of people get benefit from it.
adam commented 2026-04-25 00:10:50 +02:00
Author
Owner
Copy Link
Copy Source

@jeffreyswiggins commented on GitHub (Jun 3, 2025):

Blindly running health checks in docker without having a way to fix any issues isn't recommended. Just restarting the "failing" container over and over when the health check fails is not a proper solution. curl is no longer included in the docker image because ABS does not use the program at all. It is more beneficial to trim out excess space from the image and shrink it so the greatest number of people get benefit from it.

While I get removing bloat or unused "things" from containers where ever possible, your assertion several times in comments is that this is a waste of time because someone uses a healthcheck but does not monitor it. You assume no one uses something to monitor those results.

Guess I will look into another product like LogForge to see if I can start using it, because if your "assertion" is the new normal then we need "waste" resources spinning up a container to monitor all the containers that we can no longer get a valid healthcheck from.

Not trying to be snarky, but your answer takes a lot of liberties with how other people run their docker containers and how they should or should not monitor them.

I love this container and use it a lot so most of the time I never see any problems with it, but noticed the unhealthy status myself as I have (now had) the healthcheck in my yaml compose and had not had time to see why it was stating that..... today I looked and found that "curl" failed and then found this thread....

Appreciate all the hard work that goes into this.

@jeffreyswiggins commented on GitHub (Jun 3, 2025): > Blindly running health checks in docker without having a way to fix any issues isn't recommended. Just restarting the "failing" container over and over when the health check fails is not a proper solution. `curl` is no longer included in the docker image because ABS does not use the program at all. It is more beneficial to trim out excess space from the image and shrink it so the greatest number of people get benefit from it. While I get removing bloat or unused "things" from containers where ever possible, your assertion several times in comments is that this is a waste of time because someone uses a healthcheck but does not monitor it. You assume no one uses something to monitor those results. Guess I will look into another product like LogForge to see if I can start using it, because if your "assertion" is the new normal then we need "waste" resources spinning up a container to monitor all the containers that we can no longer get a valid healthcheck from. Not trying to be snarky, but your answer takes a lot of liberties with how other people run their docker containers and how they should or should not monitor them. I love this container and use it a lot so most of the time I never see any problems with it, but noticed the unhealthy status myself as I have (now had) the healthcheck in my yaml compose and had not had time to see why it was stating that..... today I looked and found that "curl" failed and then found this thread.... Appreciate all the hard work that goes into this.
adam commented 2026-04-25 00:10:51 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jun 3, 2025):

Blindly running health checks in docker without having a way to fix any issues isn't recommended. Just restarting the "failing" container over and over when the health check fails is not a proper solution. curl is no longer included in the docker image because ABS does not use the program at all. It is more beneficial to trim out excess space from the image and shrink it so the greatest number of people get benefit from it.

While I get removing bloat or unused "things" from containers where ever possible, your assertion several times in comments is that this is a waste of time because someone uses a healthcheck but does not monitor it. You assume no one uses something to monitor those results.

Guess I will look into another product like LogForge to see if I can start using it, because if your "assertion" is the new normal then we need "waste" resources spinning up a container to monitor all the containers that we can no longer get a valid healthcheck from.

Not trying to be snarky, but your answer takes a lot of liberties with how other people run their docker containers and how they should or should not monitor them.

I love this container and use it a lot so most of the time I never see any problems with it, but noticed the unhealthy status myself as I have (now had) the healthcheck in my yaml compose and had not had time to see why it was stating that..... today I looked and found that "curl" failed and then found this thread....

Appreciate all the hard work that goes into this.

You can use wget to do the health check

@advplyr commented on GitHub (Jun 3, 2025): > > Blindly running health checks in docker without having a way to fix any issues isn't recommended. Just restarting the "failing" container over and over when the health check fails is not a proper solution. `curl` is no longer included in the docker image because ABS does not use the program at all. It is more beneficial to trim out excess space from the image and shrink it so the greatest number of people get benefit from it. > > While I get removing bloat or unused "things" from containers where ever possible, your assertion several times in comments is that this is a waste of time because someone uses a healthcheck but does not monitor it. You assume no one uses something to monitor those results. > > Guess I will look into another product like LogForge to see if I can start using it, because if your "assertion" is the new normal then we need "waste" resources spinning up a container to monitor all the containers that we can no longer get a valid healthcheck from. > > Not trying to be snarky, but your answer takes a lot of liberties with how other people run their docker containers and how they should or should not monitor them. > > I love this container and use it a lot so most of the time I never see any problems with it, but noticed the unhealthy status myself as I have (now had) the healthcheck in my yaml compose and had not had time to see why it was stating that..... today I looked and found that "curl" failed and then found this thread.... > > Appreciate all the hard work that goes into this. You can use `wget` to do the health check
adam commented 2026-04-25 00:10:51 +02:00
Author
Owner
Copy Link
Copy Source

@DieselTech commented on GitHub (Jun 3, 2025):

You can use wget to do the health check

Exactly that. It isn't that people are being prevented from doing health checks should they want to, is it that the default configuration out of the box (IMO) shouldn't be configured to do them when the vast majority of people don't use it. If it is something you want, you can add it yourself. Burning in the health check into the dockerfile forces it on people who don't have a way of using it. Whereas if you just add the health check on your own inside of your private compose file then it makes it a "you" thing. The project doesn't need to maintain or document features that it isn't using for services outside of its scope.

@DieselTech commented on GitHub (Jun 3, 2025): > You can use `wget` to do the health check Exactly that. It isn't that people are being prevented from doing health checks should they want to, is it that the default configuration out of the box (IMO) shouldn't be configured to do them when the vast majority of people don't use it. If it is something you want, you can add it yourself. Burning in the health check into the dockerfile forces it on people who don't have a way of using it. Whereas if you just add the health check on your own inside of your private compose file then it makes it a "you" thing. The project doesn't need to maintain or document features that it isn't using for services outside of its scope.
adam commented 2026-04-25 00:10:51 +02:00
Author
Owner
Copy Link
Copy Source

@andrey-kondratov commented on GitHub (Jun 6, 2025):

I am not an expert in reverse proxies set up, but it seems when you restart an upstream such as audiobookshelf running behind nginx, the latter would start responding with 502 Bad Gateway errors. And unless you want to reconfigure healthcheck on Nginx (which has its downsides), it helps to have a config like this:

services:
  audiobookshelf:
    # ...
    restart: unless-stopped
    healthcheck:
      test: wget --no-verbose --tries=1 --spider http://localhost || exit 1
      interval: 5m
      timeout: 3s
      start_period: 30s
      start_interval: 1s
  nginx:
    # ...
    depends_on:
      audiobookshelf:
        condition: service_healthy
        restart: true

This way both audiobookshelf is checked (although not very often), and you don't have to reconfigure nginx defaults.

If ABS docs mentions nginx in the docs, maybe there is a need to ensure the suggested nginx.conf is resilient?

@andrey-kondratov commented on GitHub (Jun 6, 2025): I am not an expert in reverse proxies set up, but it seems when you restart an upstream such as audiobookshelf running behind nginx, the latter would start responding with 502 Bad Gateway errors. And unless you want to reconfigure healthcheck on Nginx (which [has](https://serverfault.com/questions/1166485/how-to-configure-nginx-to-start-if-upstream-host-is-down-when-using-upstream-blo) its [downsides](https://stackoverflow.com/questions/66312816/nginx-shows-bad-gateway-when-upstream-server-restart-and-not-back-to-normal)), it helps to have a config like this: ```yml services: audiobookshelf: # ... restart: unless-stopped healthcheck: test: wget --no-verbose --tries=1 --spider http://localhost || exit 1 interval: 5m timeout: 3s start_period: 30s start_interval: 1s nginx: # ... depends_on: audiobookshelf: condition: service_healthy restart: true ``` This way both `audiobookshelf` is checked (although not very often), and you don't have to reconfigure nginx defaults. If ABS docs [mentions](https://github.com/advplyr/audiobookshelf/blob/master/readme.md#nginx-reverse-proxy) nginx in the docs, maybe there is a need to ensure the suggested nginx.conf is resilient?
adam commented 2026-04-25 00:10:51 +02:00
Author
Owner
Copy Link
Copy Source

@jeffreyswiggins commented on GitHub (Jun 6, 2025):

I am not an expert in reverse proxies set up, but it seems when you restart an upstream such as audiobookshelf running behind nginx, the latter would start responding with 502 Bad Gateway errors. And unless you want to reconfigure healthcheck on Nginx (which has its downsides), it helps to have a config like this:

services:
audiobookshelf:
# ...
restart: unless-stopped
healthcheck:
test: wget --no-verbose --tries=1 --spider http://localhost || exit 1
interval: 5m
timeout: 3s
start_period: 30s
start_interval: 1s
nginx:
# ...
depends_on:
audiobookshelf:
condition: service_healthy
restart: true
This way both audiobookshelf is checked (although not very often), and you don't have to reconfigure nginx defaults.

If ABS docs mentions nginx in the docs, maybe there is a need to ensure the suggested nginx.conf is resilient?

This makes sense and I like the setup, I do not personal use the “on premise” proxy server anymore and utilize Cloudflare Zero Trust Tunnels cause I like that security better…. I know it is no hosted and they could potentially “see the traffic” but the latter is no consequences to me for what I am doing.

@jeffreyswiggins commented on GitHub (Jun 6, 2025): > I am not an expert in reverse proxies set up, but it seems when you restart an upstream such as audiobookshelf running behind nginx, the latter would start responding with 502 Bad Gateway errors. And unless you want to reconfigure healthcheck on Nginx (which [has](https://serverfault.com/questions/1166485/how-to-configure-nginx-to-start-if-upstream-host-is-down-when-using-upstream-blo) its [downsides](https://stackoverflow.com/questions/66312816/nginx-shows-bad-gateway-when-upstream-server-restart-and-not-back-to-normal)), it helps to have a config like this: > > services: > audiobookshelf: > # ... > restart: unless-stopped > healthcheck: > test: wget --no-verbose --tries=1 --spider http://localhost || exit 1 > interval: 5m > timeout: 3s > start_period: 30s > start_interval: 1s > nginx: > # ... > depends_on: > audiobookshelf: > condition: service_healthy > restart: true > This way both `audiobookshelf` is checked (although not very often), and you don't have to reconfigure nginx defaults. > > If ABS docs [mentions](https://github.com/advplyr/audiobookshelf/blob/master/readme.md#nginx-reverse-proxy) nginx in the docs, maybe there is a need to ensure the suggested nginx.conf is resilient? This makes sense and I like the setup, I do not personal use the “on premise” proxy server anymore and utilize Cloudflare Zero Trust Tunnels cause I like that security better…. I know it is no hosted and they could potentially “see the traffic” but the latter is no consequences to me for what I am doing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2810
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?