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.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | 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?

  • Laut Support steht wget zur Verfügung.

    Ich würde dennoch in diesem Fall (Syntax inklusive Ausgabeumleitung erscheint zunächst einmal gültig) sicherheitshalber eine vollständige Pfadangabe für wget eintragen.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Was meinst du mit vollständiger Pfadabgabe? Und wie mach ich das genau?

    Auf der Kommandozeile eruieren, wo genau wget liegt (etwa mittels Eingabe von type wget) und diesen vollständigen Pfad (bspw. /usr/bin/wget) in obiges Feld eintragen.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • 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?

  • ftwai: type wget liefert kein brauchbares ergebnis, wenn wget schon ge'alias't wurde.

    besser wäre hier which wget

    Hm… :)

    type_which_alias.png

    (Da hilft im Zweifelsfall wohl nur nachzufassen und "der Alias-Definition zu folgen", um in der crontab ein erwartetes Verhalten zu erzielen…)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • brauchst ja meist nicht, wenn du das mit aliassen auf vorhandene bins testest und nicht mit eumels :P:


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

    »Hauptsache BogoMIPS!«

    Fleischfresser

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

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

    Bash
    [2021-07-27T14:57:57+0200] root@desktop01:/opt# alias eumel="/bin/nano --hidden-emacs-mode"
    [2021-07-27T14:58:00+0200] root@desktop01:/opt# type eumel
    eumel is an alias for /bin/nano --hidden-emacs-mode
    [2021-07-27T14:58:02+0200] root@desktop01:/opt# echo $SHELL
    /usr/bin/zsh
    [2021-07-27T15:04:35+0200] root@desktop01:/opt# which eumel
    eumel: aliased to nano --hidden-emacs-mode
    [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.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

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


    Code
    lucy% type wget; which wget; where wget
    wget is an alias for wget -cnv --show-progress
    wget: aliased to wget -cnv --show-progress
    wget: aliased to wget -cnv --show-progress
    /usr/local/bin/wget
    /usr/local/bin/wget

    für zsh dann where wget.


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

    »Hauptsache BogoMIPS!«

    Fleischfresser

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