[X-post] Comando che funziona da CLI ma non da Crontab (Debian Bookworm)

[^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.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

[Neoviruz]

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
--

[^Bart]

Post by Neoviruz
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]

Post by ^Bart
*/5 * * * * /usr/bin/mysql -u MY_USER -pMY_PASSWORD <
/home/itoffice/query.sql

Ho verificato anche questo ma non dovrebbe essere un problema:

CRON[8465]: (CRON) info (No MTA installed, discarding output)
CRON[8465]: pam_unix(cron:session): session closed for user itoffice

Post by ^Bart
Saluti.
^Bart

[Stefano L.]

Post by ^Bart
CRON[8465]: (CRON) info (No MTA installed, discarding output)
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 ?

[^Bart]

Post by Stefano L.
Credo stia cercando di mandare una mail con l'errore...

E come già indicato da un altro utente del n.g. non c'è un MTA configurato.
Ho risolto in questo modo:

*/5 * * * * /home/itoffice/job01.sh

Questo è job01.sh

#!/bin/bash
#sostituisce tutte le virgole presenti nel file con dei punti
sed -i -e 's/,/./gip' /home/itoffice/data_bridge/articoli.txt

/usr/bin/mysql -umy_username -pmy_password < /home/itoffice/articoli.sql

#copia del file importato nella directory di backup
mv -v /home/itoffice/data_bridge/articoli.txt
"/home/itoffice/data_bridge_bck/articoli_$(date +"%d-%m-%Y_%H-%M".txt)"

Post by Stefano L.
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

[sm]

Post by ^Bart

Post by ^Bart
*/5 * * * * /usr/bin/mysql -u MY_USER -pMY_PASSWORD <
/home/itoffice/query.sql

CRON[8465]: (CRON) info (No MTA installed, discarding output)
CRON[8465]: pam_unix(cron:session): session closed for user itoffice

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.

[^Bart]

Post by sm
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.

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

[sm]

Post by ^Bart

Post by sm
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.

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.

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.

[^Bart]

Post by sm
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).

Corretto quello che dici però nel complesso di quello che dovevo fare ho
capito che usare uno script mi avrebbe permesso di inserire tutti i
comandi (sed, mv, sql) in un unico file.

Post by sm
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.

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

[sm]

Post by ^Bart

Post by sm
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.

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.

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.

[Giuseppe Della Bianca]

Post by ^Bart

Post by Neoviruz
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

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 ....

[^Bart]

Post by Giuseppe Della Bianca
Comunque potresti provare con
*/5 * * * * su - utentechefuniona -c '/usr/bin/mysql ....'
o
*/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

[servoloro]

Post by ^Bart
*/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
;-)

[sm]

Post by ^Bart
*/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 ;-)

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'è.

[sm]

Post by ^Bart
Ciao a tutti,
$ mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sql
*/5 * * * * mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sql
Non ne riesco a capirne il motivo... :\

Figurati noi, che non siamo neanche lì.

Scrivi l'output su un file e postalo qui.

[MarioCCCP]

Post by ^Bart
Ciao a tutti,
$ mysql -u MY_USER -pMY_PASSWORD < /home/itoffice/query.sql
*/5 * * * * mysql -u MY_USER -pMY_PASSWORD <
/home/itoffice/query.sql
Non ne riesco a capirne il motivo... :\
Saluti
^Bart

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

[^Bart]

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.

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