Newsgroup: it.comp.os.linux.sys
Titolo: Re: Creare un....demone  ;-) [Xpost]

 Saluti e a presto  :-P
PS.
Mi scuso di questa specie di multipost, ma probabilmente è una
domanda non prprio da icol.iniziare....cioè forse può stare bene
anche qua.
Al momento del primo post ho inviato senza pensarci troppo, ma
forse non ho meditato abbastanza sull'xpost...
Metto followup-to su entrambi i gruppi.
Saluti.

> vostra esperienza.  ;-)
Qual'č la domanda? Quali sono i dubbi?
Se dai un'occhiata meno di sfuggita agli script che ci sono in 
/etc/init.d o in /etc/rc.d dovresti averne di meno.

> vostra esperienza.  ;-)
Meglio se confidi in man bash
-- 
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.

> servizi in /etc/rc.d/.
Se lo metti lě poi lo avvii e lo fermi come gli altri servizi e se muore 
resta morto. Se lo metti in /etc/inittab puoi specificare respawn e se 
muore il sistema lo riavvia.

 /etc/init.d o in /etc/rc.d dovresti averne di meno.
Il fatto è che quegli script prevedono (mi pare di capire) la gestione
di un eseguibile (il demone in questione...vedo sshd, ddclient
ecc ecc) "propriamente eseguibile", un binario di un programma scritto
in C solitamente...tanto per intenderci.
Nel mio caso avrei a che fare con un rc.bashdemone che dovrà
gestire appunto il mio "bash-daemon-script".
Sono giunto a questo modo di organizzare gli script grazie alle
risposte ottenute in questo thread....e sbirciando nella dir
/etc/rc.d della slackware.
A questo punto la domanda è, come deve essere fatto questo
demone in bash?
La domanda così è inevitabilmente troppo generica, penso sia il
caso di esporre più chiaramente cosa deve fare lo script...
Metto tutto in un altro post di questa stessa discussione. ;-)

 E' possibile farlo ma non è un metodo più furbo, anzi, un'inutile complicazione.
Bene, pare quindi che la via precedente sia migliore. Comunque ti
ringranzio anche per l'esempio successivo che non riporto...non
l'ho capito completamente, me lo riguarderò con più calma magari
col man bash di fianco  ;-)

JohnnyNewbie ha scritto:

Un pò incasinata la domanda, un pò incasinata la risposta...
Un demone tipo SSH è un applicazione che fa uso di socket e sta in 
ascolto su una porta in attesa di una connessione interna/esterna e 
mette a disposizione una serie di comandi ai quali esegue delle operazioni.
Quindi se vuoi un demone la soluzione più semplice è utilizzare Perl
cerca con google la parole magiche "perl socket"
Buon lavoro

 Buon lavoro
PSK

> Un p� incasinata la domanda, un p� incasinata la risposta...
Si evidentemente...  :-\
Rispondo ad entrambi.
Il fatto � che probabilmente un reale demone non mi serve per
l'obiettivo descritto.
Mi basta uno script bash silente capace di spedire output e error
su file di log. Quindi gestirlo con un secondo script del tipo di
qelli presenti in /etc/rc.d della slack.
Le vostre rispostee chiarimenti comunque rtestano e sono
sicuramente un punto di partenza pi� corretto per capire cosa sia
un demone e come fare a crearne uno.
Peccato che venga meno la possibilit� di usare bash...almeno da
parte mia (causa ignoranza) sarebbe stata una grossa
semplificazione, anche perch� di perl e python non ne so
praticamente nulla.
Mi hanno gi� consigliato di mettere mano alla documentazione,
visto che tendo a gestire diverse faccende del mio sistema
con degli script ad hoc, tuttavia avendo quasi sempre risolto
con bash, e per via del tempo e della voglia (lo ammetto), non mi
sono mai degnato di imparare seriamente altri e pi� potenti
linguaggi di scripting. :-/

 programmi e per comodità.
Ok, riprendo questa discussione che era rimasta un po' in
sospeso.
Condiderando il significato di demone, che come alcuni mi hanno
fatto notare non è un semplice job in background, ma ha alcune
caratteristiche aggiuntive ovvero sta in ascolto su una porta ecc
ecc.
Forse sarebbe il caso di cambiare il titolo del thread alla luce
di questo, ma va bè...spero che ci si capisca.
In sintesi vorrei semplicemente che uno script bash girasse in
background e allo stesso tempo poter uscire dalla bash che lo ha
lanciato senza che lo script muoia. Anche eventualmente
effettuando il logout vorrei che lo script restasse funzionante
in background.
In un caso del genere si potrebbe usare anche screen che
attraverso la possibilità di fare il detach della sessione
raggiunge lo scopo. Ma vorrei riuscire senza screen o nohup.
Ho quotato THe_ZipMAn che ne messaggio cui sto rispondendo aveva
inserito una soluzione contenente spunti interessanti.
Allora l'idea è quella di fare due script, il primo è uno script
di avvio/stop del secondo script che invece è appunto quello da
fare girare in background.
Riporto l'esempio in toto visto che è passato del tempo. Aggiungo
che l'esempio voleva essere un unico script che conteneva al suo
interno la sua "background/side". Come ho appena detto nei miei
tentativi, invece ho scelto la soluzione a due script distinti,
che lo stesso the_zipman consigliava.
Ok, vi riporto l'esempio (considerato inutile complicazione):

Ora vorrei proporvi la soluzione a due script.
-------------- demone.sh
#!/bin/bash
#
while [ 1 ]; do
  echo `date`>>data.log
  sleep 5
done
-----------------------
Il nostro demone è una cosa molto semplice, uno script che ogni 5
secondi scrive la data su un file di log.
Ora vediamo lo script che fa partire e ferma lo pseudo demone
precedente.
------------------------------------- rc.demone
#!/bin/bash
#
PIDFILE=./demone.lock
case "$1" in
  start)
       ./demone.sh &
       RET=$?
       echo $! > $PIDFILE
       disown %1
       exit $RET
  ;;
  stop)
      [ -f $PIDFILE ] && kill $( cat $PIDFILE )
      rm -f $PIDFILE
  ;;
  *)
   echo "Impara ad usarmi"
  ;;
esac
------------------------------------------------
Se non ho capito male il punto interessante di tutto questo
discorso sta nel comando builtin "disown".
Ammetto che dal man bash ho capito veramente poco, ma se non ho
capito male, dandogli in pasto un job della shell corrente,
dovrebbe evitare che chiudendo la shell venga terminato (sighup)
anche il job figlio. Con l'opzione -h inoltre il job resta
attaccato alla shell, quindi richiamabile dalla stessa (la shell
madre, non una a caso ovviamente) mentre senza quell'opzione
viene sganciato dalla shell che lo ha lanciato.
Insomma qualcosa di simile al detach di screen...ovviamente con
diverse lmitazioni, simile non uguale.
Ora, lo pseudo-demone in questione è molto semplice e non vi si
può interagire se non per faermarlo o farlo partire, ma
immaginando che uno pseudo demone del genere si basi su degli
input ricavati dalla lettura di opportuni file di testo, mi
sembra piuttosto semplice dedurre che modificando tali files di
testo, si potrebbe modificare a caldo il comportamento del
demone. In pratica sintetizzando:
1- uno script rc.qualcosa fa partire uno script in background
   grazie a disown chiamiamolo qualcosad.
2- qualcosad accede ricorsivamente a dei file di testo pe
   compiere operazioni sue.
3- si può creare un'interfaccia di comando per qualcosad agendo
   sui file di testo che usa come input.
Ovviamente il punto 3 è fumoso, generico e assolutamente non
applicato a qualcosa di concreto, me ne rendo conto. Ciò detto
però penso che quei tre punti possano essere interessanti per
creare e gestire diversi script "di sussistenza" che non
richiedono troppa interattività.
Ad esempio avevo in mente la creazione/modifica di uno script in
per la gestione dei download, capace di accedere ad una coda di
file da scaricare magari con wget, avere la possibilità di
fermare la coda, modificarla camiare l'ordine dei download,
impostavi liiti di velocità, golobale o spegifica ecc ecc.
Ci sta dietro un lavoro di interfaccia che non ho ancora bene in
mente. Ma il nocciolo del programma potrebbe essere uno pseudo
demone e quando si vuole monitorare e modificare la coda ecc, si
usa un'opportuna interfaccia. In questo modo si potrebbero
pensare anche più interfaccie magari basate su diverse soluzioni
testuali grafiche e basate su questa oquella libreria, tipo qt,
gtk ecc ecc magar tanto per restare in script bash, ricorrendo a
programmi come zenity.
Sarebbe interessante anche farlo lavorare tipo come amuled
potendovi accedere anche su una macchina remota, ma questo esula
dalle mie conoscenze e in quel caso si tratterebbe realmente di
un demone che sta in ascolto su una porta ecc ecc. Non penso che
si riuscirebbe a cavarsela con semplici script bash.

    sui file di testo che usa come input.
Per l'interfaccia di comando puoi sfruttare in modo proficuo i segnali.
Sempre su man bash puoi cercare il comando trap e usarlo per trappare i 
segnali HUP, USR1, USR2, ecc.ecc. Tipicamente HUP lo usi per far rileggere 
la configurazione, mentre USR1 e USR2 li usi per far compiere delle azioni.
dopo aver fatto questo con un semplice
kill -HUP `cat ./demone.lock`
per esempio riesci a far fare al demone delle operazioni pulite.
Trappando TERM per esempio puoi far eseguire delle operazioni alla chiusura 
del "demone" come 
p.es
. rimuovere il pidfile.


 chiusura del "demone" come 
p.es
. rimuovere il pidfile.
Ma, ecco prendiamo questo esempio: teoricamente quale sarebbe il
vantaggio di adottare il tarp del segnale TERM per eliminare il
file col pid piuttosto che aggiungerlo nel file di richiamo
rc.qualcosa?
Dici: meglio demandare ai programmi (potrebbero esserci più
pseudo-demoni in ballo) chiamati da rc.qualcosa la propria
"sessione di chiusura" lasciando il file rc.qualcosa il più
possibile sintetico e pulito?
Non sarebbe (e perchè) meglio adottare dei demoni "stupidi" e
localizzarne la gestione maggiormente nel file rc.qualcosa?
Ti ringrazio molto dell'intervento e del supporto, il mio esempio
(che poi pesca a piene mani nel tuo) allora non è un'idea
peregringrina...che ne pensi?
Intendo, soluzioni del genere in qualche anno di utilizzo di
linux ne ho viste poche e anche quando le ho cercate non ne ho
trovate di simili a questa, tutti indicano l'utilizzo di
programmi esterni come nohup o screen, quando invece se questa
soluzione è valida si farebbe solo ricorso al builtin di bash che
come idea non mi dispiace. Se ti va di aiutarmi ancora una volta
a capire questo aspetto sono tutto orecchi.  ;-)
Saluti e grazie di nuovo!  :-D

 a capire questo aspetto sono tutto orecchi.  ;-)
Ti posso fare un esempio del tuo programma con la gestione dei segnali.
Se per esempio avvi il demone con lo script e poi lo killi, non incorrerai 
nell'errore di demone in esecuzione.
-------------- demone.sh
#!/bin/bash
PIDFILE=/var/run/demone.sh.lock
[ -f "$PIDFILE" ] && echo "Gia' in esecuzione" && exit 1
echo $$ > $PIDFILE
LOG=/var/log/data.log
clean() {
    rm -f "$PIDFILE"
}
reload() {
    echo "Ho ricaricato alle ore `date '+%H:%M:%S'`" >>  $LOG
}
check_size() {
    echo "Il file di log è di `ls -l $LOG | awk '{print $5}'` bytes" >> $LOG
}
trap clean SIGTERM SIGINT SIGABRT EXIT
trap reload SIGHUP
trap check_size SIGUSR1
while [ 1 ]; do
   echo `date` >> $LOG
   sleep 5
done
-----------------------
------------------------------------- rc.demone
#!/bin/bash
#
PIDFILE=/var/run/demone.sh.lock
case "$1" in
   start)
        ./demone.sh &
        RET=$?
        disown %1
        exit $RET
   ;;
   stop)
       [ -f $PIDFILE ] && kill $( cat $PIDFILE )
   ;;
   *)
    echo "Impara ad usarmi"
   ;;
esac
------------------------------------------------
Rif. 
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_02.html
e anche un man signal già che ci sei :)


 e anche un man signal già che ci sei :)
Ok, grazie ancora. Qualche dubbio ancora circa SIGUSR1/2, ma più
che altro nell'applcazione. Inutile parlarne ora, proverò appena
possso a scrivere lo script che avevo in mente ed eventualmente
mi rifaccio vivo. Mi stavo chiedendo se si potessero trappare
delle funzioni, ma mi hai anticipato con questa risposta e
l'esempio.
Grazie mille ancora di tutto. A presto!  :-D