Re: restart non voluto dopo apt-upgrade (lunghetto)
Mi scuso per la prolissita', ma nel desiderio di essere chiaro
( affinche' possa meglio elaborare soluzioni diverse e specifiche per le
tue esigenze ) mi sono fatto un po' prendere la mano.
Il giorno dom, 21-11-2004 alle 18:13 +0200, Maxx ha scritto:
> Mi sono andato a spulciare i postinst di un paio di package
> e ho notato che in generale il restart è fatto lanciando
> /usr/sbin/invoke-rc.d (se esiste).
> A sua volta invoke-rc.d usa al suo interno /usr/sbin/policy-rc.d
> (in genere non esistente) che permette di introdurre un "policy
> layer" e modificare così il comportamento di invoke-rc.d.
>
> Ovvero, *dovrebbe* essere possibile vietare al sistema di
> lanciare/rilanciare certi servizi a un certo runlevel.
> Hmm... almeno ora ho qualche speranza di ottenere una
> soluzione più o meno pulita.
Guarda, io lascerei stare policy-rc.d. Il fatto e' che nessuno si e'
messo a scrivere uno script decente ed il motivo e' che, a meno di non
avere esigenze diverse da quelle descritte, si tratta di un sistema
farraginoso ed inutile.
Andiamo per gradi. In un init sysv un servizio puo' avere 3 stati:
- Start, se vi e' un link Sxx (indipendentemente dal fatto che esista
anche un link Kxx);
- Kill, se e' presente solo il link Kxx
- Undefinied, se non e' presente nessuno dei link di cui sopra.
Lo stato U ( che possiamo anche definire come "Don't touch" ) fa si' che
lo stato del servizio in esame dipenda dallo stato che quello stesso
servizio aveva nel runlevel di provenienza. In pratica e' uno stato di
inerzia.
A questo punto come dovrebbe comportarsi invoke-rc.d in un caso simile ?
Poiche' la decisione dovrebbe essere presa _non_ in base all'attuale rl,
ma in base al rl di provenienza ( conosciuto ) ed eventualmente a quello
anteriore e cosi' via ( questi pero' sconosciuti ), non vi e' modo di
definire un comportamento che effettivamente possa considerarsi
"corretto". In altre parole, invoke-rc.d puo' sbagliare facendo
ripartire un servizio in stato U, pero' e' altrettanto scorretto non
farlo ripartire, essendoci ad esempio la possibilita' che rimanga in
esecuzione una versione precedente del demone, magari con falle di
sicurezza ( ed e' piu' o meno condivisa l'opinione che un sysadmin
generalmente si aspetti che un upgrade si occupi [1] di aggiornare non
solo le copie sul disco dei programmi ).
Tempo fa c'era stata la proposta di fare in modo ( diverse le soluzioni
possibili per l'implementazione ) che invoke-rc.d facesse ripartire i
servizi solo se attualmente in esecuzione, ma, se non ricordo male, la
discussione fu rimandata a dopo il rilascio di sarge. Tutto sommato,
pero', mi sembra che anche questa sia una soluzione che aggiunge un
livello di complessita inutile.
Veniamo pero' al dunque: come far in modo che un servizio non parta
automaticamente ( e non voluto ) dopo un upgrade ? Semplicemente non
limitandosi a rimuovere i link Sxx ma sostituendoli con link Kxx.
Semplice ed efficace.
Come "implementarlo" ? A manina, tramite update-rc.d o, meglio, tramite
tool quali sysv-rc-conf o sysvconfig ( che hanno alcune funzionalita'
complementari fra loro, per cui io li consiglierei entrambi ). Se non
sbaglio, anche l'ultima release di rcconf si comporta "correttamente".
Come ultima alternativa ( forse ) c'e' l'installazione di file-rc,
abbandonando cosi' il sistema sysv. Su questa pero' non sono molto
sicuro, perche' file-rc sara' anche "migliore" ma e'... ehm ...
"brutto", per cui mi limito a riportare quanto mi pare di ricordare.
Ciao,
Gian Piero.
[1] Vabbe', per quanto possibile. Un discreto amministratore usa sempre
lsof dopo un aggiornamento per provvedere manualmente a quanto i
processi automatizzati hanno tralasciato.
Reply to: