[Debian + mysqlcheck]Cronjob faalt

[van.der.schulting]

Ik heb de volgende cronjob:

code:

#OPTIMIZE TABLES
02 2   * * *    /var/scripts/db/optimize.sh >/dev/null

Deze cronjob faalt de laatste tijd dagelijks met de volgende melding:

code:

/usr/bin/mysqlcheck: Error: Couldn't get table list for database #mysql50#lost+found: Can't read dir of './lost+found/' (errno: 13)

Even wat overige info:

code:

OS: Debian 6 squeeze
Mysql versie 5.1.66-0+squeeze1-log

Als ik het command handmatig uitvoer, is er niks aan de hand...
Ik dacht dit even snel op te lossen met de hulp van Google, maar tot mijn grote verbazing loopt mijn zoektocht via google telkens op niets uit. Dit terwijl het toch niet zo ingewikkeld zou moeten zijn...

Kan iemand me vertellen wat er aan de hand is of me een schop in de goede richting geven waar ik moet zoeken?

[Hero of Time]

Moeten we eerst weten wat je script doet. Voor hetzelfde geld doet 't alleen maar een ls -l op /, en dan krijg je idd dat hij lost+found niet kan lezen, want dit is afgeschermd.

[van.der.schulting]

Dit is het script:

code:

#!/bin/bash

#PATH:/usr/bin/

/usr/bin/mysqlcheck -uda_admin -p`grep "^passwd=" /usr/local/directadmin/conf/mysql.conf | cut -d= -f2` --auto-repair --check --optimize --all-databases

test -t 0 && exit 0

Wat je stelt 'Voor hetzelfde geld doet 't alleen maar een ls -l op /, en dan krijg je idd dat hij lost+found niet kan lezen, want dit is afgeschermd' snap ik niet helemaal. Waarom geeft een cronjob wel die melding, maar als ik als gewone root het commando 'ls -l' uitvoer op /, dan krijg ik nergens een melding van...??

[Hero of Time]

De locatie waar je databases staan, is dat een aparte partitie/schijf? Want dan krijg je precies wat je zou verwachten.

Als root mag je overal in, dus ook in lost+found kijken. Maar als je cronjob als andere gebruiker wordt uitgevoerd, zoals onder de mysql gebruiker, tja, there's your problem.

[van.der.schulting]

Yupz het is een aparte HDD.

Ik voer de cronjob niet uit als de user mysql, maar als de user 'root', dus ik zou zweren dat dat het probleem niet is...

Ik heb de cronjob nu even verwijderd uit de crontab van de root en toegevoegd aan de crontab van de mysql user. Wie weet lost dat juist het probleem op...

[ Voor 34% gewijzigd door van.der.schulting op 22-04-2013 17:38 ]

[Hero of Time]

Je commando zal uiteindelijk toch als mysql user draaien. Check maar eens welke mappen er worden aangegeven in je conf bestand die je aanroept. Heb je enig idee wat je commando uitvoert? Enig idee wat z'n opties zijn die hij meekrijgt van de verschillende commando's die je gebruikt?

Als het een copy/paste was, had er net zo goed een rm -rf /* kunnen staan en had je 't zonder nadenken overgenomen.

[van.der.schulting]

In het conf bestand wat wordt aangeroepen staat alleen het password en verder helemaal niets...

Als ik het commando in de crontab van de mysql user stop krijg ik dit:

code:

/bin/sh: /var/scripts/db/optimize.sh: Permission denied

Als ik het script handmatig uitvoer onder sudo of mijn eigen user, krijg ik onderstaande output:
Let maar eens op de eerste regel.
Ik begin nu het idee te krijgen dat ik me druk maak om niks en dat het script gewoon werkt en dat hij alleen de 'warning' mailt.
Desalniettemin zou het prettig zijn als ik die warning gewoon kan wegkrijgen.

code:

/usr/bin/mysqlcheck: Error: Couldn't get table list for database #mysql50#lost+found: Can't read dir of './lost+found/' (errno: 13)
mysql.columns_priv                                 Table is already up to date
mysql.db                                           Table is already up to date
mysql.event                                        Table is already up to date
mysql.func                                         Table is already up to date
mysql.general_log
note     : The storage engine for the table doesn't support optimize
mysql.help_category                                Table is already up to date
mysql.help_keyword                                 Table is already up to date
mysql.help_relation                                Table is already up to date
mysql.help_topic                                   Table is already up to date
mysql.host                                         Table is already up to date
mysql.ndb_binlog_index                             Table is already up to date
mysql.plugin                                       Table is already up to date
mysql.proc                                         Table is already up to date
mysql.procs_priv                                   Table is already up to date
mysql.servers                                      Table is already up to date
mysql.slow_log
note     : The storage engine for the table doesn't support optimize
mysql.tables_priv                                  Table is already up to date
mysql.time_zone                                    Table is already up to date
mysql.time_zone_leap_second                        Table is already up to date
mysql.time_zone_name                               Table is already up to date
mysql.time_zone_transition                         Table is already up to date
mysql.time_zone_transition_type                    Table is already up to date
mysql.user                                         Table is already up to date
phpmyadmin.pma_bookmark                            Table is already up to date
phpmyadmin.pma_column_info                         Table is already up to date
phpmyadmin.pma_designer_coords                     Table is already up to date
phpmyadmin.pma_history                             Table is already up to date
phpmyadmin.pma_pdf_pages                           Table is already up to date
phpmyadmin.pma_relation                            Table is already up to date
phpmyadmin.pma_table_coords                        Table is already up to date
phpmyadmin.pma_table_info                          Table is already up to date
phpmyadmin.pma_tracking                            Table is already up to date

[Hero of Time]

Die eerste permission denied als je 't onder de mysql user draait kan door verschillende dingen komen, maar de meest voor de hand liggende reden is dat 'other' het script niet mag uitvoeren of lezen.

Om de melding weg te krijgen, moet je een output redirect toepassen. Er zijn verschillende outputs namelijk, stdout, stderr en nog een paar die ik niet uit m'n hoofd ken. Her op zoeken moet je al wat geven.
We kunnen je 't antwoord direct geven, maar daar leer je niets van .

[vanaalten]

Hero of Time schreef op dinsdag 23 april 2013 @ 11:16:
Om de melding weg te krijgen, moet je een output redirect toepassen. Er zijn verschillende outputs namelijk, stdout, stderr en nog een paar die ik niet uit m'n hoofd ken.

Errors naar /dev/null redirecten, bedoel je? Lijkt mij bepaald niet de meest wenselijke oplossing: als het script ooit serieus errors gaat genereren ben je uren bezig met debuggen voor je de oorzaak doorhebt. Dan liever nu nog wat debuggen om de oorzaak te snappen en goed op te lossen, toch?

[CyBeR]

Dat is gewoon mysql die probeert de lost+found dir als database te lezen, wat niet lukt want hij heeft er geen permissions op. De error kun je wel wegtoveren met output redirection maar dan ben je de rest van je errors ook kwijt.

Probeer die lost+found dir eens gewoon permissions te geven zodanig dat mysql er bij mag. (Om er vervolgens achter te komen dat 't geen db is.)

[Hero of Time]

Beter is juist om lost+found in de ignore te zetten van mysql, zodat deze 't niet gaat proberen te lezen.

Enne, een redirect van stderr hoeft 't niet altijd naar /dev/null te gaan. je kan 't ook naar een bestand dumpen, bijvoorbeeld /tmp/dbcheck-errors. Die zou je dan weer kunnen mailen naar jezelf, ipv dat 't in je cron mail komt.

Zat mogelijkheden om 't op te lossen.

[Anoniem: 118213]

Al eens eerder met een script gehad. Mysqldump geloof ik.

"#mysql50#lost+found" vinden de meeste scripts geen lieve databasenaam, en gaan over d'r nek.

[CyBeR]

Hero of Time schreef op dinsdag 23 april 2013 @ 13:44:
Beter is juist om lost+found in de ignore te zetten van mysql, zodat deze 't niet gaat proberen te lezen.

Die optie bestaat pas sinds mysql 5.6.3, dus dat gaat deze mysql 5.1-gebruiker niet helpen.


De beste optie is nog om de data dir te verplaatsen naar een subdirectory van de partitie. Dan ben je de lost+found kwijt (die staat namelijk in de root) plus alle eventuele andere zaken die 't OS nog zou kunnen bedenken.