Per PHP angestoßenes Shell-Skript funktioniert nicht mehr - auf Shell jedoch schon!

Back2toxic

Erfahrenes Mitglied
Hey hey,

ich habe ein Shell-Skript, das per rsync Daten zwischen zwei Servern synchronisiert.
Stoße ich das Skript per Shell an funktioniert alles ohne Probleme.

Rufe ich das Skript jedoch per system() auf geht der Trouble los:
Es wird keine Log-Datei erstellt, rsync wird nicht ausgeführt und und und... Bis vor ca. 2 Wochen hat das ohne Probleme funktioniert. Der 1und1 Platin-Support sagt, dass nichts geändert wurde, dass dieses Fehlverhalten produzieren könnte. habe dort schon mit diversen Leuten gesprochen.

Schreibe ich im Shell-Skript per echo in eine Datei, wird diese per Shell und per system()-funktion generiert. Der Rest geht nimmer. CHMOD 777 auf beiden Dateien brachte auch keine Änderung (und wäre so oder so keine dauerhafte Lösung gewesen!!)

Hat hier vielleicht noch jemand nen Tipp?
Handelt sich um einen Managed Server von 1und1, habe also kein root.

Beste Grüße,
Chris
 
Hi,

schreib die Programmpfade absolut in das Script.
Soweit ich weiß hat das Script, wenn es per system() ausgeführt wird, nur /bin und /sbin im Path.

Bash:
# statt:
rsync a b

# dies hier:
/usr/bin/rsync a b

Ausserdem musst du auch aufpassen, was du synchronisierst und ob hierbei ein passwort abgefragt wird. Da das Programm nicht interaktiv ausgeführt wird, kann es sein dass der Vorgang abbricht wegen fehlender Berechtigung.

Grüße,
BK
 
Hey hey,

danke für deine Antwort! Das werde ich jetzt als erstes Probieren!

Weitere Info - evtl. hilft das weiter:

Das Shell-Skript sie momentan so aus - die Passwortabfrage wird dank expect abgefangen

Code:
#!/bin/bash
#--VARSTART--#

if [ "$1" != "XXXXX" ]; then
  exit 0
fi

SOURCEDOCUMENTROOT="XXXXXXXXXXXX"
TARGETDOCUMENTROOT="XXXXXXXXXXXX"
HOST="XXXXXXXXXXXX"
USER="XXXXXXXXXXXX"
PASS="XXXXXXXXXXXX"

#OPTIONS="-nrvvh"
OPTIONS="-arzugth --delete"
#OPTIONS="-arzugth"
PERMISSIONS="--no-p"
EXCLUDE="--exclude-from "$SOURCEDOCUMENTROOT"XXXXXXXXXXXX/default/filterRules/excludeFrom.txt"
INCLUDE="--include-from "$SOURCEDOCUMENTROOT"XXXXXXXXXXXX/default/filterRules/includeFrom.txt"

if [ "$2" != "" ]; then
  LOGTYPE=$2
else
  LOGTYPE="default"
fi

LOGFILE="--log-file="$SOURCEDOCUMENTROOT"XXXXXXXXXXXX/default/logs/log_"$LOGTYPE".txt"

# rsync $OPTIONS $PERMISSIONS $LOGFILE $INCLUDE $EXCLUDE -e \"ssh -l $USER\" $SOURCEDOCUMENTROOT $USER@$HOST:$TARGETDOCUMENTROOT
#--VAREND--#
#--CMDSTART--#
VAR=$(expect -c "
spawn rsync $OPTIONS $PERMISSIONS $LOGFILE $INCLUDE $EXCLUDE -e \"ssh -l $USER\" $SOURCEDOCUMENTROOT $USER@$HOST:$TARGETDOCUMENTROOT
set timeout -1
match_max 100000
expect \"*?assword:*\"
send -- \"$PASS\r\"
send -- \"\r\"
expect eof
")

#echo rsync $OPTIONS $PERMISSIONS $LOGFILE $INCLUDE $EXCLUDE -e ssh -l $USER $SOURCEDOCUMENTROOT $USER@$HOST:$TARGETDOCUMENTROOT > ~/output.txt
 echo "$VAR"
#--CMDEND--#

Edit: auch /usr/bin/rsync brachte keine Änderung. rsync liegt auch genau dort, hab's geprüft.
Edit2: /usr/bin/expect ändert auch nichts :(

Beste Grüße,
Chris
 
Zuletzt bearbeitet:
Darf leider kein sudo - hab das jetzt mal nur mit su gemacht.
Ist das so richtig?
Code:
su -l -s /bin/bash www-data
(Enter)
XXXXXXXXXXXXXXX/bin/sync.sh XXXXXX 1340285067

Edit: "Darf leider kein sudo" sollte eigentlich "-bash: /bin/bash/sudo: Not a directory" heißen..

Edit2: Ein weiteres Telefonat mit einem (endlich fähigen) 1und1 Supporter hat ergeben, dass das Skript ohne Probleme läuft, aber wohl die Benutzerberechtigungen mit dem Update von Apache 1.2 auf 2.2 vom 11.06.2012 geändert wurden.
Führe ich das Skript in der Shell via php5 aus läuft es nämlich auch ohne Probs durch.

Beste Grüße,
Chris
 
Zuletzt bearbeitet:
So, nun doch ein Doppelpost...

Ich habe neue Erkenntnisse:
Führe ich das Skript per PHP aus wirft es mir einen Fehler 134, welcher für folgendes steht:
Code:
Exit code 134: The job is killed with an abort signal, and you probably got core dumped. Often this is caused either by an assert() or an ErrMsg(fatal) being hit in your job. There may be a run-time bug in your code. Use a debugger like gdb or dbx to find out what's wrong.

In der Shell läuft es jedoch noch immer ohne Probleme.
Ich habe die Pfade im SH-Skript mittlerweile relativ angegeben, absolut ändert allerdings nada.

Edit: weitere Meldung vom STDERR:
Code:
Tcl_InitNotifier: unable to start notifier thread

Ich glaube das geht langsam sehr in Richtung *nix.
Kann das mal ein Mod verschieben? :)

Grüße,
Chris
 
Zuletzt bearbeitet:
Die Fehlermeldung die du da angibst, kommt vom Tcl Interpreter, ich vermute mal, das expect da Probleme macht.
Versuch es doch mal mit einer Passwortlosen Authentifizierung (ssh key) funktioniert bei mir einwandfrei. Ansonsten aus man rsync:
Some modules on the remote daemon may require authentication. If so, you will receive a password prompt when you connect. You can avoid the password prompt by setting the environment variable RSYNC_PASSWORD to the password you want to use or using the --password-file option. This may be useful when scripting rsync.
WARNING: On some systems environment variables are visible to all users. On those systems using --password-file is recommended.


Dein Skript vereinfacht sich dann gewaltig, du brauchst nur noch die Variablen und den Aufruf
Code:
rsync $OPTIONS $PERMISSIONS $LOGFILE $INCLUDE $EXCLUDE -e \"ssh -l $USER\" $SOURCEDOCUMENTROOT $USER@$HOST:$TARGETDOCUMENTROOT
 
Hey hey, genau das habe ich eben gemacht.
Beim damaligen Einrichten hat es mit dem passwortlosen rsync nicht funktioniert (Hat der Mensch gesagt, der es damals eingerichtet hat...).
Hat nun aber doch funktioniert und ich verzichte jetzt komplett auf .sh-Files.
Wird direkt aus PHP per System() aufgerufen und wuppt wunderbar.

Vielen Dank für deine Antwort, das war die Lösung!
 
Zurück