[Gelöst] Cronjob liefert Fehler: "bad interpreter: No such"

[netmax]

Hallo nochmal,

nachdem meine Servermigration dank tatkräftiger Hilfe hier generell jetzt läuft, habe ich noch ein Problem mit den Cronjobs. Diese sind genauso angelegt wie bei dem alten Server, allerdings liefern sie mir auf dem neuen Server alle eine Fehlermeldung.

Ein Beispiel: Das PostMasterMailbox-Script. Ist folgende der Vorgabe so im Cron:

Code: Select all

$HOME/desk/opt/otrs/bin/otrs.PostMasterMailbox.pl >> /dev/null

Leider liefert es hier nur Fehlermeldungen:

-: //desk/opt/otrs/bin/otrs.PostMasterMailbox.pl: /usr/bin/perl: bad interpreter: No such file or directory

Exakt das gleiche Script unter dem gleichen User auf der Shell ausgeführt läuft einwandfrei. Am Perl-Pfad liegt es also generell nicht - nur warum meckert Cron hier scheinbar den "interpreter"-Pfad an?

[netmax]

Aktuell noch eine weitere Info: Es scheint ein Rechteproblem zu sein. Lege ich die Cronjobs als root an, laufen diese ohne Probleme. Mir erschließt sich nur nicht ganz, warum - die Berechtigungen sind auf beiden Rechnern im Grunde gleich.

Per SetPermissions liegen die chowns der .pl-Dateien wie folgt:
Alter Server: fbl:www-data (Debian-Installation)
Neuer Server: fbl:apache (CentOS)

chmod ist 775.

Der OTRS-User ist "fbl", die Cronjobs werden auch als "fbl" ausgeführt. Als "fbl" komme ich im Grunde genommen ja auch an die PostMasterMailbox.pl ran - diese kann ja geöffnet und ausgeführt werden. Dann kommt als Benutzer "fbl" allerdings die Fehlermeldung bezüglich des Interpreters - also scheint hier eher perl ein Problem damit zu haben, von dem User ausgeführt zu werden, und das Problem liegt nicht an der eigentlichen .pl-Datei selbst.

Auf dem alten Server lief es wie gesagt bei gleicher Konfiguration (nur unter Debian statt CentOS) problemlos.

Hat jemand einen Tipp? Ich lasse lieber die zugehörigen Crons unter den entsprechenden Usern laufen, anstatt root vollzupacken ...

[netmax]

Ich habe das Problem gefunden:

Ab Plesk 10 laufen die Cronjobs der Benutzer mit eingeschränkten Rechten - diese gestatten keinen Zugriff auf Perl oder andere Systemkomponenten. Der alte Server wurde seinerzeit mit Plesk 7 aufgesetzt und hochmigriert - dabei wurden die Einschränkungen natürlich für die alten User nicht gesetzt.

Abhilfe, falls jemand das gleiche Problem unter Plesk hat: Der entsprechende Benutzer muss SSH-Rechte bekommen: Controlpanel der Domain -> Websites und Domains -> Webhosting-Zugriff -> Dort den Zugang via SSH auf "/bin/sh" setzen.