[Linuxtrent] Re: systemd - Too many concurrent connections, refusing

  • From: Guido Brugnara <gdo@xxxxxxxxx>
  • To: linuxtrent <linuxtrent@xxxxxxxxxxxxx>
  • Date: Mon, 14 Aug 2017 07:53:22 +0200 (CEST)

----- Il 13-ago-17, alle 17:08, Antonio Galea antonio.galea@xxxxxxxxx ha 
scritto:

2017-08-13 7:04 GMT+02:00 Guido Brugnara <gdo@xxxxxxxxx>:

Lo script di norma si attiva e lo rimane per molto tempo, ma se viene a 
mancare
una risorsa esterna (mancanza di rete,
errore o service remoto fermo) lo script si ferma e va quindi riavviato. Al
riavvio se la risorsa non è ancora raggiungibile,
dopo un determinato timeout lo script si interrompe ecc. ecc.

Ok, descritta così la questione mi è decisamente più chiara - e
l'esigenza la comprendo meglio.

Prima di aggiornare il server all'attuale versione 16.4 lo script, che 
girava su
un Ubuntu 12.04, veniva riavviato da
"upstart" senza alcun problema.
Ovvio che tutto è migliorabile a questo mondo, sia lo script io oggetto che
systemd; solo che systemd, direi, è un
componente assai più critico ma purtroppo è stato adottato un po' troppo in
fretta, prima che abbia raggiunto una stabilità
sufficiente al ruolo che gli compete.
Un suo bug, come quello che ho descritto, blocca di fatto tutto il sistema.

A dire il vero, io non credo che systemd in questa situazione abbia un
bug: è solo che non puoi aspettarti che sia troppo simile ad upstart,
perché segue una filosofia abbastanza diversa.

Il comportamento che descrivi sembra dovuto al fatto che systemd è
decisamente più veloce di upstart, e questo fa sì che il tuo servizio,
quando la risorsa effettivamente non è disponibile, venga riavviato
con una frequenza troppo alta. Systemd fa correttamente il suo lavoro,
uccidendo il demone impazzito (dal suo punto di vista) prima che tiri
giù la macchina.

Non è affatto così!
Il processo impiega alcuni secondi per fermarsi e configurando opportunamente i 
parametri stante quanto riportato dai manuali così dovrebbe andar bene:
________________________________________

[Unit]
Description=My trivial script
Wants=postgresql.service
StartLimitIntervalSec=10
StartLimitBurst=10

[Service]
Type=simple
Restart=on-failure
RestartSec=3
User=nobody
Group=nogroup
ExecStart=/bin/bash -c 'sleep 1; echo "Exit 1" >&2; exit 1'

[Install]
WantedBy=multi-user.target
________________________________________

Il bug, indicato anche nell'oggetto di questo thread, "Too many concurrent 
connections, refusing" è riferito al fatto che dopo qualche giorno systemd ri 
rifiuta di eseguire qualunque comando emettendo l'errore dovuto al fatto che ha 
esaurito le connessioni con D-bus.
Solo un "kill 1" pone un rimedio al problema.
 
Una soluzione pulita sarebbe dichiarare in modo esplicito nel tuo unit
file di quale risorsa hai bisogno, usando BindsTo+After (o una delle
altre opzioni: "man systemd.unit"). Se non si tratta di una risorsa
direttamente monitorabile da systemd, puoi sempre creare un
mini-servizio che faccia solo il monitoraggio - e legarlo al tuo
script attuale allo stesso modo.

Più che una soluzione "pulita" direi che è un "workaround".
Ci hanno spacciato systemd perché rispetto al "vetusto" systemV ha in più 
l'esecuzione parallela dei processi all'avvio ed un maggior controllo degli 
stessi per garantire la continuità dei servizi ... e non so quante altre 
amenità.
Mi pare ovvio che poi questi benefici la gente poi li vada ad utilizzare ... e 
se poi un processo così vitale come systemd va "in crauti" per un banale demone 
un po' troppo frettoloso nel terminare ... siamo messi male ;-)

bye
gdo

 
HTH,

Antonio
--
Per iscriversi  (o disiscriversi), basta spedire un  messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
--
Per iscriversi  (o disiscriversi), basta spedire un  messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx


Other related posts:

  1. Home
  2. linuxtrent
  3. Archive
  4. 08-2017