(Pseudo-)Cron Problem bei system call

Gesperrt
junior0007
Beiträge: 20
Registriert: So 16. Jan 2005, 17:25
Kontaktdaten:

(Pseudo-)Cron Problem bei system call

Beitrag von junior0007 » Mo 19. Jun 2006, 16:31

Hi,

hab gerade etwas mit den pseudo-crons gespielt, und hab eine kleine Ungereimtheit, die ich mir einfach nicht erklären kann...
Hab ein DB-dump-Script das über einen System-Call eine DB-Sicherung erzeugt. Dieses script geht, solange ich es manuell aufrufe.

Wenn ich nun eben jenes Script über einen (Pseudo)-Conjob laufen lasse, dann bekomme ich zwar die selbe Bestätigung (via email) zugeschickt wie bei manueller Ausführung, allerdings finde ich kein dump-file im erwarteten Verzeichnis (definiert über $path = dirname(__FILE__); im dbexport script). Dabei sollte ich erwähnen, daß die job-datei NICHT im cronjob Verezeichnis von contenido liegt (muss sie da etwa hin???).

Der Vergleich der Rückgabewerte zwischen manuellem und automatischen Aufruf ist einmal '' (gar nix) und einmal '0'... Was beides auf false ausgewertet werde müsste und deshalb doch eigentlich aussagt, dass alles geklappt hat..., oder?

Meine Contenido-Version ist 3.5.3. Anbieter ist all-inkl.

Kann mir jemand sagen warum keine dumps erzeugt werden? Oder besser noch was ich ändern muss damit alles funktioniert :)

Danke euch..

Gruß Junior0007

emergence
Beiträge: 10645
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Mo 19. Jun 2006, 19:42

das ist zu wenig info...
ist für die helferlein wie die suche nach der nadel im heuhaufen...

lass dir doch in dem mail das du erhälst die aktuellen pfade mit ausgeben...
dann hast du einen ansatzpunkt wo es haken könnte...
*** make your own tools (wishlist :: thx)

junior0007
Beiträge: 20
Registriert: So 16. Jan 2005, 17:25
Kontaktdaten:

RE:

Beitrag von junior0007 » Di 20. Jun 2006, 08:38

Hi,
sorry - hier alles was ich weiß.

Das mit dem Pfad hab ich bereits gemacht - in beiden Mails steht das selbe
(0) DB exportiert nach
/www/htdocs/xxxxxxxx/DBdump_2006_06_20_0920.sql.gz
() DB exportiert nach
/www/htdocs/xxxxxxxx/DBdump_2006_06_20_0918.sql.gz
nur einmal mit der 0 in den Klammern (wenns klappt) und einmal ohne. Eigenartig ist höchstens, dass die Mails von verschiedenen Absendern kommen (einmal von wwwrun@mydomain.de und einmal von benutzername@xxxx.kasserver.com).

das ist der code:

Code: Alles auswählen

system("/usr/bin/mysqldump -u$myuser -p$mypass -h$myhost $mydb | gzip > $path/DBdump_$thedate.sql.gz", $fp);

  if ($fp==0)
  {
    mail( "email@myadress",
          "dbexport",
          "($fp) DB exportiert nach \n
          $path/DBdump_$thedate.sql.gz");
  }
  else
  {
    mail("email@myadress", "dbexport", "DB NICHT exportiert!!!");
  }
Würde ja an einen falschen Aufruf denken, aber nachdems bei manuellem Ausführen des Scripts funktioniert kann es daran eigentlich ja nicht liegen. Läuft ein PseudoCron in einer anderen Umgebung (ähnlich einer Sandbox), die vlt. keine Schreibrechte hat? Gibts evtl ne Möglichkeit mehr Infos von einem System-Call zu bekommen?

Gruß
Junior0007

xmurrix
Beiträge: 3154
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Beitrag von xmurrix » Di 20. Jun 2006, 12:42

Hallo Junior0007,

vielleicht liegt es daran, dass der Geltungsbereich einiger Variablen außerhalb des Scriptes liegt, wenn das Script in der funktion "runJob" des pseudo-cron includiert wird.
Variablen, die außerhalb des Scriptes definiert/deklariert sind, sollten mit "global" in den Geltungsbereich übernommen werden.

Gruß
xmurrix

junior0007
Beiträge: 20
Registriert: So 16. Jan 2005, 17:25
Kontaktdaten:

RE:

Beitrag von junior0007 » Di 20. Jun 2006, 14:36

Hallo xmurrix,

bin mir nicht sicher, ob ich das richtig verstanden habe, aber die einzigsten Variablen, die ich von "aussen" übernehme sind PHP spezifisch:
$path = dirname(__FILE__);
und sollten deshalb deshalb auch innerhalb eines scriptes laufen. Zumal die email ja auch sagt, daß der Pfad richtig ist. Die anderen Variablen werden (zugegebener massen nicht sehr elegant) direkt definiert.
$thedate=date("Y_m_d_Hi", time());
$myhost= 'xxx';
$myuser= 'xxxx';
$mypass= 'xxxxx';
$mydb = 'xx';
das sollte also nicht der Grund sein, oder?

Gruß
Junior0007

xmurrix
Beiträge: 3154
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Beitrag von xmurrix » Di 20. Jun 2006, 16:07

Ok, dann liegts es nicht daran, war ne Möglichkeit, die mir eingefallen ist.
Woran es letzendlich scheitert, kann ich dir nicht sagen.

Die Rückgabe der Funktion system ist "false", wenn der Aufruf nicht geklappt hat. Probier mal Folgendes:

Code: Alles auswählen

if ($fp != false) {
    // ok mail
} else {
    // nicht ok mail
}
Gruß
xmurrix

junior0007
Beiträge: 20
Registriert: So 16. Jan 2005, 17:25
Kontaktdaten:

RE:

Beitrag von junior0007 » Di 20. Jun 2006, 17:36

Hi,

danke die Idee war gut - aber leider klappt das so nicht. Beim manuellen ausführen des scripts bekomm ich jetzt eine false-mail obwohl ein dump angelegt worden ist. und die Cronausführung ist immernoch gleich...

junior0007
Beiträge: 20
Registriert: So 16. Jan 2005, 17:25
Kontaktdaten:

Lösung

Beitrag von junior0007 » Di 20. Jun 2006, 19:14

Hallo nochmal.

Denke die Lösung ist ganz einfach :(

All Inkl erlaubt keine Systemcall aus php dateien heraus. Diese sind nur aus .phpx dateien erlaubt. Leider ist die Pseudocron-Datei (~pseudo-cron.inc.php) eben keine .phpx datei und damit auch nicht ausführbar.

Diese Lösung ist zwar nicht hundertprozentig gesichert erklärt aber auf alle Fälle den fehlenden Rückgabewert ("()") und das nichtausführen...

In diesem Sinne danke für die Hilfe...

Gesperrt