cat /dev/null > Andrea

Mail me!

FileMaker Server su Ubuntu 24.04 si riavvia da solo ogni mattina: needrestart, unattended-upgrades e come risolvere

Se gestite FileMaker Server su Ubuntu 24.04, controllate i log: con buona probabilità il vostro server si riavvia da solo diverse volte al mese, sempre al mattino presto. Nessuno ha toccato niente, la VM non si è riavviata, FileMaker non è stato aggiornato. Eppure i database vengono chiusi e riaperti e gli utenti WebDirect vengono disconnessi.

Su un server di produzione che seguiamo abbiamo contato 18 avvii di FileMaker Server in un mese, in 12 giornate diverse, tutti tra le 06:00 e le 07:00. Nessuno se n’era accorto: i database si riaprivano da soli e a quell’ora gli utenti erano pochi.

Il responsabile: needrestart in Ubuntu 24.04

Ubuntu installa ogni mattina gli aggiornamenti di sicurezza con unattended-upgrades, avviato da apt-daily-upgrade.timer. Dopo l’installazione, l’hook di APT lancia needrestart, che cerca i servizi che stanno ancora usando in memoria una versione vecchia di una libreria appena aggiornata.

Il cambiamento sta tutto qui:

  • fino a Ubuntu 22.04, needrestart in modalità non interattiva elencava i servizi da riavviare;
  • da Ubuntu 24.04 li riavvia direttamente, anche durante gli aggiornamenti automatici (annuncio di Canonical).

FileMaker Server usa decine di librerie di sistema: OpenSSL, libcurl, GnuTLS, zlib, libxml2, brotli e altre. Basta che Ubuntu ne aggiorni una e needrestart esegue:

systemctl restart fmshelper.service

La scelta di Canonical ha senso: un processo che continua a girare con una libreria vulnerabile in memoria è ancora vulnerabile, anche se il pacchetto su disco è aggiornato. Per un database con file aperti e utenti connessi, però, un riavvio all’ora decisa dal ciclo di rilascio delle patch non è quello che vogliamo.

Come verificare se succede anche a voi

Avvii di FileMaker Server:

journalctl -u fmshelper --since "30 days ago" --no-pager -o short-iso | grep 'Started fmshelper'

Chi li ha causati (la riga systemctl restart ... fmshelper.service è la prova):

grep -h 'fmshelper' /var/log/unattended-upgrades/unattended-upgrades-dpkg.log*

Quali pacchetti erano stati aggiornati un minuto prima:

grep -A3 '^Start-Date' /var/log/apt/history.log

Se gli orari coincidono, avete il problema.

Gli effetti, non sempre evidenti

  1. Sessioni interrotte. Gli utenti WebDirect e FileMaker Pro vengono disconnessi, le chiamate alla Data API in corso falliscono, gli script lato server si interrompono.
  2. Database che non si riaprono. Se avete disattivato l’apertura automatica dei database all’avvio, come spesso si consiglia, o usate Encryption At Rest con sblocco manuale, la mattina dopo i database sono offline. Claris lo cita esplicitamente tra gli effetti. Per controllare la vostra impostazione cercate nell’Event.log la riga Automatically open databases when Database Server starts.
  3. Chiusura sotto pressione. fmshelper concede circa 120 secondi per chiudere tutto. Sul nostro server la chiusura dei database ha richiesto da 5 a 45 secondi, ma in Claris Community c’è chi ha visto arrivare la chiusura a 90 secondi su 120, con client WebDirect chiusi forzatamente. Claris stessa avverte che fermare i processi con i database aperti può danneggiare i file.
  4. Effetti a catena difficili da diagnosticare. Tutto ciò che FileMaker Server rigenera o reinizializza all’avvio torna allo stato iniziale. Se un problema “si ripresenta da solo” dopo qualche giorno senza motivo apparente, confrontate gli orari con i riavvii.

La soluzione raccomandata da Claris

Claris ha pubblicato un articolo dedicato (Preventing Unexpected FileMaker Server Restarts on Ubuntu 24 During Unattended Upgrades, Answer 000048993), che riprende il lavoro di Chris Irvine su ScaleFM. La soluzione è escludere solo i servizi FileMaker dai riavvii automatici di needrestart:

echo '$nrconf{override_rc}{qr(^fmshelper\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/fmshelper.conf
echo '$nrconf{override_rc}{qr(^com\.filemaker\.)} = 0;'    | sudo tee /etc/needrestart/conf.d/com.filemaker.conf

La prima regola copre il servizio principale. La seconda copre i servizi com.filemaker.*, tra cui l’nginx gestito da FileMaker Server.

Verifica:

sudo needrestart -l -r l

fmshelper.service deve comparire sotto “Service restarts being deferred”. Gli aggiornamenti continuano a essere installati, e gli altri servizi (ssh, systemd e così via) continuano a essere riavviati come prima.

Per tornare indietro basta cancellare i due file.

Cosa non fare

Nei forum la prima risposta è spesso “disattivate unattended-upgrades”. Claris lo sconsiglia, e ha ragione. Su un server esposto a Internet (WebDirect, Data API) rinunciare alle patch di sicurezza automatiche peggiora le cose. Lo stesso vale per disinstallare needrestart o metterlo in sola elencazione su tutto il sistema: si toglie la protezione a tutti i servizi per risolvere il problema di uno solo.

Il passo che nessuno vi dice: pianificare il riavvio

Escludere FileMaker da needrestart ha un costo, e Claris lo scrive chiaramente: FMS continua a girare con le librerie vecchie fino al riavvio successivo. Se la patch riguarda OpenSSL o GnuTLS su un server esposto, la vulnerabilità resta aperta finché non riavviate. L’esclusione va quindi sempre accompagnata da una politica di riavvio. Le strade sono due:

  • Riavvio pianificato automatico, ad esempio una notte a settimana, in un orario lontano da backup e script schedulati, e solo se ci sono librerie in sospeso.
  • Notifica + riavvio manuale: un controllo periodico vi avvisa quando FileMaker usa librerie sostituite, e decidete voi quando riavviare. È l’approccio adottato da diversi amministratori in Claris Community.

Un esempio minimo per capire se FileMaker Server sta usando librerie TLS sostituite da un aggiornamento (da lanciare come root):

cg=$(systemctl show fmshelper.service -p ControlGroup --value)
for pid in $(cat "/sys/fs/cgroup$cg/cgroup.procs"); do
  grep -oE '[^ /]*(libssl|libcrypto|libgnutls|libcurl)[^ ]*\.so[^ ]* \(deleted\)' "/proc/$pid/maps" 2>/dev/null
done | sort -u

Se l’output non è vuoto, FMS sta girando con una versione vecchia di quelle librerie ed è il momento di pianificare un riavvio. Collegatelo al vostro sistema di monitoraggio (Healthchecks, Uptime Kuma, Zabbix…) invece di affidarvi alla memoria.

Per i riavvii manuali, la procedura più prudente resta quella di Claris: disconnettere i client con un preavviso, chiudere i database con fmsadmin close, poi fermare o riavviare il servizio.

Checklist

  • ☐ Verificare nei log quante volte FMS si è riavviato da solo nell’ultimo mese
  • ☐ Creare i due file in /etc/needrestart/conf.d/ e verificare con sudo needrestart -l -r l
  • ☐ Lasciare attivi unattended-upgrades e needrestart
  • ☐ Decidere la politica di riavvio (pianificato o su notifica) e collegarla al monitoraggio
  • ☐ Controllare l’impostazione di apertura automatica dei database e l’eventuale EAR
  • ☐ Aggiungere il riavvio pianificato alla documentazione del server, così chi arriva dopo sa perché FMS non si riavvia più da solo

Fonti

Precedente