Newsgroup: it.comp.os.linux.iniziare
Titolo: [X-post] Comando che funziona da CLI ma non da Crontab (Debian Bookworm)

Ciao a tutti,
 
chiedo venia per l'X-post, il seguente comando funziona da CLI:
$ mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sql
 
ma non funziona da crontab -e ed anche da root:
*/5 * * * * mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sql
 
Non ne riesco a capirne il motivo... :\
 
Saluti
^Bart

 Ciao a tutti,chiedo venia per l'X-post, il seguente comando funziona da CLI:$ mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sqlma non funziona da crontab -e ed anche da root:*/5 * * * * mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sqlNon ne riesco a capirne il motivo... :\Saluti^Bart
 
Usa il full path di mysql
-- 

> Usa il full path di mysql
 
Avevo già provato ma nisba da crontab anche con questo :\
 
*/5 * * * * /usr/bin/mysql -u MY_USER -pMY_PASSWORD < 
/home/itoffice/query.sql
 
Saluti.
^Bart

 ^Bart
 

 CRON[8465]: pam_unix(cron:session): session closed for user itoffice
 
Credo stia cercando di mandare una mail con l'errore...
 
Prova con:
 
*/5 * * * * /usr/bin/mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sql >> /tmp/zerrore 2>&1
 
e guarda cosa scrive in /tmp/zerrore
 
 
A parte questo, stai usando il file /etc/crontab o quello dell'utente ?
 
 
-- 
Stefano L.
 

 */5 * * * * mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sql
non so se puo' aiutare, ma io uso sta roba qui:
11 15 * * *  env DISPLAY=:0.0  /home/XX/CLIST.sh
... il "culrprit" e' l' [env DISPLAY=:0.0]
spero ti possa essere utile
;-)
 
 


Figurati noi, che non siamo neanche lì.
 
Scrivi l'output su un file e postalo qui.


No non serve a nulla in questo caso (invero non ho capito neanche a che 
serva nel tuo).
 
Molto probabilmente è che usa lo stdin ma non essendo un tty lo stdin non 
c'è.


Da quello che ricordo potrebbe essere che l'utente root del db non è 
impostato o non è accessibile per tutti i domini.
 
Comunque potresti provare con 
 
*/5 * * * * su - utentechefuniona -c '/usr/bin/mysql ....'
 
o 
 
*/5 * * * * utentechefuniona /usr/bin/mysql ....
 
 


Non è un problema, ma è ciò che te lo nasconde. Cron ha catturato l'output 
del comando, vorrebbe mandarlo per e-mail ma non essendo configurato un 
MTA lo scarta. Ovviamente in quell'output ci sarebbe la risposta alla tua 
domanda sul perché non funziona.

 A parte questo, stai usando il file /etc/crontab o quello dell'utente ?
 
Sto usando quello dell'utente (crontab -e) utente che da CLI riesce a 
lanciare la query sql e quindi ho risolto inserendo in crontab solo il 
lancio del job.
 
Terminata l'emergenza ora dovrò capire come mai php, pur avendo 
modificato il php.ini abilitando la funzione, non mi permetta di 
eseguire il "load data" del file, di seguito un paio di soluzioni che 
proverò a percorrere:
 
https://itecnote.com/tecnote/php-load-data-local-infile-forbidden-after-php-mariadb-update/
 
https://itecnote.com/tecnote/php-load-data-local-infile-forbidden-after-php-mariadb-update/
 
 
Saluti.
^Bart

 domanda sul perché non funziona.
 
Mi serviva chiudere la partita nel giro di breve quindi ho trovato come 
soluzione quella di inserire la query sql in un sh e mettere questo nel 
crontab dell'utente.
 
Appena avrò qualche minuto libero di sicuro configurerò un MTA tipo 
postfix ma soprattutto dovrò provare a risolvere il fatto che php non mi 
esegua il load data del file pur avendo modificato l'apposita riga nel 
php.ini ma da quel che ho letto in giro ci sono altri file dove tale 
modifica andrebbe eseguita.
 
Saluti.
^Bart

 */5 * * * * utentechefuniona /usr/bin/mysql ....
 
Come già accennato negli altri post ho risolto mettendo il tutto in uno 
script ed usando il crontab dell'utente per schedulare lo stesso.
 
Saluti.
^Bart
 


Mentre ti si indica la luna tu guardi il dito. Non ti stavo suggerendo di 
configurare un MTA ma ti stavo dicendo che l'errore era nascosto 
nell'output del comando scartato, output che potevi tranquillamente 
mandare ad un file di log come ti avevamo suggerito e come era logico fare 
sin da subito (e come sarebbe logico fare anche adesso, per inciso).
 
Senza contare che stai descrivendo il più classico dei paradossi da 
niubbo: non avere tempo per mettere le ruote tonde perché sei troppo 
impegnato a spingere il tuo carro dalle ruote quadrate.
 


ciao, scusami, ma MY_PASSWORD è la password di root o quella 
di accesso al database ? Il database a cui accedi ha o meno 
una password ? Se fossero differenti, a mysql potrebbe non 
stare bene agire sul db.
Il mio cent ...
 
-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP
 

 impegnato a spingere il tuo carro dalle ruote quadrate.
 
Come già detto sopra, il tuo discorso non fa una piega se lo 
riconduciamo al modus operandi di come risolvere un inghippo ma facendo 
un'analisi globale ho capito che, almeno stavolta, non mi avrebbe dato 
valore aggiunto metter mano a quella situazione.
 
Grazie comunque per tutte le info perché spesso può sfuggire qualcosa.
 
Saluti.
^Bart

 fossero differenti, a mysql potrebbe non stare bene agire sul db.
 
MY_USER è l'user di MariaDB che hai diritti di scrivere in un 
determinato DB e MY_PASSWORD è la password di quell'utente.
 
Saluti.
^Bart

 valore aggiunto metter mano a quella situazione.
 
Ovvio, tu sei quello dai casi particolari a cui le best practice non 
aggiungono mai valore.
 
D'altra parte a chi è mai capitato di schedulare un backup di MySQL? È una 
cosa che non fa nessuno.