Web service tries to start before app is ready #152

New Issue

Open

opened 2026-10-22 08:08:25 +00:00 by amras · 7 comments

amras commented 2026-10-22 08:08:25 +00:00

Owner

Copy Link

Copy Source

Current behavior: The app service takes several minutes to start and reach a healthy state. In the meantime, web attempts deployment over 10 times, reporting "unhealthy" each time.

Proposed solution: The depends-on attribute is already set on web. We should probably switch from the short syntax

depends-on:
 - app

to the long syntax

depends-on:
 app:
  - condition: service_healthy

More info on the compose file reference

**Current behavior**: The `app` service takes several minutes to start and reach a healthy state. In the meantime, `web` attempts deployment over 10 times, reporting "unhealthy" each time. **Proposed solution**: The `depends-on` attribute is already set on `web`. We should probably switch from the short syntax ```yaml depends-on: - app ``` to the long syntax ```yaml depends-on: app: - condition: service_healthy ``` [More info on the compose file reference](https://docs.docker.com/reference/compose-file/services/#depends_on)

amras changed title from Fix "depends-on" order to Web service starts before app is ready 2026-10-22 08:08:56 +00:00

amras changed title from Web service starts before app is ready to Web service tries to start before app is ready 2026-10-22 08:09:08 +00:00

amras commented 2026-10-22 08:10:01 +00:00

Author

Owner

Copy Link

Copy Source

Might be good to do a full pass of dependencies and ensure other services don't start too early either.

Might be good to do a full pass of dependencies and ensure other services don't start too early either.

amras added the bug label 2026-10-22 08:13:17 +00:00

ineiti commented 2026-10-22 08:16:19 +00:00

Owner

Copy Link

Copy Source

Did you try this out? I always thought (and also experienced, IIRC), that docker swarm ignores depends-on. Here is an old documentation which states so: https://github.com/docker/compose/blob/v1/docs/Compose%20file%20reference%20(legacy)/version-3.md#depends_on

Claude proposes this instead:

Fixes that do work in Swarm:

• Make nginx look up the address when a request arrives, not at startup. Use Docker's internal DNS server and a variable, so nginx starts even if app isn't up yet:
  resolver 127.0.0.11 valid=10s;
  set $php_upstream {{ env "STACK_NAME" }}_app:9000;
  fastcgi_pass $php_upstream;
  This replaces the upstream php-handler block. Until app is up, requests get a 502 instead of nginx crashing.
• Give web's healthcheck the same time as app's: set start_period: 15m for web too. Or make it only check nginx itself, e.g. a static location /nginx-health { return 200; }, so it
  stops depending on app.
• Optionally, add a wait loop to web's entrypoint that waits until app:9000 is reachable before starting nginx. That's the usual Swarm stand-in for depends_on.

Did you try this out? I always thought (and also experienced, IIRC), that docker swarm ignores `depends-on`. Here is an old documentation which states so: https://github.com/docker/compose/blob/v1/docs/Compose%20file%20reference%20(legacy)/version-3.md#depends_on Claude proposes this instead: Fixes that do work in Swarm: - Make nginx look up the address when a request arrives, not at startup. Use Docker's internal DNS server and a variable, so nginx starts even if app isn't up yet: resolver 127.0.0.11 valid=10s; set $php_upstream {{ env "STACK_NAME" }}_app:9000; fastcgi_pass $php_upstream; This replaces the upstream php-handler block. Until app is up, requests get a 502 instead of nginx crashing. - Give web's healthcheck the same time as app's: set start_period: 15m for web too. Or make it only check nginx itself, e.g. a static location /nginx-health { return 200; }, so it stops depending on app. - Optionally, add a wait loop to web's entrypoint that waits until app:9000 is reachable before starting nginx. That's the usual Swarm stand-in for depends_on.

ineiti added the question label 2026-10-22 08:18:34 +00:00

amras commented 2026-10-22 08:27:45 +00:00

Author

Owner

Copy Link

Copy Source

Oh, interesting. The new docs don't mention the swarm limitation - I wonder if it's been removed. If I find the time I'll run some experiments, unless someone else beats me to it.

None of the workarounds you propose spark joy. If the swarm limitation is still applicable, my vote would be to leave it as-is, and just let web spin its tires for a few minutes.

Oh, interesting. The new docs don't mention the swarm limitation - I wonder if it's been removed. If I find the time I'll run some experiments, unless someone else beats me to it. None of the workarounds you propose spark joy. If the swarm limitation is still applicable, my vote would be to leave it as-is, and just let `web` spin its tires for a few minutes.

ineiti commented 2026-10-22 08:43:09 +00:00

Owner

Copy Link

Copy Source

According to https://github.com/docker/docs/issues/21079 they removed it, as docker swarm is no longer officially part of docker...

So we should perhaps remove all depends_on to make sure nobody thinks this is actually doing something useful :)

Now that I think about it: usually when I deploy nextccloud, the app is started after all other services - I wonder if that's a coincidence, or what's happening there?

According to https://github.com/docker/docs/issues/21079 they removed it, as docker swarm is no longer officially part of docker... So we should perhaps remove all `depends_on` to make sure nobody thinks this is actually doing something useful :) Now that I think about it: usually when I `deploy` nextccloud, the `app` is started after all other services - I wonder if that's a coincidence, or what's happening there?

amras commented 2026-10-22 08:55:50 +00:00

Author

Owner

Copy Link

Copy Source

Looking through some more docs, looks like "all the services keep restarting until the stack works" is the design intent in swarm.

Agree that we should remove depends_on from the recipe. Maybe even make a note in the maintainer's handbook.

Looking through some more docs, looks like "all the services keep restarting until the stack works" is the design intent in swarm. Agree that we should remove `depends_on` from the recipe. Maybe even make a note in the maintainer's handbook.

amras commented 2026-10-22 08:57:46 +00:00

Author

Owner

Copy Link

Copy Source

Now that I think about it: usually when I deploy nextccloud, the app is started after all other services - I wonder if that's a coincidence, or what's happening there?

I assume that's a combination of the app having an internal wait for the db connection, and nextcloud just being a bit bloated.

> Now that I think about it: usually when I deploy nextccloud, the app is started after all other services - I wonder if that's a coincidence, or what's happening there? I assume that's a combination of the app having an internal wait for the db connection, and nextcloud just being a bit bloated.

ineiti commented 2026-10-22 11:39:51 +00:00

Owner

Copy Link

Copy Source

I assume that's a combination of the app having an internal wait for the db connection, and nextcloud just being a bit bloated.

and mental bias - I just redeployed, and it was another service starting as the latest...

> I assume that's a combination of the app having an internal wait for the db connection, and nextcloud just being a bit bloated. and mental bias - I just redeployed, and it was another service starting as the latest...

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

renovate/ghcr.io-nextcloud-releases-whiteboard-2.x

kc_stable

mitigations_php

version_35

after-pr-143-cherry-pick

pr-143-review

renovate/docker.elastic.co-elasticsearch-elasticsearch-9.x

pr-125-v2

pr-125

renovate/mariadb-13.x

trusted-domains

renovate/pgautoupgrade-pgautoupgrade-18.x

pr-15.2.0+34.0.2-fpm

pr-14.2.0+33-fpm

fix-pgautoupgrade-max-connections

upload-limit

feature/imaginary

15.0.1+34.0.5-fpm

15.0.0+34.0.5-fpm

14.6.0+33-fpm

14.5.1+33.0.9-fpm

14.5.0+33.0.9-fpm

14.4.0+33.0.9-fpm

14.3.0+33.0.9-fpm

14.2.0+33.0.9-fpm

14.1.2+33.0.9-fpm

14.1.1+33.0.8-fpm

14.1.0+33.0.7-fpm

14.0.1+33.0.7-fpm

14.0.0+33.0.7-fpm

13.2.0+32-fpm

13.1.5+32.0.13-fpm

13.1.4+32.0.13-fpm

13.1.3+32.0.13-fpm

13.1.2+32.0.13-fpm

13.1.1+32.0.12-fpm

13.1.0+32.0.11-fpm

13.0.1+32.0.3-fpm

13.0.0+32.0.3-fpm

12.1.0+31.0.6-fpm

12.0.1+31.0.6-fpm

12.0.0+31.0.6-fpm

11.4.0+30.0.6-fpm

11.4.0+30.0.10-fpm

11.3.0+30.0.6-fpm

11.2.0+30.0.6-fpm

11.1.0+30.0.6-fpm

11.0.1+30.0.4-fpm

11.0.0+30.0.4-fpm

10.0.0+30.0.4-fpm

9.2.0+29.0.8-fpm

6.0.11+28.0.10-fpm

6.0.10+28.0.10-fpm

6.0.9+28.0.10-fpm

9.1.2+29.0.5-fpm

6.0.8+28.0.5-fpm

6.0.7+28.0.5-fpm

9.1.0+29.0.5-fpm

9.0.0+29.0.5-fpm

6.0.6+28.0.5-fpm

8.0.1+29.0.3-fpm

8.0.0+29.0.1-fpm

7.0.3+29.0.1-fpm

6.0.5+28.0.5-fpm

7.0.2+29.0.1-fpm

7.0.1+29.0.1-fpm

7.0.0+29.0.0-fpm

6.0.4+28.0.5-fpm

6.0.3+28.0.5-fpm

6.0.2+28.0.5-fpm

5.0.3+27.0.1-fpm

6.0.1+28.0.2-fpm

6.0.0+28.0.1-fpm

5.2.0+27.1.5-fpm

5.1.1+27.1.5-fpm

5.1.0+27.1.3-fpm

5.0.2+27.0.1-fpm

5.0.1+27.0.1-fpm

5.0.0+27.0.0-fpm

4.0.7+26.0.2-fpm

4.0.6+26.0.2-fpm

4.0.5+26.0.2-fpm

4.0.4+26.0.2-fpm

4.0.3+26.0.2-fpm

4.0.2+26.0.2-fpm

4.0.1+26.0.1-fpm

4.0.0+26.0.1-fpm

3.3.2+25.0.6-fpm

3.3.1+25.0.5-fpm

3.3.0+25.0.5-fpm

3.2.0+25.0.4-fpm

3.1.2+25.0.4-fpm

3.1.1+25.0.1-fpm

3.1.0+25.0.1-fpm

3.0.1+25.0.1-fpm

3.0.0+25.0.1-fpm

2.1.4+24.0.6-fpm

2.1.3+24.0.5-fpm

2.1.2+24.0.3-fpm

2.1.1+24.0.2-fpm

2.1.0+24.0.0-fpm

2.0.0+23.0.4-fpm

1.0.0+23.0.1-fpm

Labels

Clear labels

bug

Something is not working

documentation

For issues that are calling out documentation gap

duplicate

This issue or pull request already exists

enhancement

New feature

help wanted

Need some help

invalid

Something is wrong

question

More information is needed

wontfix

This won't be fixed

No labels bug question

Milestone

No items

No Milestone

Assignees

Clear assignees

3wordchant aadil (Aadil Ayub) abra-bot (Abra Bot) ammaratef45 amras (Sarma) BornDeleuze (Born Deleuze) Brooke carla cas (Cassowary) coopcloud dannygroenewegen (Danny Groenewegen) decentral1se (d1) fauno (fauno) hex (Josh Dukes) ineiti (Linus Gasser) javielico (Javielico) jjsfunhouse kawaiipunk (KawaiiPunk) knoflook moosemower moritz notplants oxaliq (sorrel) p4u1 (p4u1) renovate-bot (Comrade Renovate Bot) simon stevensting (stevensting) trav (Trav Fryer) yksflip

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/nextcloud#152