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

^Bart <gabriel...@hotmail.com> ha scritto:r
> 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]

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

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

> Saluti.
> ^Bart

[Stefano L.]

Il 03/11/23 17:05, ^Bart ha scritto:

> 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

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.

[sm]

Figurati noi, che non siamo neanche lì.

Scrivi l'output su un file e postalo qui.

[Giuseppe Della Bianca]

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

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

[^Bart]

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

> Prova con:

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

> 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

[^Bart]

> 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

[^Bart]

> 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

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

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.

[MarioCCCP]

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

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

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.

> 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

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

[sm]

Il Sun, 26 Nov 2023 15:40:11 +0100, ^Bart ha scritto:


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