Le stranezze degli script...
Moderatore: Federico.Lagni
- andrewp
- Messianic Network master
- Messaggi: 2199
- Iscritto il: lun 13 giu , 2005 7:32 pm
- Località: Roma
E' bello imbattersi sempre in nuove improbabilità informatiche...per quale motivo uno script in bash, se lanciato a mano termina tutti i compiti alla perfezione...e se schedulato in crontab si ferma a metà?!
Manipolatore di bit.
- andrewp
- Messianic Network master
- Messaggi: 2199
- Iscritto il: lun 13 giu , 2005 7:32 pm
- Località: Roma
Cosa intendi per path completo dei comandi?All'interno dello script?!
Puoi farmi un esempio...dal momento che lanciandolo a mano, utilizzando la stessa stringa di crontab, porta a termine tutti i suoi compiti.
Puoi farmi un esempio...dal momento che lanciandolo a mano, utilizzando la stessa stringa di crontab, porta a termine tutti i suoi compiti.
Manipolatore di bit.
-
- Cisco power user
- Messaggi: 75
- Iscritto il: sab 23 apr , 2005 9:48 pm
per fare un esempio 'fesso fesso', se devi eseguire un comando comeSithDrew ha scritto:Cosa intendi per path completo dei comandi?All'interno dello script?!
Codice: Seleziona tutto
echo "hello world"
Codice: Seleziona tutto
/bin/echo "hello world"
Un comando in crontab può essere eseguito in una shell la cui variabile path di ambiente può non contenere il percorso del file che vuoi eseguire, e quindi il sistema operativo semplicemente non lo trova...
Se per l'utente root, /bin è un percorso già impostato nella variabile path, lo stesso percorso può non essere definito per l'untente con il quale il comando in crontab viene fatto eseguire.
Se posti lo script ci si da uno sgaurdo!
Saluti.
- sum][one
- Cisco power user
- Messaggi: 87
- Iscritto il: ven 11 nov , 2005 12:04 pm
- Località: Italy
- Contatta:
anche io ho avuto lo stesso problema .. ed alla fine ho fatto degli script da eseguire in crontab con i percorsi completi invece di lanciare in una riga crontab i vari comandi (ed i percorsi anche li erano completi.. ma non andava la meta' delle volte)... so che tutto questa mia risposta e' inutile..
inotre potresti magari pipeare l'output al log.. magari ti dice perche' non va.. boh..
ciao!
inotre potresti magari pipeare l'output al log.. magari ti dice perche' non va.. boh..
ciao!
:: jean-claude
:: mimgfx dot com
:: mimgfx dot com
-
- Cisco power user
- Messaggi: 75
- Iscritto il: sab 23 apr , 2005 9:48 pm
L'errore più comune nei crontab è quello di omettere i percorsi, o eseguire comandi per i quali l'user che li esegue non ha i privilegi.
Se devo eseguire un comando come cat prova.txt, in crontab il comando diventa:
Qualsiasi file o directory si voglia specificare come opzione va indicata con il percorso assoluto. Un altro esempio tipico è per mrtg per chi non vuole usare l'opzione daemon, per cui il comando diventa:
oppure per cacti:
Saluti.
Se devo eseguire un comando come cat prova.txt, in crontab il comando diventa:
Codice: Seleziona tutto
/bin/cat /$directory_dove_si_trova_prova.txt/prova.txt
Codice: Seleziona tutto
/usr/bin/mrtg /etc/mrtg.cfg
Codice: Seleziona tutto
*/5 * * * * cactiuser /usr/bin/php /var/www/localhost/htdocs/cacti/poller.php > /dev/null 2>&1
Saluti.
- andrewp
- Messianic Network master
- Messaggi: 2199
- Iscritto il: lun 13 giu , 2005 7:32 pm
- Località: Roma
Questa prima parte viene eseguita tranquillamente anche da crontab:
Questa parte invece...non ne vuole sapere, se non manualmente, sono sicuro che l'utenza di crontab sia root in quanto lo script riesce a partire ed a eseguire operazioni in cartelle e file con permessi 700.
Something strange?!
Codice: Seleziona tutto
cd /var/log/squid
cp access.log.1.gz /var/spool/squid/bcklog/
cp cache.log.1.gz /var/spool/squid/bcklog/
cp store.log.1.gz /var/spool/squid/bcklog/
cd /var/spool/squid/bcklog/
mv access.log.1.gz access.log.1.gz.$(stat access.log.1.gz --format=%y |cut -c 1-10)
mv cache.log.1.gz cache.log.1.gz.$(stat cache.log.1.gz --format=%y |cut -c 1-10)
mv store.log.1.gz store.log.1.gz.$(stat store.log.1.gz --format=%y |cut -c 1-10)
find * -ctime +7 -exec rm {} \;
Codice: Seleziona tutto
cd /var/log/squid
sleep 1
filenamea="access.log.1.gz"
filenameb="cache.log.1.gz"
filenamec="store.log.1.gz"
hostname="x"
username="xx"
password="y"
ftp -un $hostname <<EOF
quote USER $username
quote PASS $password
binary
cd cartella
put $filenamea $filenamea.A
put $filenameb $filenameb.B
put $filenamec $filenamec.C
quit
EOF
Manipolatore di bit.
-
- Cisco power user
- Messaggi: 75
- Iscritto il: sab 23 apr , 2005 9:48 pm
Se la prima parte non ti da problemi passiamo alla seconda, ed anche se ho tolto -u all'ftp perchè nel mio client ftp non è previsto lo switch -u, se l'user che esegue lo script è root, funziona anche senza full path, ma per essere precisi, l'ho modificato così:
Ad ogni modo lo script risulta corretto, e il problema potrebbe essere la directory 'cartella'.
Ha i permessi di scrittura per l'user x? Non è che quando l'hai creata, l'hai creata come root, e l'user x non può scriverci dentro?
Inoltre se i file esistono già in quella directory, può capitare che non puoi sovrascriverli.
Di solito cron manda una mail a root alla fine di ogni script che ha generato un output, oppure puoi dirgli di farlo. Ti sarebbe utile per capire dove lo script si ferma. In /etc/crontab (se nella tua distro esiste un crontab) puoi inserire quanto segue:
Saluti.
Codice: Seleziona tutto
/bin/sleep 1
cd /var/log/squid
filenamea="access.log.1.gz"
filenameb="cache.log.1.gz"
filenamec="store.log.1.gz"
hostname="h"
username="x"
password="y"
/usr/bin/ftp -n $hostname <<EOF
quote USER $username
quote PASS $password
binary
cd cartella
put $filenamea $filenamea.A
put $filenameb $filenameb.B
put $filenamec $filenamec.C
quit
EOF
Ha i permessi di scrittura per l'user x? Non è che quando l'hai creata, l'hai creata come root, e l'user x non può scriverci dentro?
Inoltre se i file esistono già in quella directory, può capitare che non puoi sovrascriverli.
Di solito cron manda una mail a root alla fine di ogni script che ha generato un output, oppure puoi dirgli di farlo. Ti sarebbe utile per capire dove lo script si ferma. In /etc/crontab (se nella tua distro esiste un crontab) puoi inserire quanto segue:
Codice: Seleziona tutto
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
Saluti.
- andrewp
- Messianic Network master
- Messaggi: 2199
- Iscritto il: lun 13 giu , 2005 7:32 pm
- Località: Roma
I permessi e l'owner della cartella sono corretti, i file nella cartella di destinazione non esistono.jbg70 ha scritto:Ad ogni modo lo script risulta corretto, e il problema potrebbe essere la directory 'cartella'.
Ha i permessi di scrittura per l'user x? Non è che quando l'hai creata, l'hai creata come root, e l'user x non può scriverci dentro?
Inoltre se i file esistono già in quella directory, può capitare che non puoi sovrascriverli.
Ho modificato lo script inserendo i full path...vediamo che succede domani.
Manipolatore di bit.
- andrewp
- Messianic Network master
- Messaggi: 2199
- Iscritto il: lun 13 giu , 2005 7:32 pm
- Località: Roma
Dopo un po di troubleshooting....ecco il problema:
Bye.
nel mio client era previsto lo switch -u....manualmente funzionava mentre schedulato in crontab restituiva un errore!Tolto il -u lo script viaggia che è una meraviglia.jbg70 ha scritto:anche se ho tolto -u all'ftp perchè nel mio client ftp non è previsto lo switch -u
Bye.
Manipolatore di bit.
- andrewp
- Messianic Network master
- Messaggi: 2199
- Iscritto il: lun 13 giu , 2005 7:32 pm
- Località: Roma
Dal man dell' ftp:
Codice: Seleziona tutto
-u Restrains ftp from attempting ‘‘auto-authentication’’ upon initial connection. If auto-authentication is enabled, ftp
attempts to authenticate to the FTP server by sending the AUTH
command, using whichever authentication types are locally supported. Once an authentication type is accepted, an authentica-
tion protocol will proceed by issuing ADAT commands. This
option also disables auto-login.
Manipolatore di bit.