Newsgroup: it.comp.os.linux.debian
Titolo: 'Baco' di upstart (soluzione del problemone con init.d script)

È passato un po' di tempo, ma sono tornato sul problema solo oggi.
Avevo già affrontato la questione a partire da
<1omu4sqy...@HerenotThere.invalid>.
Ubuntu 64 bit, con upstart che emula i runlevel. In sintesi: quando
il sistema si accende e va al runlevel di default (2), non viene
eseguito un mio K-script (in precedenza correttamente eseguito come
S-script al runlevel S).
Ho dato uno sguardo agli script del boot, ricostruendo il loro
comportamento, ho svelato l'arcano e trovato la facile soluzione.
Prima, però, apro una breve parentesi. Leggendo lo script
/etc/init.d/rc, richiamato dagli script-evento presenti in
/etc/event.d e usato per eseguire tutti gli init-script, runlevel per
runlevel, ho potuto notare che è in certo modo "ottimizzato".
Passando da un runlevel all'altro, cioè, gli script del nuovo
runlevel non vengono tutti eseguiti. Un K-script non viene eseguito,
per esempio, se nel runlevel di provenienza esiste un K-link analogo
e manca un S-link analogo (questo, nelle intenzioni degli
"ottimizzatori", per evitare di fermare un servizio già fermo). A me
questo comportamento non piace affatto. E se avessi fatto partire
manualmente quel dato servizio, nel runlevel precedente? Entrando nel
nuovo runlevel non verrebbe fermato! Che pensate di queste cosideette
ottimizzazioni? Chiusa parentesi.
Torno a bomba. Essendo a runlevel 2, ecco qui il problema:
lem@GUTSYCOMP:~$ runlevel
N 2
Invece dovrei ottenere "S 2", perché sono arrivato a 2 passando da S
(cioè dalla fase di boot). Verificando anche gli script-evento, la
catena dell'impostazione di runlevel e prevlevel dovrebbe essere
preservata correttamente, nelle intenzioni di upstart. Invece no, e
sia arriva a 2 con prevlevel N (che credo stia per None) e non S. Per
una delle ottimizzazioni di cui dicevo prima, se si proviene da N
*nessun* K-script del nuovo runlevel viene eseguito. Questo, per la
verità, ha senso: infatti, in linea teorica, non potrebbe esservi
nulla da fermare, se davvero si provenisse da N, ovvero dal nulla. Ma
solo S proviene da N (e infatti in /etc/rcS.d non si hanno K-script),
e invece qui siamo già a 2!
Il boot comincia da /etc/event.d/rcS, di cui riporto il succo:
	start on startup
	stop on runlevel
 
	runlevel --set S >/dev/null || true
	PREVLEVEL=N
	RUNLEVEL=S
	export PREVLEVEL RUNLEVEL
	exec /etc/init.d/rcS
 
Poi il boot prosegue, ma noi possiamo fermarci qui.
_Problema_
Il problema sta nel fatto che il comando:
runlevel --set S >/dev/null || true
contenuto in /etc/event.d/rcS arriva decisamente troppo *presto*.
Infatti il comando runlevel agisce sul file /var/run/utmp. Ma il
filesystem tmpfs varrun viene montato su /var/run solo dal successivo
script /etc/rcS.d/S01mountkernfs.sh. Il file utmp, per di più, viene
creato addirittura solo dallo script /etc/rcS.d/S80bootmisc.sh!
_Soluzione_
Per far funzionare bene upstart, basta modificare quest'ultimo
script, etc/rcS.d/S80bootmisc.sh, inserendo il comando
/sbin/runlevel --set S >/dev/null || true
nella sezione start, dopo la chiamata alla funzione do_start.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
__________________________________
Combatti l'AIDS col tuo computer: 
http://fightaidsathome.scripps.edu/

Lem Novantotto ha scritto:
[...]
Dimenticavo di ringraziare THe_ZiPMaN per il suo giusto suggerimento
di concentrarmi su upstart. Lo faccio ora. :)


 di concentrarmi su upstart. Lo faccio ora. :)
Arrossisco ;-)
Sono contento che tu abbia risolto.
Purtroppo come hai potuto constatare upstart ha ancora parecchie 
idiosincrasie che ne giustificano la permanenza in experimental :-(
Speriamo vengano risolte in fretta.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.