Hi Anne

das mit dem tar ist auch etwas tiefer verstekct - kann auch später noch gemacht werden, schauen wir mal, wie sich diese Änderung auswirkt.

die zweite Zeile, die du weggelassen hast ist für die Sicherung von ispcp selbst verantwortlich. Ich würde sie wieder hineinmachen - ggf. mit zeitlichen Angaben (statt @daily), ein "nice -n 19" vor dem Befehl, oder so wie es jetzt ist, wieder reintun (übrigens: es reicht ein # an den Anfang der Zeile zu setzen, um diese zu deaktivieren...

Nach den Änderungen muss man den cron-Dienst ggf. neu starten:

/etc/init.d/cron restart

Gruss J

ok ich habe es nochmal geändert. Nun sieht das ganze so aus und den Cron-Dienst Befehl habe ich auch ausgeführt.

delayed tasks START.

# Quota
@daily root /var/www/ispcp/engine/quota/ispcp-dsk-quota &>/var/log/ispcp/ispcp-dsk-quota.log

# Traffic
0,30 * * * * root /var/www/ispcp/engine/traffic/ispcp-srv-traff &>/var/log/ispcp/ispcp-srv-traff.log
0,30 * * * * root /var/www/ispcp/engine/traffic/ispcp-vrl-traff >/var/log/ispcp/ispcp-vrl-traff.log
15,45 * * * * root /var/www/ispcp/engine/traffic/ispcp-vrl-traff-correction &>/var/log/ispcp/ispcp-vrl-traff-correction.log

# customer logs
@daily root /var/www/ispcp/engine/tools/ispcp-httpd-logs-mngr &>/var/log/ispcp/ispcp-httpd-logs-mngr.log

# Backup
#@daily root /var/www/ispcp/engine/backup/ispcp-backup-all yes &>/var/log/ispcp/ispcp-backup-all-mngr.log

0 3 * * * root nice -n 19 /var/www/ispcp/engine/backup/ispcp-backup-all yes > /var/log/ispcp/ispcp-backup-all-mngr.log

nice -n 19 root /var/www/ispcp/engine/backup/ispcp-backup-ispcp noreport &>/var/log/ispcp/ispcp-backup-ispcp-mngr.log

# Remove config backups older than seven days
@daily root find /etc/ispcp/*/backup/* -maxdepth 0 -type f -mtime +7 -print | egrep '.*\.[0-9]+$' | xargs -r /bin/rm

# Remove Daemon Logs older than 14 days (except .gz files)
@daily root find /var/log/ispcp/* -maxdepth 1 -type f -mtime +14 -print | egrep '.*\.gz$' | xargs -r /bin/rm

# AWStats
15 */6 * * * root /var/www/ispcp/engine/awstats/awstats_updateall.pl now -awstatsprog=/usr/lib/cgi-bin/awstats.pl >/dev/null 2>&1

# Rootkit Hunter
0 */12 * * * root /usr/bin/rkhunter --scan-knownbad-files --check-deleted --createlogfile --cronjob --createlogfile /var/log/rkhunter.log>/dev/null 2>&1

# Chkrootkit
0 */12 * * * root /usr/sbin/chkrootkit &> /var/log/chkrootkit.log

# Look for and purge old sessions every 30 minutes
0,30 * * * * root /var/www/ispcp/engine/tools/ispcpphptemp.sh >/dev/null 2>&1

# [{DMN_NAME}] backup task START.
# [{DMN_NAME}] backup task END.

# [{DMN_NAME}]:{CRONJOB_ID} custom task START.
# [{DMN_NAME}]:{CRONJOB_ID} custom task END.

# [{DMN_NAME}] AWStats static tasks START.
# [{DMN_NAME}] AWStats static tasks END.

# delayed tasks END.

ich schau's mir mal direkt an... hab das Gefühl, dass das noch nicht so ganz korrekt ist...

so


ispcp backup läuft um 2:30 Uhr, die Kundenbackups um 3 Uhr...

mal sehen, was heut nach geht...

Gruss J

Das währe sehr nett von dir. Vielleicht schaust du auch mal warum der heute zusammen gebrochen ist.

Hi Anne

ich sehe grad nicht, was das war - aber mit Mailabholen ging wohl auch nichts letzte Nacht - immer Fehler mit dem Speicher...

Da ich nicht viel Ahnung habe, ob da die VE noch eine Rolle spielt, kann ich nicht viel helfen - aber vielleicht wäre es doch mal gut, den speicher zu testen -das dauert bei 4GB aber ne Weile.

Gruss J

Willst du den testen? Dann mache ruhig, es nützt ja nichts. Oder wie meintest du das?

üblicherweise wird der getestet, wenn Linux nicht geladen ist (memtest86 zB. wird *anstelle* des Systems gestartet...)

Ist wohl eher was für den Provider, wo der Server steht.

Vielleicht können die den Ram mal tauschen und testen... ???

Das können wir vergessen, die machen nichts. Die sagen der Server läuft und gut ist. Tut er ja eigentlich auch, aber eben das Problem das vom RAM nichts übrig bleibt.

Hattest du noch einen Fehler gefunden?

Nichts sehr aussagekräftiges. Cannot allocate memory...

Mal sehen, wie es diese Nacht geht - da wird das Backup später gemacht und mit weniger Last.

Es sind aber noch ein paar Dinge, die man auf dem Server kontrollieren/korrigieren sollte:
nicht für alle Domains sind die Mail-Verzeichnisse erstellt worden. Ich denke, das hängt noch mit den früheren Problemen zusammen.
in /var/mail/virtual sollte für jede domain ein Verzeichnis bestehen - und darin für jede Mailadresse wiederum ein Verzeichnis - mit mehreren Unterverzeichnissen (Maildir)...

Die sache mit den SQL-Usern ist auch noch nicht gelöst - es werden nicht alle Sicherungen der Kunden-Datenbanken durchgeführt!

Gruss J