crontab skript ausführen - unison im skript funzt nicht

Hi,
kann mit mal jemand auf die Sprünge helfen?
Skriptproblem mit UNISON sync.
Auf einer Seite ist eine TS-659 Pro II, Version 3.5.0 build 0815T
Auf der anderen Seite ist eine TS-459 Version 3.5.0 build 0815T

Ich hab ein crontab -e mit einem Skript am laufen - leider nur zu 80% funktionierend. (ipkg install cron)
Die wichtigen 20% mit unison gehen nicht ... (unison 2.40.63)
Das Skript funktioniert, wenn ich es per Hand auf der Shell starte. Der Sync, Mailverschicken, LOG erstellen, etc. ...

Als cronjob geht alles bis auf den sync mit unison. LOG-erstellen geht, cat geht, mailverschicken (python skript) geht.

PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/share/MD0_DATA/.qpkg/Optware/bin:/opt/sbin
start=$(/bin/date +"%m%d%Y_%k%M%S")
/bin/echo $start
logfileout="/share/MD0_DATA/BACKUP/log/$start.txt"
/bin/echo "LOG-File: "$logfileout
/bin/echo "PFAD-Variable PATH: "$PATH >> $logfileout
# verschieben der LOG-Files des Windowsservers in das Verzeichnis auf dem NAS
/bin/mv /share/MD0_DATA/FFM/tmp/*.txt /share/MD0_DATA/BACKUP/log/
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo "STARTZEIT: " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo "SYNC ##### Aktuelle_JOBS #####  FFM<---->Berlin" >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
cd /share/MD0_DATA/.qpkg/Optware/bin/
./unison /share/MD0_DATA/FFM/daten/Aktuelle_Jobs -ignore "Name .DS_Store" -ignore "Name TheVolumeSettingsFolder" -auto -batch -logfile /share/MD0_DATA/BACKUP/log/aktuelle_jobs.txt ssh://admin@80.140.33.108//share/MD0_DATA/BERLIN/daten/Aktuelle_Jobs -prefer /share/MD0_DATA/FFM/daten/Aktuelle_Jobs
cd /share/MD0_DATA/BACKUP/log/
/bin/cat *.txt >> /share/MD0_DATA/BACKUP/log/log_$start
cd /share/MD0_DATA/BACKUP/
./mailraus_ffm.py /share/MD0_DATA/BACKUP/log/log_$start >> /share/MD0_DATA/BACKUP/log/log_$start
./mailraus_kb.py /share/MD0_DATA/BACKUP/log/log_$start >> /share/MD0_DATA/BACKUP/log/log_$start
cd /share/MD0_DATA/BACKUP/log/
mv *.txt /share/MD0_DATA/BACKUP/tmp/

Hi frosch2,

absolutere Pfade direkt zum Behfehl geht doch kaum noch ...

Also wie du im Skript sehen kannst, gehe ich direkt in das ../bin Verzeichnis.
Dort mache ich dann ein ./unison

Ich hab das mal ein bischen eingedampft.
Fehlermeldung gibt es gar keine:

#!/bin/ash
PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/share/MD0_DATA/.qpkg/Optware/bin:/opt/sbin
start=$(/bin/date +"%m%d%Y_%k%M%S")
/bin/echo $start
logfileout="/share/MD0_DATA/BACKUP/log/$start.txt"
/bin/echo "LOG-File: "$logfileout
/bin/echo "PFAD-Variable PATH: "$PATH >> $logfileout
# verschieben der LOG-Files des Windowsservers in das Verzeichnis auf dem NAS
/bin/mv /share/MD0_DATA/FFM/tmp/*.txt /share/MD0_DATA/BACKUP/log/
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo "STARTZEIT: " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo "SYNC ##### Aktuelle_JOBS #####  FFM<---->Berlin" >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " " >> /share/MD0_DATA/BACKUP/log/log_$start
cd /share/MD0_DATA/.qpkg/Optware/bin/
/bin/ls -la >> /share/MD0_DATA/BACKUP/log/log_$start
./unison /share/MD0_DATA/FFM/daten/bs -ignore "Name .DS_Store" -ignore "Name TheVolumeSettingsFolder" -auto -batch -logfile /share/MD0_DATA/BACKUP/log/bs.txt ssh://admin@80.145.35.105//share/MD0_DATA/BERLIN/bs -prefer /share/MD0_DATA/FFM/daten/Aktuelle_Jobs >> /share/MD0_DATA/BACKUP/log/log_$start
/bin/echo " aktuelle JOBS Fertig!! " >> /share/MD0_DATA/BACKUP/log/log_$start
exit

Also ich hab den ganzen kram in die Ausgabe ... log_$start gemacht.
Da sehe ich, daß er in den Pfad ../Optware/bin/ gewechselt ist und unison sehe ich auch.
Dann ein ./unison im skript --> keine Ausgabe und auch kein Fehler.

Hier das LOG:

STARTZEIT:
SYNC ##### Aktuelle_JOBS ##### FFM<---->Berlin
drwxr-xr-x 2 admin administ 4096 Sep 13 20:35 .
drwxr-xr-x 16 admin administ 4096 Sep 13 20:35 ..
-rwxr-xr-x 1 admin administ 474024 Dec 4 2010 addr2line
-rwxr-xr-x 2 admin administ 445892 Dec 4 2010 ar
-rwxr-xr-x 2 admin administ 663108 Dec 4 2010 as
-rwxr-xr-x 1 admin administ 428896 Dec 4 2010 binutils-strings
...
-rwxr-xr-x 1 admin administ 8588 Jun 7 2010 toe
-rwxr-xr-x 1 admin administ 9124 Jun 7 2010 tput
-rwxr-xr-x 1 admin administ 14312 Jun 7 2010 tset
-rwxr-xr-x 1 admin administ 3468914 Sep 4 22:07 unison
-rwxr-xr-x 1 admin administ 4248 May 18 2010 update-alternatives
aktuelle JOBS Fertig!!

#!/bin/ash

--> Überreste des alten Skriptes einer anderen Maschine (ash --> ksh, zsh, bash, sh) anderes Shellderivat.

Die Idee das gebammel wegzumachen,
--> gar nicht blöd. Ergebnisse gibts gleich. :thumb:

Hallo Frosch2,
War ein super Tip.
Also so ohne gebambel funktioniert unison. Ich bekomme eine Ausgabe mit Version.
Das ist doch schon mal was.

Wenn ich mir den Rattenschwanz anschaue, wird es wohl an der Umsetzung zu ssh hängen.

crontab auf dem QNAP macht einen Unterschied ob ich es auf der shell ausführe oder nicht.
Das ist schon ok, so von wegen den absoltuen Pfaden zu den Binaries. Aber daß der dann noch obskure Pfade zum Home-Laufwerk hat, wie die vom Synology NAS --> Das ist dann doch schon ein BUG.

Fatal error: exception Util.Fatal("Error in getLogch:
/share/homes/admin/unison.log: No such file or directory")
Fatal error: Error in creating unison directory /share/homes/admin/.unison:
No such file or directory [mkdir(/share/homes/admin/.unison)]
Fatal error: exception Util.Fatal("Error in getLogch:
/share/homes/admin/unison.log: No such file or directory")
Fatal error: Error in creating unison directory /share/homes/admin/.unison:
No such file or directory [mkdir(/share/homes/admin/.unison)]
Fatal error: exception Util.Fatal("Error in getLogch:

EDIT:
So in my mind the user shall be ok. On the QNAP side (embedded Linux with busybox) will be a bug with admin/root-rape.
If somebody need the hint - this did the trick:
mkdir -p /share/homes/admin/
cd /share/homes/admin
ln -s /share/MD0_DATA/BACKUP/.unison .unison