Newsgroup: it.comp.os.linux.debian
Titolo: runlevel... proprio non capisco...

ma che senso ha avere degli script che iniziano per S nei runlevel 0 e 
6, quando questi verranno comunque avviati con stop?
e piu' in generale, che senso ha che lo script rc lanci gli script con 
start o con stop a seconda del runlevel?
lo stesso script per inizia per S, nel runlevel 0 verra' fatto partire 
con stop, mentre nel runlevel 2 verra' fatto partire con start...
non era sufficiente il prefisso S o K per passare start o stop?
al runlevel 0 e 6 si sarebbero potuti mettere tutti gli script con K... 
e tutto (a parere mio) era piu' coerente...
fa forse mi sfugge qualcosa?

 non era sufficiente il prefisso S o K per passare start o stop?
No, perche` cosi` ogni script avrebbe dovuto contenere la logica per 
rilevare se fosse stato lanciato con start o con stop.
 
La struttura attuale e` la meno peggio per il sistema di init di default. 
Ogni script in init.d gestisce un servizio, e in base a come viene 
richiamato (con start o stop o altro) fa certe operazioni. Al suo interno 
contiene le definizioni comuni alle varie operazioni.
Quelli nei runlevel sono link a questi script, e si arrangia rc a 
richiamarli tutti con i parametri corretti in base al loro nome.
Bye.

 
si, ma mi sa che non ha capito l'illogicita' che ho cercato di spiegare
(colpa mia... mi spiego malissimo)
ciao

 indipendentemente dal fatto che inizino per K, o per S
Ora ho capito. Ho guardato il sorgente di rc, ed effettivamente ai 
runlevel 0 e 6 vengono richiamati tutti con stop.
Non era cosi` fino a qualche anno fa... :/
Come hai fatto ad accorgertene??
Bye.

 
tu qualche anno fai l'hai guardato...
io qualche anno fa usavo windows... :)



potrebbe essere  (presumo) che pur avendo  cambiato il comportamento di
rc, hanno volut tenere i nomi dei file in linea con quelli vecchi


??
quindi han tenuto dei file che iniziavano per S nel runlevel 0?!?!?
e cosa facevano partire al runlevel 0?
un software che dice 'essere o non essere?' prima di ammazzarsi?

 stop?
Con S init passa "start" allo script, con K passa "stop".
-- 
Vide


no no...
agli script che iniziano per S, ma che sono nei runlevel 0 o 6 vien 
passato stop lostesso
fra l'altro la cosa crea un piccolo bug, non grave, ma forse andrebbe 
segnalato
lo script /etc/rc0.d/S32portmap, che dovrebbe essere lanciato con stop, 
non viene mai eseguito (e qundi mai chiuso in modo corretto con uno stop)
questo per via di queste righe, in rc
suffix=${i#/etc/rc$runlevel.d/S[0-9][0-9]}
stop=/etc/rc$runlevel.d/K[0-9][0-9]$suffix
previous_start=/etc/rc$previous.d/S[0-9][0-9]$suffix
[ -f $previous_start ] && [ ! -f $stop ] && continue
che, secondo quella che dovrebbe essere  una logica coerente, dice che 
se un certo script e' presente col prefisso S al runlevel precedente e 
non e' presente con K al runlevel attuale... (ovvero se e' stato avviato 
ma non e' stato chiuso) allora non lo trattare...
ma in realta', al runlevel 0, lui avrebbe dovuto chiuderlo, non lanciarlo
insommma... c'e' qualcosa che non va... non mi so spiegare, me ne rendo 
condo, ma c'e' qualcosa che non va lostesso...

 passato stop lostesso
Vero, in 0 e 6 è un po' diverso, si considerano le lettere como
discriminanti per l'ordine (prime le K, in cui si uccidono processi, poi le
S in cui si fermano servizi più di sistema, diciamo così)
Qui comunque spiega tutto
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
In ogni caso non venirmi a dire che ci sono bug negli script di init di
Debian perchè ho appena finito (anzi, non ancora del tutto) di litigare con
Etch e open-iscsi che di default ti fa piantare tutto al reboot, per cui lo
so già fin troppo bene :/
-- 
Vide

 
mi spiace, ma invece ho paura che ci sia... e mi piacerebbe poterglielo 
dire a chi mantiene questo pacchetto...
il bug sta nel fatto che rc, se vede che al run level precedente, e' 
stato avviato un processo, evita di rilanciarlo (e una verifica simile 
la fa per evitare di 'richiudere' uno script)
pero' la verifica la fa basandosi sulle iniziali S e K... non tenendo 
conto del fatto che alcuni script vengono chiusi pur iniziando con S
la cosa miracolosamente funziona quasi sempre... tranne per uno script
portmap, al runlevel 0, inizia con S, ma dovrebbe venir avviato lostesso 
con stop
  ma siccome e' stato avviato con S anche al runlevel2,  non lo rilancia 
(credendo che debba lanciarlo con start)... e cosi' non lo chiude.
se vuoi vedere la cosa, e' facile
nel file /etc/init.d/rc, editi la funzione startup_progress (che e' 
quella che lancia materialmente gli script) e ci aggiungi una scritta a 
video, tipo:
startup_progress() {
     ########
     echo
     echo -----------------
     echo $@
     echo -----------------
     echo
     ########
     $@
     if [ "$SPLASH" = true ] ; then
         step=$(($step + $step_change))
         progress=$(($step * $progress_size / $num_steps + $first_step))
         $debug usplash_write "PROGRESS $progress" || true
     fi
}
chiudi, e vedrai tutti  gli script lanciati
e vedrai che portmap manca.
(pur essendoci nella lista degli script da chiudere, in rc0...)
se qualcuno mi ha letto fin qui, e ha un po' di esperienza, cosa mi 
consiglia di fare?
meglio non  intasare con bug cosi' piccoli, o meglio segnalare?

 meglio non  intasare con bug cosi' piccoli, o meglio segnalare?
non mi sembra cosě piccolo, io segnalerei


il problema era gia' stato risolto in versioni piu' recenti della mia...
(sciocco io... dovevo guardare...)
tanto meglio