Cronjob anlegen

  • Cronjobs musst du über das WCP anlegen.


    Oben links auf Websited & Domains und anschließend oben rechts auf Scheduled Tasks


    Ansonsten wären eine etwas genauere Fehlerbeschreibung oder Screenshots hilfreich. "allerdings bekomme ich es leider nicht hin" ist nämlich ziemlich nichts sagend.

    VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Fehler 1 sagt ja erstmal nicht so viel aus, nur dass ein Fehler aufgetreten ist.


    Plesk ist normalerweise bei den Cronjobs recht gesprächig, wenn stdout und stderr nicht auf /dev/null umgeleitet werden.


    Was passiert, bzw. welche zusätzlichen Ausgaben kommen wenn der Befehl ohne >/dev/null 2>&1 aufgerufen wird?


    Bzw. steht wget überhaupt zur Verfügung?

  • Das hab ich vin netcup bekommen werde aber daraus nicht schlau was und wie ich das machen soll.:



    vielen Dank für Ihre Anfrage.


    Das Problem liegt dann vermutlich an fehlerhaften Syntax. Beachten Sie, dass sich Optionen je nach verfügbarer "wget" und "bash" Version unterscheiden.


    Ich empfehle, sich per ssh in Ihr Webhosting einzuloggen und die möglichen Optionen per "wget --help" durchgehen.

  • Das Problem liegt dann vermutlich an fehlerhaften Syntax. Beachten Sie, dass sich Optionen je nach verfügbarer "wget" und "bash" Version unterscheiden.

    Das würde mich wundern. -q und -o sind ja wohl Standard.

    Ich habe mich eben mal per ssh in die Konsole meines Webhosting 8000 eingeloggt und

    wget -q -o - https://Beispiel

    läd die Seite ohne Fehlermeldung korrekt herunter.

    Ich empfehle, sich per ssh in Ihr Webhosting einzuloggen...

    https://www.netcup-wiki.de/wiki/Websites#SSH-Verbindung


    EDIT:

    Hattes du irgendwann (nach Anlegen der anderen cronjobs und vor diesem) die Standarddomain (Die mit der langen Zahlenfolge) des Hostings deaktiviert?

  • Code
    1. hosting1xxxxx@a2xxx:/$ type wget; which wget
    2. wget is aliased to `wget -cnv --show-progress'
    3. /usr/bin/wget

    Ich sehe, wo das Problem liegt, das ich immer gerne vergesse… 8o (Auf eine gescheite Shell kommt es an.)

    Shell-Script
    1. [2021-07-27T14:57:57+0200] root@desktop01:/opt# alias eumel="/bin/nano --hidden-emacs-mode"
    2. [2021-07-27T14:58:00+0200] root@desktop01:/opt# type eumel
    3. eumel is an alias for /bin/nano --hidden-emacs-mode
    4. [2021-07-27T14:58:02+0200] root@desktop01:/opt# echo $SHELL
    5. /usr/bin/zsh
    6. [2021-07-27T15:04:35+0200] root@desktop01:/opt# which eumel
    7. eumel: aliased to nano --hidden-emacs-mode
    8. [2021-07-27T15:04:37+0200] root@desktop01:/opt#

    which unterschlägt in diesem Fall sogar den Pfad des Alias'. Aber so oder so: Solange man keinen absoluten Pfad sieht, muss man der Definition folgen.

  • das kommt noch dazu. auf webhostings gibts ja erstmal nur /bin/bash.


    Code
    1. lucy% type wget; which wget; where wget
    2. wget is an alias for wget -cnv --show-progress
    3. wget: aliased to wget -cnv --show-progress
    4. wget: aliased to wget -cnv --show-progress
    5. /usr/local/bin/wget
    6. /usr/local/bin/wget

    für zsh dann where wget.


    und zu guter letzt, für beide shells gültig :S: type -a wget

  • Also auf dem Screenshot sehe ich "-O" anstatt "-o".

    Die Frage ist, was soll nach stdout umgeleitet werden, die heruntergeladene Datei oder der Log? Und warum macht man das, wenn man später stdout eh nach /dev/null umleitet? Und zumal das Log standardmäßig auf stederr kommt, was auch umgeleitet wird?


    Mir erschließt sich der Sinn dieses Cron Jobs noch nicht wirklich, aber seis drum.


    Je nach Scriptsprache kann auch das "&" im Aufruf ein Problem sein. Vielleicht besser beide pipes dediziert nach /dev/null leiten.

  • Kann man sich wahrscheinlich eh alles schenken im Webhosting. Ich habe es jedenfalls in Fall eines PHP-Scripts, das Ausgaben per 'echo' gemacht hat und die ich in einer Datei sammeln wollte, nicht geschafft im netcup Webhosting Cron diese Ausgaben in einer Datei zu sammeln. Die war grundsätzlich immer leer bzw nicht vorhanden nach Ablauf des Skripts im Cronjob. Sowohl bei Aufruf als PHP-Skript als auch beim Aufruf als Kommando mit z.B. '/usr/local/php74/bin/php meinskript.php'. Beim Aufruf des selben Kommandos in der Shell kamen die Ausgaben, im Cronjob nichts, niente, nada. Ich habe da mal einen Abend lang gegoogelt und alles mögliche aus dem Netz probiert - und die Ausgaben dann letztendlich mit fprintf in die gewünschte Datei geschrieben, weil rein gar nichts funktioniert hat.:rolleyes: Bei anderen Webhostern größtenteils kein Problem ... Naja, vielleicht ist es mittlerweile nach dem Upgrade auf Plesk Obsidian anders, aber um das Skript nochmal umzuschreiben ist mir jetzt eh die Zeit zu schade.