{"id":338,"date":"2018-08-20T11:23:59","date_gmt":"2018-08-20T10:23:59","guid":{"rendered":"http:\/\/eppesuigoccas.homedns.org\/wordpress\/?p=338"},"modified":"2018-08-20T11:23:59","modified_gmt":"2018-08-20T10:23:59","slug":"aggiungere-un-timeout-ad-un-servizio-di-systemd","status":"publish","type":"post","link":"https:\/\/blog.sguazz.it\/index.php\/archives\/338","title":{"rendered":"Aggiungere un timeout ad un servizio di systemd"},"content":{"rendered":"<p>Systemd pare forse troppo veloce ad avviare i server su cui lavoro, dei DELL PowerEdge T110-II con dischi SATA in mirror.<br \/>\nMe ne sono accorto perch\u00e9, all&#8217;avvio del server, il database postgresql non veniva avviato ed il relativo servizio di systemd era in stato \u00abfailed\u00bb. Nei log di postgresql non c&#8217;erano errori, ma il database era spento.<br \/>\nAvviare postgresql via systemd da linea di comando ha sempre funzionato correttamente, ma ovviamente questo avviene solo dopo aver avviato il sistema, quando la macchina \u00e8 meno carica. Difatti all&#8217;avvio, systemd fa partire in parallelo tutti i servizi che non hanno dipendenze tra loro. Tutti questi, partendo, leggono dal disco, il file system risponde quindi pi\u00f9 lentamente del normale, e postgresql va in timeout.<\/p>\n<p><!--more--><\/p>\n<p>Il timeout predefinito per il servizio postgresql \u00e8 di 90 secondi, come si pu\u00f2 vedere dai parametri di postgresql@9.4-main.service, che \u00e8 il servizio del quale stiamo parlando.<\/p>\n<p><code># systemctl show postgresql@9.4-main.service | grep -i timeouts<br \/>\nTimeoutStartUSec=1min 30s<br \/>\nTimeoutStopUSec=1min 30s<\/code><\/p>\n<p>In realt\u00e0 non si tratta di timeout specifici di postgresql, ma di quelli generici di systemd, difatti nella configurazione generale di systemd s&#8217;\u00e8 scritto:<\/p>\n<p><code># grep -i timeou \/etc\/systemd\/system.conf<br \/>\n#DefaultTimeoutStartSec=90s<br \/>\n#DefaultTimeoutStopSec=90s<\/code><\/p>\n<p>Nelle \u00abunit\u00bb per i servizi, si possono utilizzare tre parametri per il timeout: <em>TimeoutStartSec<\/em>, <em>TimeoutStopSec<\/em>, oppure <em>TimeoutSec<\/em>. Il primo \u00e8 quello dell&#8217;avvio del servizio, il secondo dell&#8217;arresto, il terzo \u00e8 comodo se si vuole impostare lo stesso timeout per entrambi. Nel caso systemd non riceva il segnale di avvenuto avvio entro TimeoutStartSec, il servizio viene arrestato e il suo stato cambiato in \u00abfailed\u00bb.<\/p>\n<p>Oltre al timeout di systemd, c&#8217;\u00e8 anche quello interno di postgresql, che si pu\u00f2 mettere nella variabile PGCTLTIMEOUT (per Debian, su altre distribuzioni questa variabile potrebbe avere nomi diversi). Il valore predefinito di questo timeout \u00e8 di 60 secondi (cfr: pagina di manuale di pg_ctl). Quindi, nel mio caso, ipotizzo che il database non si avviasse entro i 60 secondi.<\/p>\n<p>A questo punto decido di impostare le due variabili nella \u00abunit\u00bb del servizio di postresql. Nel mio caso si tratta di una \u00abunit\u00bb istanziata, vale a dire che con il solo programma postgresql, ci possono essere pi\u00f9 istanza del servizio, una per ogni cluster di postgresql. Nel mio caso l&#8217;istanza si chiama \u00ab9.4-main\u00bb e difatti il servizio \u00e8 \u00abpostgresql@9.4-main.service\u00bb.<br \/>\nSystemd vuole che le \u00abunit\u00bb per i servizi istanziati abbiano, nel loro nome, il carattere chiocciolina. La \u00abunit\u00bb \u00e8 quindi \/lib\/systemd\/system\/postgresql@.service.<\/p>\n<p>Potrei quindi modificare direttamente quel file, ma si tratta di un file che arriva con i pacchetti Debian di postgtresql e potrebbe essere aggiornato con nuove versioni del pacchetto, quindi sfrutto una caratteristica di systemd che permette di creare delle configurazioni aggiuntive che possono specificare parametri da aggiungere o modificare delle \u00abunit\u00bb. La documentazione (cfr: pagina di manuale di systemd.unit) dice che si possono creare delle directory foo.service.d\/ e metterci dei file con estensione \u00abconf\u00bb che contengono le modifiche alle \u00abunit\u00bb con lo stesso nome. Queste directory possono essere in vari posti, ma nel mio caso user\u00f2 \/etc\/systemd\/system perch\u00e9 \/etc \u00e8 deputata alla configurazione gestita direttamente dall&#8217;amministratore di sistema.<\/p>\n<p>Ecco quindi il contenuto di \/etc\/systemd\/system\/postgresql@.service.d\/timeout.conf:<\/p>\n<p><code>[Service]<br \/>\n# Aggiunti i due time out<br \/>\n# Giuseppe Sacco &lt;giuseppe.sacco@example.org&gt; 2018-08-20<br \/>\n# Numero massimo di secondi che pg_ctl attender\u00e0 per l'avvio di postgresql. Notare che<br \/>\n# PGCTLTIMEOUT deve essere minore di TimeoutSec.<br \/>\n# Valore predefinito: 60 secondi<br \/>\nEnvironment=PGCTLTIMEOUT=270<br \/>\n# Indica a systemd di attendere un certo periodo per l'avvio e arresto di questa \u00abunit\u00bb<br \/>\n# Deve essere maggiore di quello impostato con PGCTLTIMEOUT<br \/>\n# Valore predefinito: 90 secondi<br \/>\nTimeoutSec=300s<\/code><\/p>\n<p>adesso vediamo se systemd utilizza correttamente i nuovi valori:<\/p>\n<p><code># systemctl daemon-reload<br \/>\n# systemctl show postgresql@9.4-main.service | grep -i timeouts<br \/>\nTimeoutStartUSec=5min<br \/>\nTimeoutStopUSec=5min<\/code><\/p>\n<p>Tutto OK<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Systemd pare forse troppo veloce ad avviare i server su cui lavoro, dei DELL PowerEdge T110-II con dischi SATA in mirror. Me ne sono accorto perch\u00e9, all&#8217;avvio del server, il database postgresql non veniva avviato ed il relativo servizio di systemd era in stato \u00abfailed\u00bb. Nei log di postgresql non c&#8217;erano errori, ma il database [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,3,11],"tags":[],"class_list":["post-338","post","type-post","status-publish","format-standard","hentry","category-sysadmin","category-computer","category-debian"],"_links":{"self":[{"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/posts\/338","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/comments?post=338"}],"version-history":[{"count":1,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/posts\/338\/revisions"}],"predecessor-version":[{"id":339,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/posts\/338\/revisions\/339"}],"wp:attachment":[{"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/media?parent=338"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/categories?post=338"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.sguazz.it\/index.php\/wp-json\/wp\/v2\/tags?post=338"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}