Cronjob will nicht!

B

beta113

Member
Hallo,
ich habe Probleme mit einem Cronjob. Und zwar ich habe diesen in /etc/crontab eingetargen und wo es nicht funktioniert hat mit crontab -e. Beides hat nicht funktioniert.
Das script dient zum abschalten eines Game-Servers.
In den Logs wird folgendes angeziegt:
Dec 22 17:21:00 cl-t069-031cl /usr/sbin/cron[60872]: (root) CMD (/usr/home/game/auth/shut.sh)

Ich habe es auch schon einmal so probiert:
Dec 22 17:36:00 cl-t069-031cl /usr/sbin/cron[97367]: (root) CMD (sh /usr/home/game/auth/shut.sh)
Beides hat nicht geklappt der Server war noch online.

So sieht es im Crontab aus:
*/3 * * * * root /usr/home/game/auth/shut.sh
Weis jemand wo der Fehler liegt?
 
Anscheinend wird das Script ja ausgeführt...
Füge doch mal ein
Code: 
echo "ich werde ausgeführt" > datei.txt
ins Script ein, damit du sicher weißt das das Script läuft und vielleicht nur fehlerhaft ist.

Wieso willst du den Dienst alle 3 Minuten abschalten?


Grüße!
 
Kannst du ma dein script zeigen. cron macht nicht alles was per hand geht. Beispielsweise hatte ich Probleme mit "expect" kannst ja mal googlen "cron expect".
Es gibt evtl. Probleme mit den Umgebunsvariablen.
 
Das drei Minütige habe reingemacht um zu sehen obs überhaupt funktioniert.
So sieht das script aus:
#!/bin/sh
if [ -r ./pid ]; then
touch .killscript
kill -1 `cat ./pid`
else
echo 'server is not running.';
fi
Ich würde ihn dann auch hochfahren nur wenn das herunterfahren noch nicht einmal funktioniert.
 
Wie ich sagte, rufe mal nicht die Befehle so auf, sondern mit kompletten Pfad.

Also statt touch halt /usr/bin/touch oder statt cat halt /usr/bin/touch, je nachdem wo sie liegen. Genauso kill usw. Und auch keine relativen Pfade nehmen, sondern absolute. ./pid wird das Skript sicherlich nicht finden, da es meist von / aus aufgerufen wird.
 
THX für den Tipp -Nuke- er lässt sich jer herunterfahren nur jez lässt er sich nciht per cronjob starten.
Die Datei wodrüber gestartet wird kann man nicht auslesen und diese hat auch keine Endung.
Kann ich da etwas machen?
 
Was meinst du damit?
Hab es mal so ausprobiert:
#/bin/sh
/user/home/game/auth/auth


Geht aber nicht
normal starte ich es einfach so ./auth
 
Zuletzt bearbeitet:
Wenn du relative Pfade nutzen willst, musst du vorher mit cd ins Arbeitsverzeichnis.
./ heisst - aktuelles Verzeichnis. Der Cronjob kann aber nicht wissen, in welchem Verzeichnis du warst, als du die Scripte geschrieben und getestet hast. Also mussadahin
 
Vielleicht sind relative Pfadangaben im Script auth.
Das kann man schlecht sagen, ohne das Script zu kennen.
 
Wenn du das script nicht veraendern kannst, musst du halt vorher die Pfadvariablen setzen und probier es dann nochmal.
 
Nein, vorher in dem Script, dass Cron aufruft mit cd ins Workdir wechseln.
Sieht aus, als würde dieses auth-Dingens argv[0] prüfen, um sicher zu stellen, dass man im richtigen Verzeichnis ist.
Durch das setzen des Pfades im Environment würde argv[0] zu auth. Durch wechseln ins workdir zu ./auth. Also das, was gewollt ist.
 
troll schrieb:
Nein, vorher in dem Script, dass Cron aufruft mit cd ins Workdir wechseln.
Sieht aus, als würde dieses auth-Dingens argv[0] prüfen, um sicher zu stellen, dass man im richtigen Verzeichnis ist.
Durch das setzen des Pfades im Environment würde argv[0] zu auth. Durch wechseln ins workdir zu ./auth. Also das, was gewollt ist.
Zum Vergrößern anklicken....

Also funktioniert das nun oder nicht? Ich steige grade nicht durch sry.
 
was troll sagt, ist etwa dies:
wenn tatsächlich /user/home/game/auth/auth das script ist, welches den Server startet, dann steht ./auth dafür, dass sich ein Anwender aktuell im Verzeichnis /user/home/game/auth aufhält und dann in diesem ./ (also . = in dem Verzeichnis, wo ich bin) auth aufruft.
Wenn du manuell ./auth eingibst, solltest du sicherheitshalber erst mal mit pwd nachsehen, ob das tatsächlich so ist, denn es kann auch sein, dass ein auth für einen lokalen User angelegt worden ist und dieses den Server startet. Also, zunächst sicher sein, welches auth du aufrufst um den Server erfolgreich manuell zu starten.
Wenn dann der Aufruf dieses auth mit der Angabe des kompletten Pfades nicht mittels cron gelingt, dann meint troll, dass sehr wahrscheinlich in auth abgefragt wird, ob man auch im richtigen Verzeichnis steht um auth aufzurufen. Um es nun "auszutricksen" will troll, dass du nicht auth direkt in der crontab aufrufst, sondern ein kleines script und in diesem gibst du vor dem Aufruf des auth eine Zeile ein, die cd /zu/deinem/Pfad enthält und damit erst in das gewünschte Verzeichnis wechselt.
cd funktionierte zwar bei mir immer direkt, doch es gilt wieder der Hinweis: nicht Befehle, sondern die absoluten Pfade zu ihnen wirken sicherer.
Entsprechend wäre dann das script etwa

#/bin/sh
/usr/bin/cd /user/home/game/auth
./auth

wobei du den später sicher auch in den Hintergrund schicken willst und nicht auf die Ausgaben wartest, wie auch immer.
 
pit234a schrieb:
was troll sagt, ist etwa dies:
wenn tatsächlich /user/home/game/auth/auth das script ist, welches den Server startet, dann steht ./auth dafür, dass sich ein Anwender aktuell im Verzeichnis /user/home/game/auth aufhält und dann in diesem ./ (also . = in dem Verzeichnis, wo ich bin) auth aufruft.
Wenn du manuell ./auth eingibst, solltest du sicherheitshalber erst mal mit pwd nachsehen, ob das tatsächlich so ist, denn es kann auch sein, dass ein auth für einen lokalen User angelegt worden ist und dieses den Server startet. Also, zunächst sicher sein, welches auth du aufrufst um den Server erfolgreich manuell zu starten.
Wenn dann der Aufruf dieses auth mit der Angabe des kompletten Pfades nicht mittels cron gelingt, dann meint troll, dass sehr wahrscheinlich in auth abgefragt wird, ob man auch im richtigen Verzeichnis steht um auth aufzurufen. Um es nun "auszutricksen" will troll, dass du nicht auth direkt in der crontab aufrufst, sondern ein kleines script und in diesem gibst du vor dem Aufruf des auth eine Zeile ein, die cd /zu/deinem/Pfad enthält und damit erst in das gewünschte Verzeichnis wechselt.
cd funktionierte zwar bei mir immer direkt, doch es gilt wieder der Hinweis: nicht Befehle, sondern die absoluten Pfade zu ihnen wirken sicherer.
Entsprechend wäre dann das script etwa

#/bin/sh
/usr/bin/cd /user/home/game/auth
./auth

wobei du den später sicher auch in den Hintergrund schicken willst und nicht auf die Ausgaben wartest, wie auch immer.
Zum Vergrößern anklicken....



Ja das hatte ich soweit verstanden, aber war das letztendlich auch die Lösung?
 
Also funktioniert das nun oder nicht? Ich steige grade nicht durch sry.
Zum Vergrößern anklicken....
Ah, dann hatte ich dieses falsch gedeutet und etwas erklärt, was niemand wissen wollte.
Die Antwort, ob das auch funktioniert, findest du, indem du es selbst probierst (falls du so ein Problem auch hast) und es hier rückmeldest oder, indem beta113 eine Antwort gibt.

Bei mir selbst werden cronjobs aus /var/cron/tabs/ gestartet und für die einzelnen User verwaltet. Ein Beispiel:
# run every five minutes
*/5 * * * * sh /raid1/Exports/aiff2mp3.sh

damit starte ich alle fünf Minuten ein script aiff2mp3.sh und das sucht in bestimmten Ordnern nach bestimmten Dateien und macht dann damit was, wenn es sie findet und das funktioniert.
Also: Im Grundsatz funktioniert es, wie beschrieben und bei der speziellen Anwendung um die es hier ging, wird niemand das verbindlich beantworten können, der nicht exakt das gleiche Problem auch hat.
Hoffe, dich nun besser verstanden gehabt zu haben.
 
beta113 schrieb:
#/bin/sh
cd /usr/bin/cd /user/home/game/auth
/usr/bin/cd /user/home/game/auth/auth


das in den cronjob und dann hats geklappt
Zum Vergrößern anklicken....

Wie soll das irgendie auch nur ansatzweise irgendwas sinnvolles tun, ausser mehr oder weniger erleuchtende Fehlermeldungen auszuspucken?

Ich weiss jetzt nicht, wer hier zuerst mit dem /usr/bin/cd angerueckt ist, aber das ist kompletter Unfug. cd muss ein Shell-Builtin sein, als externes Programm waere es komplett sinnfrei.
 
Ich weiss jetzt nicht, wer hier zuerst mit dem /usr/bin/cd angerueckt ist, aber das ist kompletter Unfug. cd muss ein Shell-Builtin sein, als externes Programm waere es komplett sinnfrei.
Zum Vergrößern anklicken....
ich dachte, dass das in dem Beitrag von troll schon klar geworden ist.
Weiter vermute ich, dass beta113 das auch so meinte, weil er den Beitrag mit #/bin/sh einleitete. (was ich kopierte und damit leicht falsch übernommen hatte. Meine Augen sind nicht mehr so gut. #!/bin/sh sollte das eher sein, allerdings braucht es das ja nicht unbedingt)
Also, als Eintrag in eine crontab taugen diese Zeilen natürlich nicht.
Aus der crontab ruft man Programme oder Dienste oder eben Scripts auf und wenn ein einfacher, direkter Programmaufruf nicht funktioniert, wie in diesem Beispiel beschrieben und dazu weitere Schritte nötig sind, erstellt man dazu ein Script und ruft dann dieses aus der crontab auf. Das ist eine einzige Zeile, in meinem Beispiel weiter oben hatte ich so was gezeigt.

cd /usr/bin/cd /user/home/game/auth
taugt unter keinen Umständen für irgendwas, weder direkt als Kommando, noch in einem Script und selbst als Kommentar wäre es kein sinnvoller Beitrag.
/usr/bin/cd oder auch cd direkt wechseln in das nachstehend angegebene Verzeichnis, mehr nicht. Solch ein Wechsel führt nicht zu einem Programmaufruf. Es ist mir schleierhaft, wie mit solch einem Aufruf etwas funktionieren soll, weder als Script, das aus der crontab gestartet wird, aber erst recht nicht als direkter Eintrag in eine crontab.
Außerdem halte ich die Einträge in /var/cron/tabs für wesentlich einfacher zu handeln, als direkte Einträge in der /etc/crontab. (siehe: crontab(5), cron(8))
Wenn es also mit den zitierten Einträgen tatsächlich geklappt hat, fehlt noch ergänzende Information dazu.

crontab: ich trenne bei den Begriffen hier nicht scharf. Eigentlich gibt es nur eine crontab, die /etc/crontab. Wenn ich hier von crontab spreche, meine ich diese nicht ausschließlich, sondern jede von cron beachtete und ausgewertete Tabelle, insbesondere eben jene in /var/cron/tabs.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben