Newsgroup: it.comp.os.linux.sys
Titolo: crontab e $PATH

Ciao gruppo!
Perchè cron al momento dell' esecuzione di un job utilizza una
variabile PATH diversa da quella che è normalmente di sistema?
# env | grep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ma se metto in cron...
* * * * * echo $PATH > /tmp/PATH
mi ritrovo...
# cat /tmp/PATH
/usr/bin:/bin
In /etc/crontab ho specificato:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
..ma sembra non interessargli un granchè...
Cos' altro mi sfugge ?

 * * * * * echo $PATH > /tmp/PATH
Ma questo lo hai metsso in /etc/crontab con l'editor oppure lo
hai messo digitando crontab -e   ?
Perche' nel primo caso la sintassi e' sbagliata, manca lo user,
nel secondo caso lo hai scritto in /var/spool/cron/contabs/...
-- 
Stefano L.

no l' ho inserito via crontab -e...
Ma quindi via crontab -e non c'è modo di passare/settare una variabile
PATH?

 Perche' cron non e' il tuo utente.
Però se esplicita il PATH in /etc/crontab, cron dovrebbe leggere 
l'impostazione.
Piuttosto... chiedere se ha fatto un killall -HUP cron? (o crond, 
dipende dalle distribuzioni)? In alcune, tipo Debian, dicono che non 
serve, ma per non sapere né leggere né scrivere io l'ho sempre fatto, 
tanto male non fa.
Varrebbe la pena provare...
-- 
Massimo Bacilieri AKA Crononauta

 tanto male non fa.
Mai vista una distro in cui fosse necessario, dopo crontab -e...
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 


# ps aux | grep cron
root      3627  0.0  0.0   2376   900 ?        Ss   Sep15   0:00 cron
crontab  -e -u root
* * * * * echo $PATH > /tmp/PATH
non capisco la tua affermazione...


# ps aux | grep cron
root      3627  0.0  0.0   2376   900 ?        Ss   Sep15   0:00 cron
crontab  -e -u root
* * * * * echo $PATH > /tmp/PATH
non capisco la tua affermazione...

 Mai vista una distro in cui fosse necessario, dopo crontab -e...
Assolutamente vero.
Però si parlava di /etc/crontab. Se fai crontab -e da root, non vai a 
modificare /etc/crontab, ma crei un crontab per l'utente root, cosa che 
non ha molto senso, anche se funzionalmente può lavorare come /etc/crontab.
Però ha fatto crontab -e o ha modificato /etc/crontab? Avevo capito la 
seconda.



# ps aux | grep cron
root      3627  0.0  0.0   2376   900 ?        Ss   Sep15   0:00 cron
crontab  -e -u root
* * * * * echo $PATH > /tmp/PATH
non capisco la tua affermazione...

  ha scritto nel messaggio

la prima...

 la prima...
Allora ti consiglio di fare le cose come vanno fatte, evita dei crontab 
dell'utente root, modifica /etc/crontab e fai killall -HUP cron alla fine.


 non capisco la tua affermazione...
Il fatto che cron giri con i permessi di root non vuol dire che abbia lo
stesso ambiente. Anzi, cron parte con un ambiente limitato proprio
per limitare eventuali danni.
Qui c'è una buona spiegazione:
http://linuxshellaccount.blogspot.com/2007/10/crontab-and-your-environment.html


 seconda.
Ah ecco, io invece la prima. Comunque ho appena controllato il man:
[...] cron checks each minute to see if its spool directory's modtime (or
the modtime on /etc/crontab) has changed [...]
Thus cron need not be restarted whenever a crontab file is modified.
E' una cosa interessante, io non ci avevo mai pensato!


 ha scritto nel messaggionews:i6shu0$gcn$
2...@tdi.cu.mi.it

Ma se provi anche a riavviare cron dopo aver fatto un:
crontab  -e -u root
* * * * * echo $PATH > /tmp/PATH
cosa ti ritrovi nel file /tmp/PATH ?

 cosa ti ritrovi nel file /tmp/PATH ?
Ma tu l'hai letto il link che ti ho inviato?
-- 
ValeRyo


 GamerTag:
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
^-_^ Mi era sfuggito ^-_^


Bho io continuo a non riuscire a settare la variabile PATH di mio
gradimento...
ho aggiunto ad /etc/default/cron
PATH=/usr/bin:/usr/sbin:/sbin
ma continua a far girare i jobs con
PATH=/usr/bin:/usr/sbin
...

 PATH=/usr/bin:/usr/sbin:/sbin
E dopo questo hai riavviato cron?
In seconda battuta: sei sicuro che quel file serva a fare ciņ che vuoi?
Io piuttosto nella crontab di riferimento metterei
PATH=/usr/bin:/usr/sbin:/sbin
Ho l'impressione che tu stia provando un po' a casaccio, ti converrebbe
leggere la documentazione...
-- 
ValeRyo


Stefano L. ha scritto:

  C'č almeno un crond che usa solo file di cron per utente, non ha
/etc/crontab, la cui funzione č invece sostituita dal crontab dell'utente
root.  Credo sia fcron (
http://fcron.free.fr/
) a funzionare cosě.
  O meglio, per essere piů precisi, non ha bisogno del crontab di sistema,
ma se il superutente lo vuole puň editarselo e poi fare # fcrontab
/etc/fcrontab invece di fcrontab -e
(
http://fcron.free.fr/doc/en/fcrontab.1.html
).  Le due maniere di fare sono
equivalenti.  Ma il demone fcron(8) di suo non va a cercarsi /etc/fcrontab
all'avvio.
  Ciao,
-- 
Alessandro Selli, 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 leggere la documentazione...
Può essere che stia tirando a caso ma nella documentazione non trovo
nulal che mi sia di aiuto...ecco eprchè chiedo un parere qui...
Ecco cosa non funziona...(il tutto su una macchina di test)
00 10 * * * /usr/bin/apt-get upgrade -y
Ecco cosa ritorna:
6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/24.7MB of archives.
After this operation, 0B of additional disk space will be used.
dpkg: warning: 'ldconfig' not found on PATH.
dpkg: warning: 'start-stop-daemon' not found on PATH.
dpkg: warning: 'update-rc.d' not found on PATH.
dpkg: 3 expected program(s) not found on PATH.
Ecco perchè mi serve la variabile $PATH
La soluzione quindi è quella di usare /etc/crontab piuttosto di
crontab -e?

 crontab -e?
Uhm, no, non è quello il problema... adesso mi pare chiaro. Io direi che 
il problema è che dovresti ESPORTARE la variabile PATH, perché apt-get 
esegue a sua volta dei programmi in altre subshell che però riprendono 
così il path di default. E infatti sono loro che vanno in errore.
Siccome credo che in crontab non sia ammessa la direttiva export, a 
naso, io proverei a fare uno script in /usr/local/sbin/script.sh tipo 
questo:
#!/bin/bash
export PATH=/bin:/usr/bin:/usr/sbin:/usr/salcaz...
apt-get upgrade -y
gli dai un chmod 0700 e poi esegui *questo* script dentro il cron:
0 10 * * * /usr/local/sbin/script.sh
Se è come penso, così dovrebbe funzionare.


 00 10 * * * /usr/bin/apt-get upgrade -y
ok, ora prova cosģ
PATH=scriviiltuopath
00 10 * * * /usr/bin/apt-get upgrade -y
-- 



avevo pensato anche io di creare uno script con dentro definite le
variabili, ma mi sembrava una soluzione poco ortodossa...
In ogni caso così funziona... ma davvero faccio fatica a comprendere
come cron non permetta di utilizzare o settare la variabile PATH..

 ha scritto:

minchia però.
$ man 5 crontab
[CUT]
Note in particular that if you want a PATH other than "/usr/bin:/bin",
you will need to set it in the crontab file.
Per quanto riguarda il file di cron, prima delle direttive puoi mettere
alcune variabili valide per il cron. Esempio di file di crontab:
PATH=/di/qua:/di/la:/di/su:/giù
SHELL=/bin/bash
5 0 * * *       $HOME/bin/this_is_a_secheduled_job.sh
* * * * *	/this/is/shit.sh
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"


Facebook: Massimo Bacilieri

 
questa però è tutta un'altra storia (che comunque hai fatto bene a
evidenziare, per evitare di incorrere in altro tipo di errori). 
cron accetta comunque TRE variabili: HOME, LOGNAME e PATH e tu *puoi*
impostare queste tre variabili in cima al file del crontab.
Aggiungiamo quindi che le variabili non possono essere "nested" quando
vengono dichiarate. 


 cron accetta comunque TRE variabili: HOME, LOGNAME e PATH
be' accetta anche SHELL ... insomma, accetta quel che sono scritte
nella man page.


 
/me dorme .... anche di giorno.
Tu ti riferivi al fatto che ho scritto:
5 0 * * *       $HOME/bin/this_is_a_secheduled_job.sh
Lo sai perché ti dico che funziona?
Non perché ho studiato la scienza dei razzi, ma perché è una riga che
ho copiato sempre da "man 5 crontab" ;-)
Forse lui si riferisce al caso in cui usi la variabile per la
sostituzione di un'altra:
PATH = $HOME/bin:$PATH --> won't work
e allora se capiamo bene:
PATH = $PATH:/blabla/blabla
non funziona nemmeno!


 nella man page.
Aggiungiamo anche MAILTO allora :D



Le shell lanciate da crontab prendono la profilazione da
/etc/profile (sì, lo so che non c'è nel man, ma è così).
Ma modificare /etc/profile non è una buona idea.
La cosa più corretta è inserire in testa ad ogni shell che lanci una 
shell di profilazione
. /<app_dir>/<profiling>
Così puoi configurarti i tuoi path come più ti aggrada e superi il 
problema delle nested shell.