[ruby] rvmsudo-Problem

  • Hallo,


    habe ein Problem mit Ruby. Folgendes: ich kann ein Script manuell problemlos ausführen, sobald ich es aber mit einem Crontab / Cronjob versuche, der bei jedem Booten (@reboot) ausgeführt wird, versuche, schlägt dies Fehl und ich bekomme folgende Ausgabe:

    Zitat

    ./SiriProxy_Upstart.sh: 2: rvmsudo: not found


    Das Script (die Schleife ist derzeit "deaktiviert" bzw. auskommentiert, weil die log-Datei (siehe cron) sonst zugeflutet wird, mit den Fehlermeldungen):

    Code
    # while true; do
    rvmsudo siriproxy server
    # done


    Und so sieht der cron aus:

    Zitat

    @reboot cd /root/SiriProxy; ./SiriProxy_Upstart.sh > /root/SiriProxy/siriproxy.log 2>&1


    Hoffe, es ist ein Ruby-"Experte" hier, der mir helfen kann. Wie gesagt, wenn ich es manuell via PuTTy ausführe, funktioniert es Problemlos - bis ich die Konsole schließe.


    Danke, schonmal!

  • Verwende den absoluten Pfad zum Programm oder setze den korrekten PATH im Crontab ;)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Hi Christian,


    danke, darauf bin ich auch schon gekommen, funktioniert aber auch nicht:


    Script:

    Bash
    #!/bin/bash
    # while true; do
    /usr/local/rvm/bin/rvmsudo siriproxy server
    # done


    Fehler:

    Zitat

    /usr/bin/env: siriproxy: No such file or directory


    Was will er eigentlich in /usr/bin/env ?!


    Cron:

    Zitat

    @reboot cd /root/SiriProxy; ./SiriProxy_Upstart.sh > /root/SiriProxy/siriproxy.log 2>&1


    Bin noch am verzweifeln... ;(

  • Aktuell läuft ein Debaien Squeeze-Image. Was bei Debian funktioniert, sind die Crontabs, diese wurden beim Ubuntu-Image garnicht erst ausgeführt.


    Aber der Fehler tritt trotzdem auf.. Es kann doch nicht sein, dass es hier keine Lösung gibt... ;(

  • rvmsudo sollte nicht einfach so benutzt werden, da zuvor die Umgebungsvariablen ordentlich gesetzt werden müssen (source /usr/local/rvm/scripts/rvm).


    Einfacher ist es, das Skript in der Crontab des root-Users aufzurufen (oder besser noch: das Skript so schreiben, dass es ¬root-User benutzen können).