# \`/srv/status\` restituisce OK anche se il database è rotto
**URL:** https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075
**Category:** Development
**Created:** [17 Luglio 2020, 8:09pm UTC](https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075 "2020-07-17T20:09:58Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [17 Luglio 2020, 8:09pm UTC](https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075/1 "2020-07-17T20:09:58Z")
Questa mattina un aggiornamento su un’installazione a 2 container è andato storto. L’avvio di un nuovo container ha migrato il database in uno stato danneggiato (forse non sarebbe successo se avessi usato `SKIP_POST_DEPLOYMENT_MIGRATIONS=1`, ma questa è un’altra questione), cosicché il container in esecuzione ha mostrato il messaggio “oops, questo sito è rotto”.
Questo aspetto è previsto, ma il mio monitor controlla `/srv/status` e restituisce tranquillamente un OK anche quando Rails è piuttosto compromesso.
È un bug? Vorrei davvero che i miei monitor sapessero se c’è un problema; dovrei invece controllare qualcos’altro, come `/about.json` (per i siti che non richiedono il login)?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [17 Luglio 2020, 11:17pm UTC](https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075/2 "2020-07-17T23:17:35Z")
In che modo esattamente era rotto? Puoi essere più specifico? Com’era la homepage?
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [18 Luglio 2020, 1:48am UTC](https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075/3 "2020-07-18T01:48:47Z")
Sì, “ok” significa che il “unicorno” sta funzionando. Se ricordo bene, puoi spegnere Postgres e Redis e continuerà a dire “ok”.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [18 Luglio 2020, 1:53am UTC](https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075/4 "2020-07-18T01:53:08Z")
Sono abbastanza sicuro che sia corretto. Ha senso, è solo che non era quello che pensavo.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [18 Luglio 2020, 1:54am UTC](https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075/5 "2020-07-18T01:54:40Z")
Non sono sicuro di quale sia lo stato di questa cosa @sam @eviltrout? Ricordo vagamente una discussione al riguardo in passato.
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [18 Luglio 2020, 2:06am UTC](https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075/6 "2020-07-18T02:06:23Z")
Sì, non controlla Redis o PG. Penso che usiamo un plugin che esegue `User.find(1)` e `$redis.get` al posto di ciò. Questo non rileva comunque il caso di @pfaffman, ma potrebbe essere un po’ eccessivo: non ci si può aspettare che effettui un controllo completo della coerenza del database.
[discourse/app/controllers/forums\_controller.rb at main · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/master/app/controllers/forums_controller.rb#L11-L17)
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [18 Luglio 2020, 2:27am UTC](https://meta.discourse.org/t/srv-status-returns-ok-even-if-database-is-broken/158075/7 "2020-07-18T02:27:41Z")
Il endpoint `/srv/status` controlla _solo_ il processo locale, non le dipendenze. “Lo stack HTTP è bloccato?”, più “sono in fase di dismissione?”. Nella terminologia di Kubernetes, questo è il `livenessProbe`, non il `readinessProbe`.
Se vogliamo introdurre un `readinessProbe`, dovrebbe risiedere su un URL diverso.
> [@michaeld](#):
>
> User.find(1)
Probabilmente `Discourse.system_user.id` invece di 1.