bug report: `supervisord` ignores retry limit when `startsecs=0`

Offen
  • Stimmt etwas nicht?
#4,708 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
docker, shell
Bereich
devops, infrastructure

Rechercherichtung

Beginnen Sie mit dem Lesen der vier Stellen, an denen startsecs=0 gesetzt wird, insbesondere supervisor/conf.d/dms-services.conf und supervisor/conf.d/saslauth.conf, und untersuchen Sie anschließend den Startablauf in scripts/startup/daemons-stack.sh und scripts/startup/setup.d/fetchmail.sh. Prüfen Sie zeitkritische Tests, während Sie die Verwendung von supervisorctl nachverfolgen. Die Arbeit ist abgeschlossen, wenn fehlgeschlagene Dienste das Wiederholungslimit einhalten und der Start supervisorctl start effizient aufrufen kann, ohne eine unzumutbare Verzögerung des Containers.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

area/scripts bug/confirmed kind/bug/report meta/help wanted stale-bot/ignore
  • startsecs=0 (default is 1 second) has been used in DMS since supervisord was added into the project back in Aug 2017. It determines how long a service needs to be running before it's moved from the STARTING to RUNNING state.
  • startretries=3 (default) is the number of retry attempts before the service is marked with the status FATAL and is no longer restarted. This only applies during the STARTING status prior to being assigned RUNNING (unless the service fails in this state, where supervisord will restart it, placing it back into STARTING status).

Due to the above mismatch, a service immediately enters RUNNING status, and if it then crashes with an uptime of 0 seconds the startsecs value will immediately switch from STARTING to RUNNING, there is no opportunity to increment the restart counter so it is always reset once the service is marked as RUNNING again.

For a reliable healthcheck script (as is being pursued here), we should correct this.

Known examples of this behaviour observed in DMS:

A side-effect of changing to startsecs = 1 is supervisorctl start (and potentially other sub-commands) are blocking with that delay. Any usage within DMS scripts would be affected by such, most notably during container startup where we sequentially invoke the start command per service individually. In the startup case we should probably collect the services to start and provide them all to a single supervisorctl start ... command, that should keep the impact low. Some container deployments may have a healthcheck policy that kills/restarts the container under an unhealthy state, so let's ensure the downtime is low 😅

Locations for startsecs=0 => startsecs=1 (or deletion):

Refactor invoking supervisorctl start to single use in scripts/startup/daemons-stack.sh:

Either that or a more extensive refactor. This change may also impact the test suite if any test cases are aggressive with timing expectations.

Vorherrschende Sprache
Shell
Sterne
19.7k
Forks
2.1k
Ø Merge
3 T. 29 Min.
Gemergte PRs (30 T.)
12

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus docker-mailserver/docker-mailserver

Alle Issues in docker-mailserver/docker-mailserver

Ähnliche Issues

Weitere Issues zu Shell/Bash

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.