Cronjob heeft problemen met MySQL

Dag beste GoTjes,

Ik heb een zeer eenvoudig script gemaakt. Het doet niet meer dan kijken of in de database een 1 of een 0 staat. Indien een 1 moet er een reboot gebeuren. Als ik het bestand gewoon in mijn webbrowser aanroep dan krijg ik gewoon een blanco pagina, zoals het hoor, er is dus geen error.

Om daadwerkelijk te rebooten heb ik een cronjob nodig, waarmee ik root-acces verkrijg en dus kan rebooten. Nu blijkt de cron een probleem te ondervinden met de db.

[root@esli-server ~]# /usr/bin/php /opt/lampp/htdocs/down.php
PHP Warning:  Zend Optimizer does not support this version of PHP -
please upgrade to the latest version of Zend Optimizer in Unknown on
line 0
<pre>Regelnummer: 4<br>Bestand:
/opt/lampp/htdocs/down.php<br>Foutmelding: SQLSTATE[HY000] [2002]
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2)<br></pre> [root@esli-server ~]#

Iemand enig idee waar het mis loopt?

De databaseserver is trouwens gewoonweg localhost.

Je mysql is niet gestart ? .
Of een non default socket locatie?
Of geen goed password?
DIt is verder nos voer.

En, wat heb je zelf al uitgevlooid? Kun je wel met de mysql client connecten?

Lijkt me sowieso vreemde manier: een 1 of 0 bekijken in een database voor het rebooten: lijkt me logischer om reboot te doen vanuit script: zo heb je gelijk ervoor gezorgd dat hij niet 'perongelijk' op 1 kan blijven staan, waardoor de server constant opnieuw blijft opstarten hierdoor.

Eerste waarschuwing is dat Zend niet goed samenwerkt met de huidige versie van PHP (update doen?), maar zal waraschijnlijk dit niet veroorzaken.

Mysl-connectie goed tot stand gekomen? Sowieso zie ik dat Google er al verstand van heeft.

Ik ken de layout van lampp verder niet, maar ik denk dat je de verkeerde php aanroept. Dat een vlugge zoekquery mij liet weten dat er een bestand /opt/lampp/etc/php.ini bestaat bevestigt dat vermoeden min of meer. Het lijkt me dat je dus de binary uit de lampp-map moet hebben omdat die in het juiste pad naar de config-file zoekt, die vervolgens weer naar de juiste mysql-socket wijst (die waarschijnlijk ook in /opt/lampp staat).

quote:

vmsw schreef op zondag 28 september 2008 @ 21:01:
Lijkt me sowieso vreemde manier: een 1 of 0 bekijken in een database voor het rebooten: lijkt me logischer om reboot te doen vanuit script: zo heb je gelijk ervoor gezorgd dat hij niet 'perongelijk' op 1 kan blijven staan, waardoor de server constant opnieuw blijft opstarten hierdoor.

Eerste waarschuwing is dat Zend niet goed samenwerkt met de huidige versie van PHP (update doen?), maar zal waraschijnlijk dit niet veroorzaken.

Mysl-connectie goed tot stand gekomen? Sowieso zie ik dat Google er al verstand van heeft.

Waarchijnlijk komt dat omdat hij de command-line versie van PHP gebruikt.

Overigens is een blanco pagina geen garantie dat er niks fout gaat; error reporting kan uit staan. Probeer anders even naar localhost te connecten.

quote:

Frash schreef op zondag 28 september 2008 @ 21:04:
[...]

Waarchijnlijk komt dat omdat hij de command-line versie van PHP gebruikt.

Eerste resultaat heeft zelfde foutmelding, vandaar. Daarnaast ook nog eens opgelost, dus een goede referentie. (en natuurlijk een hint eerst google te gebruiken)

Probeer sowieso even wat dingen te testen, die hiervoor o.a. genoemd zijn, en de overige default controle's om dingen uit te sluiten. Zodra je dingen hebt uitgesloten, en er niet uit komt, is het voor ons gemakkelijker/beter om jou te helpen.

Dit is op zich geen brakke php versie (mischien wel de php-mysql plugin vergeten, dat kan), maar lijkt me verdacht veel op een mysql probleem.
Daarom: kun je nou connecten met de mysql client, ts?

quote:

/opt/lampp/htdocs/down.php<br>Foutmelding: SQLSTATE[HY000] [2002]
Can't connect to local MySQL server through socket

Is vrij duidelijk he .

quote:

DataGhost schreef op zondag 28 september 2008 @ 21:04:
Ik ken de layout van lampp verder niet, maar ik denk dat je de verkeerde php aanroept. Dat een vlugge zoekquery mij liet weten dat er een bestand /opt/lampp/etc/php.ini bestaat bevestigt dat vermoeden min of meer. Het lijkt me dat je dus de binary uit de lampp-map moet hebben omdat die in het juiste pad naar de config-file zoekt, die vervolgens weer naar de juiste mysql-socket wijst (die waarschijnlijk ook in /opt/lampp staat).

Dit ga ik eens testen, lijkt me een nuttig antwoord. Denk dat ik me van path heb vergist.

Trouwens aan de overigen antwoorden:

PHP erros staan 100% zekerheid aan.
Ik kan perfect via PHP zelf connecten naar de database

Dat is net de rede waar om ik er geen raad mee weet.

Ga direct is het path nakijken.

Het lag idd aan het path.

/opt/lampp/bin/php moest dit zijn ipv /et/bin/php. Voro gewoon zuvier shutdown gign dit wel perfect, maar nu dus die verkeerde verwijzing.

Bedankt!

Lorduh wijzigde dit bericht 28-09-2008 21:20 (24%)

quote:

vmsw schreef op zondag 28 september 2008 @ 21:01:
Lijkt me sowieso vreemde manier: een 1 of 0 bekijken in een database voor het rebooten: lijkt me logischer om reboot te doen vanuit script: zo heb je gelijk ervoor gezorgd dat hij niet 'perongelijk' op 1 kan blijven staan, waardoor de server constant opnieuw blijft opstarten hierdoor.

Dus je wilt gewoon de shut-downcomamndo draaien vanuit de cronjob? Kan leuk worden als dat elke ** tijd gebeurt .

Ik geloof dat het de bedoeling was (ik ken de TS) om vanauit een beheerpaneel een reboot status te geven, en via de cronjob te laten uitvoeren omdat die root rechten heeft. Apache wil je zeker niet met root-rechten laten draaien.

Mischien een suid scriptje of sudo achtige gein uithalen?

@vmsw & Boudewijn.

Deze manier is helemaal niet zo vreemd. Sterker nog, ik denk dat dit 1 van de veiligere manieren is. Het punt is dat het op deze manier niet nodig is om je phpscripts een mogelijkheid te kunnen bieden om root te worden. Sudo zou nog kunnen, alhoewel het goed opletten is dat je niet te veel rechten geeft, maar een suid zou ik al helemaal afraden. Voor je het weet is er ergens door een brak php script een root terminal gestart.

Uiteraard is het heel belangrijk dat je goed borgt dat hij niet in een oneindige rebootlus terecht komt. Wat je eventueel zou kunnen doen is niet een 1 of 0 opslaan, maar de huidige tijd en dan het cron scriptje laat kijken of de vorige reboot voor of na die tijd is.

En wat als er nou morgen een apache exploit geworden wordt terwijl die als root draait? Of er een brak php script als root wordt gedraaid.


Is het niet veel netter om het zo te doen:

Bash scriptje als root draaien vanuit een cronjob.
Scriptje pollt telkens of een int-veld in de DB '1' is oid.
If so, reboot.

Nu alleen nog zorgen dat je niet blijft rebooten (minstens 1 uur uptime afdwingen voor reboot?).

Gevolg is dus dat je je script netjes als root kunt draaien zonder directe communicatie met apache\php.

Boudewijn wijzigde dit bericht 29-09-2008 11:22 (58%)

Bouwewijn: dat is precies wat de TS doet, alleen dan geen bash script maar een PHP script.

Uhh ja ik was echt absoluut niet wakker, excuses .

Klopt doe ik. Ik voer mijn PHP script uit via cronjob. Mijn cronjob kan zich dan even voordoen als root, mits dat dit onder root draait. Ik kan dit PHP script trouwens ook evt. buiten mijn online ruimte doen. (Ben ik ook van plan) Gewoon dus via een script in de DB een eentje of nulletje zetten, mijn cronjob kijkt dan buiten de webdir, waar dus niemand anders aan kan, en daar gebeurt de reboot dan . Lijkt me veilig, toch?

quote:

Lorduh schreef op zondag 28 september 2008 @ 20:56:
Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2)
[..]
Iemand enig idee waar het mis loopt?

Ik begrijp de vraag niet. Het is toch glashelder wat daar staat? Precies wat Boudewijn al in de eerste reactie zegt: je MySql server draait niet of je probeert de MySql server op de verkeerde poort te benaderen. Misschien heb je een tikfout in je script en probeer je localhots te benaderen ofzo; zonder script kunnen we daar natuurlijk ook niks over zeggen...

quote:

Lorduh schreef op zondag 28 september 2008 @ 21:13:
[...]

Dit ga ik eens testen, lijkt me een nuttig antwoord. Denk dat ik me van path heb vergist.

Trouwens aan de overigen antwoorden:

PHP erros staan 100% zekerheid aan.
Ik kan perfect via PHP zelf connecten naar de database

Dat is net de rede waar om ik er geen raad mee weet.

Ga direct is het path nakijken.

Het lag idd aan het path.

/opt/lampp/bin/php moest dit zijn ipv /et/bin/php. Voro gewoon zuvier shutdown gign dit wel perfect, maar nu dus die verkeerde verwijzing.

Bedankt!

Ik zie het toch, het probleem is opgelost?

Hierboven werd alleen even de veiligheid betwist, en ik ga daar op in.

quote:

Lorduh schreef op maandag 29 september 2008 @ 20:17:
Ik zie het toch, het probleem is opgelost?

Ik mistte even dat het probleem inderdaad al gevonden was; ik dacht dat er aleen nog maar offtopic over de veiligheid gediscussieerd werd.