Jump to content
Froxlor Forum
  • 0

0.9.33.1 - Cronjob wird nicht abgearbeitet


Stephan

Question

Hallo, ich habe vor ein paar Tagen auf die neueste Version geupdatet und alles wie beschrieben eingestellt.

Allerdings arbeitet es meine Cronjobs nicht mehr ab. Bei Cronjob-Einstellungen zeigt es mir noch jeweils das Datum von Dezember bzw "01.01.1970 00:00" an. Es passiert auch nichts, wenn ich den Cron in der Kommandozeile von Hand ausf?hre mit  /usr/bin/nice -n 5 /usr/bin/php5 -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --force 

 

Unter /var/log habe ich nach Datum sortiert, finde aber keine Error-Log oder ?hnliches was zur Uhrzeit usw passt.

Es passiert einfach nichts.

Ich bin gerade etwas ratlos. Mein System ist: Linux RNMV001 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64

 

K?nnt ihr mir bitte weiterhelfen?

Link to comment
Share on other sites

Recommended Posts

Sehr dubios...naja, schreib doch mal direkt via mysql-shell oder phpmyadmin in die "panel_tasks" einen neuen Eintrag mit type=99 (data leerlassen). Dann nochma den cronjob mit --force laufen lassen. danach wurde zumindest beim anderen hier im thread die datei erstellt

Link to comment
Share on other sites

Danke, jetzt gehts wieder. Ich schreib das mal in meine eigene kleine Doku :)

 

Lediglich neu angelegte Domains/Subdomains sind leiten nicht auf das Verzeichnis der Domain, sondern bei Subdomains auf die Hauptdomain und bei Domains auf das froxlor-Login. Ich mein, das ging ja die ganze Zeit auch immer. Also, dass die Domain/Subdomain normal erreichbar sind nach der Erstellung.

Link to comment
Share on other sites

Ich habe in froxlor zu einer Domain eine Subdomain angelegt. Diese wird als Verzeichnis vom Cronjob auf dem Server erstellt. M?chte nun auf diese Subdomain drauf zugreifen (aufrufen im Browser), dann gelangt man direkt auf der Hauptdomain der Subdomain.

 

Aufruf: test.meinedomain.de -> ich gelange zum Inhalt von meinedomain.de

Link to comment
Share on other sites

Also irgendetwas stimmt intern nicht so ganz. Wenn ich bei einer vorhandenen Subdomain den Pfad ?ndere, dann wird nach der Ausf?hrung der Cronjobs nicht auf dieses Verzeichnis geleitet.

Also liegt es an apache oder bind, denke ich mal.

Link to comment
Share on other sites

Ok

 

Die Hauptdomain

# 22_froxlor_normal_vhost_$DOMAIN1.de.conf
# Created 03.03.2015 13:45
# Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel.

# Domain ID: 29 - CustomerID: 1 - CustomerLogin: $USERNAME
<VirtualHost $IPAdresse:80>
  ServerName $DOMAIN1.de
  ServerAlias *.$DOMAIN1.de
  ServerAdmin $MAILADRESSE
  DocumentRoot "/var/customers/webs/$USERNAME/$DOMAIN1.de/"
  FcgidIdleTimeout 30
  SuexecUserGroup "$USERNAME" "$USERNAME"
  <Directory "/var/customers/webs/$USERNAME/$DOMAIN1.de/">
    <FilesMatch "\.(php)$">
      SetHandler fcgid-script
      FcgidWrapper /var/www/php-fcgi-scripts/$USERNAME/$DOMAIN1.de/php-fcgi-starter .php
      Options +ExecCGI
    </FilesMatch>
    Order allow,deny
    allow from all
  </Directory>
  Alias /webalizer "/var/customers/webs/$USERNAME/webalizer"
  ErrorLog "/var/customers/logs/$USERNAME-error.log"
  CustomLog "/var/customers/logs/$USERNAME-access.log" combined
</VirtualHost>

Die Subdomain

# 20_froxlor_normal_vhost_lecker.$DOMAIN1.de.conf
# Created 03.03.2015 13:45
# Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel.

# Domain ID: 61 - CustomerID: 1 - CustomerLogin: $USERNAME
<VirtualHost $IPAdresse:80>
  ServerName lecker.$DOMAIN1.de
  ServerAlias *.lecker.$DOMAIN1.de
  ServerAdmin $MAILADRESSE
  DocumentRoot "/var/customers/webs/$USERNAME/lecker.$DOMAIN1.de/"
  FcgidIdleTimeout 30
  SuexecUserGroup "$USERNAME" "$USERNAME"
  <Directory "/var/customers/webs/$USERNAME/lecker.$DOMAIN1.de/">
    <FilesMatch "\.(php)$">
      SetHandler fcgid-script
      FcgidWrapper /var/www/php-fcgi-scripts/$USERNAME/lecker.$DOMAIN1.de/php-fcgi-starter .php
      Options +ExecCGI
    </FilesMatch>
    Order allow,deny
    allow from all
  </Directory>
  Alias /webalizer "/var/customers/webs/$USERNAME/webalizer"
  ErrorLog "/var/customers/logs/$USERNAME-error.log"
  CustomLog "/var/customers/logs/$USERNAME-access.log" combined
</VirtualHost>

Kann man darauf etwas schlie?en. Alternative k?nnen wir auch mal skypen :)

Link to comment
Share on other sites

Moinsens :)

 

tl;dr

 

Der Bug: der task 99 wird inserted; cron_tasks l?scht am Ende amer immer alle restlichen tasks raus. Demnach kann task 99 NIE automatisch wieder ausgef?hrt werden. Warum funzt das einmalig? in der froxlor.sql is der task 99 alleinstehend drin, cron_tasks wird dadurch beim 1. Run nicht ausgef?hrt -> cron.d/froxlor wird erstellt.

 

Ausf?hrlich:

 

Ich hatte heute selbiges Problem, hab leider die cron.d/froxlor gel?scht und sie wurde via --force auch nicht wieder angelegt.

 

Hab jetzt ne halbe Stunde debugged und hab mich etwas ins Cronjob-System eingelesen.

 

Der Cronjob startet, die cron_init.php wird ja als erstes ausgerufen. In dieser steht ganz unten der Funktionsaufruf zum pr?fen der cron.d (checkCrondConfigurationFile). Diese Funktion sucht nat?rlich dann einen Task 99, der in der Basis-SQL ja schon ab Werk drin ist - als einziger.

 

Der wird ja auch ausgef?hrt.

Alles toll.

 

So, jetzt ist die panel_tasks ja wieder leer.

 

 

 

Jetzt kommt jemand mit --force daher..

 

Selbiger Ablauf: cron_init startet, cron.d-Funktion sucht Task 99 => keiner da, ist ja klar, bis jetzt ist ja auch noch nicht viel passiert.

Erst danach kommt der Check auf --force, Task 99 wird (neben 1 und 4) inserted.

 

Nun kommt cron_tasks und f?hrt alles aus.

 

Am Ende werden jedoch alle restlichen Tasks gel?scht - auch Task 99. Somit wird Task 99 NIE ausgef?hrt, sobald cron_tasks.php auch mit l?uft.

 

 

Ich sehe hier 2 Probleme:

 

 

D.h.:

 

  • Den checkCrondConfigurationFile w?rde ich woanders aufrufen (oder Task 99 vorher inserten), damit, WENN Task 99 inserted wird (via --force) das auch noch im selben Run mitl?uft.
  • cron_tasks sollte nur die IDs l?schen, die von diesem Script auch verarbeitet werden ($resultIDs[] = $row['id']; z.B. in die if($row[type] Bl?cke verschieben)

 

Hoffe ich habe jetzt keinen krassen Denkfehler, aber ich glaub, das ist das Problem. Deswegen klappt auch der manuelle INSERT f?r Task 99 - da der dann allein drin steht und cron_tasks eben nicht mitl?uft.

 

Hoffe ich habs einigerma?en klar dargestellt :)

Link to comment
Share on other sites

Ja, so kann man das l?sen, so hatte ich es ine iner L?sungsvariante auch gedacht ;)

 

Aber dennoch wird die cron.d-Datei erst beim nachfolgenden Aufruf neu erstellt. St?rt jetzt nicht unbedingt, dachte nur, wenn man eh dran arbeitet.. ;)

Link to comment
Share on other sites

Ich klinke mich hier mal ein, denn ich scheine ein ?hnliches Problem zu haben. Auch mein Cron wird nicht ausgef?hrt, aber manuell mit --force funktioniert es.

 

Hier ist meine cron froxlor konfiguration:

# cat /etc/cron.d/froxlor
#
# Set PATH, otherwise restart-scripts won't find start-stop-daemon
#
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
#
# Regular cron jobs for the froxlor package
#
# Please check that all following paths are correct
#
*/5 * * * *     root    /usr/bin/nice -n 5 /usr/bin/php5 -q /var/www/froxlor/scripts/froxlor_master_cronjob.php

5TvIjb5.png

 

Gru?

David

Link to comment
Share on other sites

Hab ich mir gedacht, bei euch scheint die Datei durch den cronjob selbst nicht aktualisiert zu werden. Normalerweise liest der cronjob die cron-Einstellungen aus der Datenbank und erstellt aus diesen dann die cron.d/froxlor Datei.

 

Ein manueller cronjob mit --force regeneriert eigentlich auch diese Datei. Welche Berechtigungen hat die Datei denn? Wenn du den cronjob von froxlor deaktiviert, im Panel dann "Konfiguration neuerstellen" links im Men? klickst, hast du danach in der Tabelle panel_tasks einen Eintrag mit type=99?

Link to comment
Share on other sites

Hier die Berechtigungen:

root@srv003 /etc/cron.d # ls -la
total 24K
drwxr-xr-x  2 root root 4.0K Feb 28 14:20 .
drwxr-xr-x 85 root root 4.0K Feb 28 16:48 ..
-rw-r--r--  1 root root  344 Feb 28 13:50 froxlor
-rw-r--r--  1 root root  564 Feb 11 18:07 mdadm
-rw-r--r--  1 root root  510 Jan  9 09:20 php5
-rw-r--r--  1 root root  102 Jul  3  2012 .placeholder
root@srv003 /etc/cron.d #

Hier die Datenbankausgabe nachdem ich "Configs neu schreiben" ausgew?hlt habe:

 

yLPULzI.png

 

Und auch hier noch einmal die Anzeige im Froxlor:

 

3lVmJK1.png

 

PS: Sollte das cronscript dem Falschen Benutzer geh?ren, so fehlt ein entsprechender Hinweis in der Konfiguration dazu.

 

Gru?

David

Link to comment
Share on other sites

Und du hast ganz sicher die aktuelle 0.9.33.1? Hat deine froxlor/scripts/froxlor_master_cronjob.php Datei in Zeile 50/51 Folgendes:

// also regenerate cron.d-file
inserttask('99');

Wenn nicht hast du nicht die 0.9.33.1 Dateien.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.



×
×
  • Create New...