Logfiles und Größenbegrenzung

[BaNaNaBeck]

Hallo,

ich habe meine Logs in den Ram ausgelagert... zur Verfügung habe ich für den Log Bereich 150 MB gegeben.

Nun habe ich das hier eingestellt:

Code: Alles auswählen

/var/log/syslog
{
	rotate 1
	daily
	size 10M
	missingok
	notifempty
	delaycompress
	compress
	postrotate
		invoke-rc.d rsyslog reload > /dev/null
	endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
	rotate 1
	daily
	size 10M
	missingok
	notifempty
	compress
	delaycompress
	sharedscripts
	postrotate
		invoke-rc.d rsyslog reload > /dev/null
	endscript
}

Aber wie kann es dann sein, dass das daemon.log dennoch 55 MB groß wird? Nach dem ich alles eingestellt habe, habe ich mal nen reboot gemacht.

Den Speicher habe ich auf 150 MB erhöht.. dennoch ist er voll belegt

Sihe Bild: http://gallery.debianforum.de/d/26439-1 ... uuuunt.JPG


Dann habe ich noch in << etc/default/bootlogd >> das Bootlog eingestellt mit:

Code: Alles auswählen

BOOTLOGD_ENABLE=yes

Aber ich kann es hier nicht finden unter << var/log >>



Was muss ich einstellen, dass die Logfiles auch wirklich nur 10MB größer werden und nicht mehr?

[rendegast]

Was Du da hast sind die Einstellungen für das logrotate, ein Skript unterhalb /etc/cron.daily/.
Die Logdateien werden nicht ständig überwacht, sondern periodisch geschrumpft.


Wenn die Dateien so anwachsen, liegt es daran
-- daß entweder cron.daily/ nicht aufgerufen wird,
dann dessen Ausführungszeit in die Zeit öfterer Rechnerbenutzung legen -> /etc/crontab einstellen,
eventuell den Job auch nach cron./hourly verschieben.
oder eine andere Art des Aufrufs gestalten, zBsp. zusätzlich anacron oder Ersetzen von cron durch fcron.
(Die cron-Jobs sollten den Regelbetrieb wegen ihrer normalerweise niedrigen Priorität nicht stören.)
-- oder ein Dienst ausrastet und massiv Meldungen produziert -> auch mal ins Logfile sehen, Dienste kontrollieren,
Alternativen [r]syslog[-ng] mit filigraner Einstellungsmöglichkeit.


Das Dumme an Logs im Ram ist, daß sie nach einem Neustart nicht mehr zur Verfügung stehen.
Hier ist es bei nur 512MB RAM zudem auch noch teuer erkauft.

[BaNaNaBeck]

Hi,

danke erst mal für die Antwort. Die Logs werden beim booten auf die CF Karte geschrieben und nach dem Starten wieder in den Ram gelegt. So kann ich die Schreibvorgänge auf der CF Karte minimieren.

Meine crontab sieht so aus:

Code: Alles auswählen

# m h dom mon dow user	command
17 *	* * *	root    cd / && run-parts --report /etc/cron.hourly
25 6	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6	* * 7	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6	1 * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

[rendegast]

Dann verschieb das ganze doch auf zBsp. 18:xx

Code: Alles auswählen

...
25 18   * * *   root   test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 18   * * 7   root   test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 18   1 * *   root   test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Und für den Anfang einfach mal händisch ausführen:

Code: Alles auswählen

#!/bin/sh
cd / && run-parts --report /etc/cron.daily 
cd / && run-parts --report /etc/cron.weekly
cd / && run-parts --report /etc/cron.monthly

[BaNaNaBeck]

Na dann bin ich mal gespannt...

Code: Alles auswählen

root@debian / > cd / && run-parts --report /etc/cron.daily
/etc/cron.daily/exim4-base:
2010-05-29 15:12:16 1OILpo-0000jt-3j Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=101 egid=103^[[A
root@debian / > cd / && run-parts --report /etc/cron.weekly
root@debian / > cd / && run-parts --report /etc/cron.monthly
root@debian / > /etc/init.d/cron restart
Restarting periodic command scheduler: crond.
root@debian / >

daemon.log
debug
syslog

kann es sein das in allen drei dateien das gleiche gleichzeitgt geloggt wird?

[rendegast]

Na dann bin ich mal gespannt...

Haben sich die entsprechenden Logs in kleinere *.gz umgewandelt?

/etc/cron.daily/exim4-base:
2010-05-29 15:12:16 1OILpo-0000jt-3j Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=101 egid=103^[[A

Denke das kommt vom Neustartversuch des exim4.

euid=101 egid=103

Code: Alles auswählen

ls -l /var/log/exim4

[BaNaNaBeck]

Code: Alles auswählen

root@debian / > ls -l /var/log/exim4
insgesamt 4
-rw------- 1 root        root    0 26. Mai 22:40 mainlog
-rw------- 1 root        root    0 26. Mai 22:40 mainlog.1
-rw------- 1 root        root    0 26. Mai 22:40 mainlog.2.gz
-rw------- 1 root        root    0 26. Mai 22:40 mainlog.3.gz
-rw------- 1 root        root    0 26. Mai 22:40 mainlog.4.gz
-rw-r----- 1 Debian-exim adm  3346 29. Mai 15:12 paniclog
root@debian / >

Haben sich die entsprechenden Logs in kleinere *.gz umgewandelt?

Nein. Ich habe nun erstmal alle alten Logs von Hand gelöscht.

Aktuell sieht das ganze dann so aus:



Ich warte nun mal ab was um 18 Uhr passiert. Denn da sollte nun ja logrotate anspringen oder?

[BaNaNaBeck]

Nun sieht das ganze so aus:









Ich hab aber irgendwie das Gefühl das cronjobs nicht ausgeführt werden

Code: Alles auswählen

*/5 * * * * www-data wget -q --spider http://localhost/cccam/infophp/cron_update.php?p=0  #CCcamInfoPHP - Update jede Minute

Das sollte ja eigentlich alle 5 Minuten aktuallisiert werden. Passiert aber auch nicht.

[rendegast]

Ähem,

Code: Alles auswählen

   size 10M
...
   size 10M

zippen tut er ja auch erst ab der Größe.
'man logrotate':

Code: Alles auswählen

       size size
              Log files are rotated when they grow bigger than size bytes.  If
              size  is  followed by k, the size is assumed to be in kilobytes.
              If the M is used, the size is in megabytes, and if  G  is  used,
              the  size is in gigabytes. So size 100, size 100k, size 100M and
              size 100G are all valid.

Ändere mal in zBsp.

Code: Alles auswählen

   size 1M
...
   size 1M

oder entferne diese ganz (scheint dann einen (relativ kleinen) default zu treffen).

Denn da sollte nun ja logrotate anspringen oder?

cron läuft auch?

[BaNaNaBeck]

Okay.

Ich hab nun size auf 2M gestellt und logrotate mit << /etc/init.d/rsyslog restart >> neugestartet

Die cronjobs auf 19 Uhr gesetzt und den cron mit << /etc/init.d/cron restart >> neugestartet

Dann warten wir mal 19 Uhr ab. Ich melde mich dann mit meinen Screenshots

[rendegast]

Die cronjobs auf 19 Uhr gesetzt und den cron mit << /etc/init.d/cron restart >> neugestartet

cron übernimmt Änderungen in /etc/crontab oder /etc/cron.d/* on-the-fly, ohne Neustart.
Dagegen zBsp. fcron muß zum erneuten Einlesen veranlaßt werden
(mensch kann dazu auch einen Wächter für fcron laufen lassen,
ich habe jedoch nach gewissen Grundeinstellungen in der system-fcrontab keinen Anlaß mehr dafür.
Und die user-fcrontabs werden bei Änderung mittels 'fcrontab' neu eingelesen.).

[BaNaNaBeck]

Hat nun wohl geklappt. Wir kommen der Sache näher

Allerdings werden die alten nicht gezippt. Ist auch nicht weiter tragisch.

Aber wenn ich das nun alles richtig verstanden habe, dann wird dies nun einmal am Tag überprüft. Also laufen die Logs solange voll. Und wenn dann die Vorgaben überschritten worden sind, kommt Logrotate ins Spiel und macht nen neues Logfile auf.

Wie kann ich das nun so machen das dies z.b alle 5 Stunden passiert?

[rendegast]

Du brauchst es nicht zu übertreiben, diese logs laufen im Normalfall nicht so schnell voll.
Und als Textdateien gezippt sind sie sehr klein - bei mir brauchen diese zusammen nicht 1MB,
also kannst Du auch 'rotate 1' höher stellen.
Komprimiert wird ab dem backup.2, also backup.2.gz, backup.3.gz ...

Um das Script häufiger auszuführen reicht
/etc/cron.d/logrotate_local :

Code: Alles auswählen

* */5 * * * root /etc/cron.daily/logrotate

 oder direkter
* */5 * * * root /usr/sbin/logrotate /etc/logrotate.conf

[BaNaNaBeck]

Also in /etc/cron.d habe ich bisher keine Dateien drin. Dafür habe ich noch die Ordner: cron.daily, cron.hourly, cron.monthly, cron.weekly

Soll ich dann im Ordner cron.d die Datei logrotate_local erstellen und das dann einfügen?

[rendegast]

Soll ich dann im Ordner cron.d die Datei logrotate_local erstellen und das dann einfügen?

Genau

[BaNaNaBeck]

Jetzt hab ich nur noch eine Frage woran es liegen kann, dass dieser cronjob nicht ausgeführt wird und alle 5 Minuten das update macht.

Code: Alles auswählen

*/5 * * * * www-data wget -q --spider http://localhost/cccam/infophp/cron_update.php?p=0  #CCcamInfoPHP - Update alle 5 Minuten

[rendegast]

Wo steht der denn?
Steht was in einem log-file?
Bekommst Du eine Mail von cron deswegen?

Entferne vielleicht mal den Anhang " #CCcamInfoPHP - Update alle 5 Minuten".
"/usr/bin/wget" statt "wget" verwenden?
Das "?" quoten?

[BaNaNaBeck]

Der EIntrag steht in der crontab. In keinem Logfile steht was dazu. Der job ist dafür zuständig eine Status auf die man von Extern zugreifen kann upzudaten. Eine Mail bekomme ich nicht und ist auch nicht geplant.

[rendegast]

Ohne log und Mail die Kristallkugel?

und ist auch nicht geplant.

Benachrichtigung über Probleme wäre aber gut.

Zur Probe einen einfachen Job:

Code: Alles auswählen

*/5 * * * * www-data /bin/touch /tmp/Problemjob
#*/5 * * * * www-data wget -q --spider http://localhost/cccam/infophp/cron_update.php?p=0  #CCcamInfoPHP - Update alle 5 Minuten

Ausführung ließe sich dann am geänderten Dateidatum ablesen.

[BaNaNaBeck]

Also ich habe die Datei Problemjob im tmp ordner angelegt. Aber auch nach 10 Minuten ist immer noch das Erstellungsatum zu sehen

[cosmac]

hi,

* Wem gehört denn /tmp/Problemjob? Wenn du die als root angelegt hast, kann der cronjob sie als www-data nicht touchen. Wenn du sie löschst, erzeugt sie der Job selber neu.
* Läuft cron wirklich? Der schreibt normal für jede Aktion eine Zeile nach /var/log/syslog.
* Hat die job-Datei ind cron.d Sonderzeichen im Namen? Unterstrich und Bindestrich sind wohl gerade noch erlaubt, Punkte glaube ich schon nicht mehr.

[BaNaNaBeck]

* Wem gehört denn /tmp/Problemjob? Wenn du die als root angelegt hast, kann der cronjob sie als www-data nicht touchen. Wenn du sie löschst, erzeugt sie der Job selber neu.

Ja, hatte die Datei als root angelegt. Nun wieder gelöscht. Aber die Datei wird auch nicht erstellt...

* Läuft cron wirklich? Der schreibt normal für jede Aktion eine Zeile nach /var/log/syslog.
* Hat die job-Datei ind cron.d Sonderzeichen im Namen? Unterstrich und Bindestrich sind wohl gerade noch erlaubt, Punkte glaube ich schon nicht mehr.

Die Datei /etc/init.d/cron ist leer. Daher gehe ich nun mal davon aus, dass crond gar nicht laufen kann. Warum die Datei auf ein mal leer ist kann ich nciht sagen. Wird aber mein Fehler gewesen sein.

[BaNaNaBeck]

Den Inhalt habe ich nun wieder eingepflegt.

Jedoch wird das Uptdate immer noch nicht gemacht und die Datei Problemjob nicht erstellt

Im syslog erhalte ich diese Meldung:


May 30 01:18:21 debian /usr/sbin/cron[4064]: (CRON) INFO (pidfile fd = 3)
May 30 01:18:21 debian /usr/sbin/cron[4065]: (CRON) STARTUP (fork ok)
May 30 01:18:21 debian cron[4065]: Error: bad username; while reading /etc/crontab
May 30 01:18:21 debian /usr/sbin/cron[4065]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
May 30 01:18:27 debian /usr/sbin/cron[4085]: (CRON) INFO (pidfile fd = 3)
May 30 01:18:27 debian /usr/sbin/cron[4086]: (CRON) STARTUP (fork ok)
May 30 01:18:27 debian cron[4086]: Error: bad username; while reading /etc/crontab
May 30 01:18:27 debian /usr/sbin/cron[4086]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
May 30 01:20:01 debian cron[4086]: Error: bad username; while reading /etc/crontab

[rendegast]

/etc/init.d/cron leer, diese Meldungen beim cron-Start bzw. exim4-Start, Deine Modifikationen "logrotate".
Wieviel hast Du noch modifiziert? Da ist doch der Wurm drin.

Wenn es das nicht ist, hat die flashdisk / das Dateisystem eine Macke?

Neuinstallation machen?

[BaNaNaBeck]

Also hier mal der aktuelle Status:

Code: Alles auswählen

45 14	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Dieser Job wurde soeben ausgeführt und es wurde auch auf Logrotate zurückgegriffen und neue Logfiles erstellt.

Allerdings greift er nicht auf den Ordner /etc/cron.d und das File: logorotate_local zurück. Muss ich nirgends einstellen das er auch darauf zurückgreifen soll?


Ich habe das nun erstmal so gelöst in der crontab:

Code: Alles auswählen

45 16	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
45 22	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
45 04	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
45 10	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Die Logfiles brauch ich auch weniger zum nachsehen sondern die laufen für fail2ban von daher ist das ned so schlimm wenn die alle 6 Stunden rausgehauen werden.

mfg