Newsgroup: it.comp.lang.perl
Titolo: perl daemon e cron

Salve,
     volevo programmare un demone in perl che eseguisse dei compiti ogni 
tot secondi...volevo sapere se la seguente era una buona struttura per 
implementare il demone:
#!/usr/bin/perl
#
# Perl Daemon
use strict;
use warnings;
use IO::Socket::INET;
use POSIX qw(setsid);
&daemonize;
while(1) {
   sleep(10);
   # do my tasks...
}
sub daemonize
{
   chdir '/';
   umask 0;
   close (STDOUT);
   close (STDIN);
   close (STDERR);
 
   my $pid = fork;
   defined ($pid) or die "Cannot start daemon: $!";
   exit if $pid;
   setsid or die "$!\n";
}
__END__;
inoltre volevo sapere se è più consigliabile un ciclo:
while(1) {
   sleep(10);
   # do my tasks...
}
oppure sarebbe meglio usare dei segnali ALARM??
Dato che questo demone deve partire all'avvio del sistema...anzi diciamo 
appena mi loggo nel sistema (quindi a sistema già avviato)...come posso 
settare "cron" in tal modo? si può lanciare un demone da cron...vero?
grazie


C'è un articolo sulla "demonizzazione" su 
perl.it
:
http://www.perl.it/documenti/articoli/2006/12/demoni_e_segnal.html
Grosso modo mi sembra che tu copra tutti gli aspetti evidenziati. Puoi
provare anche a dare un'occhiata a Proc::Daemon (http://
search.cpan.org/dist/Proc-Daemon/
), dove mi sembra che descriva una
"doppia fork" per evitare l'acquisizione di un terminale di controllo.
IO::Socket::INET non è necessario ai fini della demonizzazione.
Se devi eseguire operazioni con pause di 10 secondi il ciclo che hai
scritto è ok ed eviterei di impelagarmi con alarm(). Ovviamente questo
dipende dal tipo di applicazione che stai scrivendo e dalle tue
esigenze in termini di attesa. Per avere dei timer con granularità più
fine puoi dare un'occhiata a Time::HiRes (
http://search.cpan.org/dist/
Time-HiRes/), che mette a disposizione una funzione sleep()
alternativa.
Non vedo problemi a lanciare demoni da cron, però poiché questo esegue
operazioni "ripetitive" devi stare attento a non lanciare più demoni.
Probabilmente è meglio evitare la crontab per queste operazioni, ed
allestire uno script di inizializzazione da mettere sotto /etc/init.d
(sto supponendo che tu stia sotto Linux), per poi utilizzare il
meccanismo di start-up dei demoni che la tua distribuzione mette a
disposizione (in molti casi, si tratta di link simbolici opportuni in /
etc/rc.d/rcX.d dove X è il numero del tuo runlevel).
Ciao,
   Flavio.

 grazie
a me sembra a posto cosi'. La funzione daemonize cosi' come e' in
perldoc perlipc mi sembra buona, io la uso.
alarm() e SIGALARM da come hai esposto il problema non servono:
Se i lavori da eseguire sono sincroni al flusso di programma,
intervalli i compiti con sleep() (magari usando quella di Time::HiRes
come dipe polettix per precisioni > del sec.)
alarm e SIGALARM le userei solo se il programma nel frattempo deve
fare dell' altro. In tal caso il suo flusso verra' interrotto
in modo rientrante dall' handler che, una volta eseguito, ritornera'
il controllo al programma nel punto di interruzione.
DIVAGAZIONE.......
tra l' altro i segnali complicano il codice anche per altri aspetti,
ad esempio per l' accesso a variabili globali. In tal caso il programma
deve garantirsi che quando accede a tali fariabili l' handler non lo
interrompera':
es
use POSIX();
$tmpsigset = POSIX::SigSet->new;
$oldsigset = POSIX::SigSet->new;
$tmpsigset->emptyset();
$oldsigset->emptyset();
$tmpsigset->addset(&POSIX::ALRM);
POSIX::sigprocmask(&POSIX::SIG_BLOCK, $tmpsigset, $oldsigset);
# il segnale e' bloccato e posso accedere alle var globali a cui
# puo' accedere l' handler. se il segnale arriva verra' "ricordato"
# non perso.
POSIX::sigprocmask(&POSIX::SIG_SETMASK, $oldsigset, $tmpsigset);
# ora il segnale puo' arrivare e se gia' arrivato l' handler verra'
# eseguito ora che non accedo piu' alle variabili condivise.
E' un modo per accedere in maniera atomica a strutture dati condivise
con ' handler, visto che questo non accetta altri argomenti.
ad esempio se un server concorrente vuole contare quanti figli ha in
esecuzione gestendo SIGCHLD deve incrementare un contatore a ogni
fork() e decrementarlo quando handler a SIGCHLD chiama waitpid(),
ma l' accesso a tale counter condiviso deve essere atomico, bloccando
appunto SIGCHLD per il tempo in cui il programma lo aggiorna.
Ciao
Roberto.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
search.cpan.org/dist/Proc-Daemon/
),
ti ringrazio, ho scoperto anche questo utile articolo: 
http://perladvent.pm.org/2004/9th/
ciao

 ti ringrazio, ho scoperto anche questo utile articolo:
http://perladvent.pm.org/2004/9th/
Sentendo parlare di queste cose mi viene in mente sempre POE.
Che se adottato, trall'altro, permette di aggiungere a costo zero o
quasi funzionalità di (ad esempio) monitoraggio remoto del demone,
produzione di report via web del suo stato, e così via...
ciao,
S.