/var/log/ in eine Art RAMdisk auslagern & weitere Optimierungen bezgl. Logs

meigrafd · Aug 24th 2014

Angenommen das varlog Script läuft noch nicht und angenommen die Datei /var/log/syslog hat einen timestamp vom 3.Mai

Wenn wir jetzt varlog starten wird die Datei /var/log/syslog nach /var/save.log/ kopiert und tmpfs für /var/log/ erzeugt bzw da drüber gemountet.
Als würde man einen Eimer auf eine anderen halb vollen drauf stellen, dann tropft das Wasser in den oberen Eimer aber nicht mehr in den da drunter. Im unteren Eimer ist aber weiterhin das alte Wasser drin..

Anschließend wird die Datei /var/save.log/syslog wieder in den neuen, leeren tmpfs Ordner /var/log/ kopiert.

Nun wird in /var/log/syslog etwas rein geschrieben, somit wird der timestamp raufgesetzt.

Irgendwann, sagen wir am 20.Mai, führen wir einen Reboot durch.

Die Datei /var/log/syslog wird erneut nach /var/save.log/ kopiert, da die aktuelle Datei einen timestamp vom 20.Mai besitzt, diese also neuer ist als die /var/save.log/syslog vom 3.Mai

Nun startet der Rechner neu.
Der tmpfs Mount ist noch nicht vorhanden und /var/log/ beinhaltet Dateien vom 3.Mai auch die syslog Datei ist vom 3.Mai

Das varlog Script kopiert nun nur die Dateien die neuer als von 20.Mai wären. Das trifft aber zu diesem Zeitpunkt auf keine der Dateien zu. (fast) Alle Dateien in /var/save.log/ sind vom 20.Mai wohingegen die Dateien in /var/log/ noch vom 3.Mai sind (das alte Wasser vom unteren Eimer)

Und nun wird tmpfs erzeugt bzw über /var/log/ gelegt und die Dateien aus /var/save.log/ nach /var/log/ kopiert.... In /var/log/ sind nun Dateien vom 20.Mai, eben von dem Tag als rebootet wurde

Ist es jetzt klar wie das abläuft

WinterUnit16246 · Aug 24th 2014

Jau, habe ich jetzt verstanden... ... mir war nur die Technik ein wenig suspekt.... ich hatte nen falschen Fokus auf den Copy. Mir war klar, dass er nix kopiert, aber mir war nicht klar, dass genau das beabsichtigt war. Meine Logik ist da irgendwie geradliniger.... *lacht*... zum Salto noch ne Schraube.... dafür bin ich zu alt. :s

Ich habe mein Script für beide Pi's jetzt fertig und das gerade "oben" aktualisiert. Das Problem (meines Verstehens) wäre gelöst, wenn die letzten beiden Zeilen auch in meinem Stop-Code-Block nicht auskommentiert wären. Da liegt nämlich genau das Problem, warum die SDC-Logs nie wieder zurückaktualisiert werden. Denn diese beiden Kommandos funktioneren eben nicht. Allerdings denke ich auch, soooo wichtig ist das nicht. Bei mir liegt jetzt alles auf der Platte... und das reicht, um, bei Bedarf was zu recherchieren.

Na ja... war auf jeden Fall für mich spannend..... :thumbs1:

Gruss, Thomas

framp · Aug 24th 2014

Ein kleines Problem gibt es durch das cp: Alte nicht mehr existierende Dateien in /var/log werden nicht dabei gelöscht. Hatte ich mit meigrafd schon diskutiert. Eine Lösung ist die Benutzung von rsync. Allerdings ist die Kanone da etwas zu gross für den Spatz cp reicht vollends.

WinterUnit16246 · Aug 24th 2014

Ich hoffe , Du hilfst mir noch einmal..... ich weiss nicht, wie ich das eintragen muss. Ich glaube, mein Script funktioniert gar nicht.....
sudo update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .

Ich müsste ja noch nen 2 Parameter angeben, um die Pi's im Zielverzeichnis zu unterscheiden. Da weiss ich jetzt nicht mehr weiter :s

Od muss ich ein "Zwischenscript" in die Runlevels eintragen, welches das richtige dann mit zusätzlichem Parameter 2 startet?

Gruß, Thomas

WinterUnit16246 · Aug 25th 2014

Hallo meigrafd

Ich hoffe, Du bist nachsichtig bezüglich meines enthusiastischen Eifers als Linux-Anfänger und nimmst mir das nicht übel.... aber ich bin immer noch der Meinung, dass im Script ein Integritäts-Problem mit eigentlich regelmäßigem Datenverlust besteht.... und zwar bei JEDEM Systemstart.

Ich bin der Meinung, dass sdc->/var/log ausser beim allerersten Start von varlog danach gar nicht mehr verwendet werden darf. Ich versuche das mal zu erklären und greife auf meine Datumsbeispiele zurück.

Der Rechner hatte ein Laufzeit vom 3. bis 20. Mai und wird am 20. Mai neu gestartet. In der Zeit vom 3. bis zum Shutdown wurden die Logs in tempfs->/var/log geschrieben und beim shutdown nach $varlogSave gesichert. Bis dahin ist alles im grünen Bereich.

Nun wird der Rechner am 20. neu gestartet. Bevor varlog gestartet und aktiv ist, werden zunächst mal Log-Einträge ganz normal nach sdc->/var/log geschrieben.... sofern irgendwelche Programme überhaupt Einträge schreiben und das vor dem varlog-start tun. Und damit wird das Filedatum der betroffenen Dateien in sdc->/var/log aktualisiert und aus einer Alt-Datei vom 3. Mai wird eine geänderte mit heutigem Datum. In dieser Datei fehlen aber alle Einträge vom 3. bis 20. Und nun überschreibt beim Copy im Start-Code-Block diese Alt-Datei mit dem Log-Eintrag von heute (aber einem Datenloch vom 3. - 20) die eigentlich aktuelle und vollständige Datei in $varlogSave, die dann anschließend wiederum nach tempfs->/var/log kopiert wird.Damit sind die Log-Daten dieses Prozesses aus dem Zeitraum 3.-20.verloren.

Meiner Meinung nach sollten die in der Bootphase vor varlog geschriebenen einträge ebenso wie die in der shutdownphase nach varlog geschriebenen Einträge in sdc->/var/log einfach unberücksichtigt bleiben. Reinkopieren -um das zu aktualisieren- geht leider nicht, und rauskopieren kopiert mit einem aktuellem Datum verfälschte Dateien, die keine Daten der Zeiten vor dem Boot enthalten.

Ich habe das jetzt in meinem Script gelöst. Ebenso das Problem mit den Backup von 2 Pi's, die nicht kollidieren dürfen..... das war sogar einfacher als gedacht. Ich habe das oben mal aktualisiert.

Gruss, Thomas

WinterUnit16246 · Sep 5th 2014

Hallo @ all

Jetzt ist mir beim Durchsehen meiner Job-Log-Protokolle aufgefallen, dass mit meiner varlog-Adaption doch was nicht stimmt. Und beim genaueren Hinsehen habe ich festgestellt, dass sich die Files auf dem Hin- und Rückweg zwischen tempfs und meinem BackupDir regelrecht kaputt kopiert haben. Ich bin da jetzt nicht großartig traurig, denn nach ein paar Tagen füllen sich die Pötte ja alle wieder neu und sind dann irgendwann korrekt .... und im Moment gibts auch keinen Bedarf, in den Logs nach echten System-Fehlern zu suchen.

Die Auswirkungen des Fehlers sind also im Moment "erträglich", und nachdem ich die Ursache beseitigt habe, lösen sich diese Fehlerauswirkungen irgendwann in Luft auf. Was war die Ursache? Es war das noch nicht verfübare Netzwerk in der Startphase der PI's. Bei mir sind ja beide PI vollständig im Netz integriert und nutzen demenstprechend auch die Speichermedien des Netzes für alle Aktionen.... eben genau das tut auch das Script "varlog".

Ich habe jetzt in meinem Script ganz oben in der Sektion der Var-Inits 10 Wartesekunden eingebaut, wenn der Start des Scripts aller Wahrscheinlichkeit nach aus den Runlevels erfolgt ist. Damit ist der Fehler nie wieder aufgetreten. Aber ich weiss nicht, ob es da nicht eine bessere Methode gibt, als eine konstante Zeit zu warten.

Hat vielleicht jemand einen Rat?

Gruß, Thomas

rpi444 · Sep 5th 2014

Gelöscht wegen OT.

WinterUnit16246 · Sep 6th 2014

Moin

Quote from rpi444

Ich starte Scripte die das Netzwerk benötigen, aus dem Verzeichnis "/etc/network/if-up.d".

Starten die dort liegenden Scripte automatisch, wenn das Netz verfügbar ist? Was passiert, wenn das Netz resp. der Router mal kurz wegfällt und neu startet...?... würde das Script dann noch mal starten?

Gruß, Thomas

rpi444 · Sep 6th 2014

Gelöscht wegen OT.

meigrafd · Sep 6th 2014

Er hat das Script als Vorlage für sein Individuelles Vorhaben abgeändert - also würde ich euch bitten euren Problem-Lösungungs-Talk in einem eigenen Thread abzuhandeln, da das im Grunde nichts mehr mit diesem Tutorial hier zu tun hat... Danke

Würde jeder sein individuelles Problem in den Anleitungs-Threads behandeln, würden diese ziemlich schnell aus allen Nähten platzen und extrem unübersichtlich werden. Daher bitte ich erneut um Verständnis und stillem Nachkommen.

Philthom · Sep 22nd 2014

Ein kleiner Erfahrungsbericht: Erst einmal vielen Dank für das schöne Tutorial. Habe mich von vorne nach hinten durchgearbeitet. ...und auch installiert.

Zum Thema:

Code

sed -i /etc/default/rcS -e "s/RAMRUN=no/RAMRUN=yes/"
sed -i /etc/default/rcS -e "s/RAMLOCK=no/RAMLOCK=yes/"

ein df -h brachte zutage, dass die Switches schon gesetzt waren. In der rcS gab es keine Einträge - jedoch in der /etc/default/tmpfs. Habe ich dann so belassen. Also: nicht wie oben erwähnt einfach in die rcS eintragen.

Zum Thema:
umount in der stop-Sequenz. Ein händische Ausführen der Cron-Befehle hat auch mir bestätigt, dass dieser umount wegen Zugriffes erfolglos abgebrochen wird. Ich habe ihn entfernt. Die if-Anweisung in der start-Sequenz wird aufgrund des fstab-Eintrages bei mir nicht durchlaufen. Das ist aus meiner Sicht auch ok. Somit verkürzt sich der Cron-Eintrag wieder auf den ursprünglichen kürzeren, einteiligen Befehl.

Code

#varlog - Taeglich um 05:00
0 5 * * * root /etc/init.d/varlog stop >/dev/null 2>&1

Code

......
d=`date +%d-%m-%Y-%H-%M`
varlogLog=/var/log/loglog
.....
 fi
        cp -Rpu ${varlogSave}* /var/log/
        echo $d "*** Starting tmpfs file restore: varlog." >> $varlogLog  <-----------
    ;;
    stop)
        echo "*** Stopping tmpfs file saving: varlog."
        echo $d "*** Storing tmpfs files: varlog." >> $varlogLog  <--------------
        #[ -n $varlogSave ] && rm -rf ${varlogSave}*
......

Display More

Die beiden oben gekennzeichneten Zeilen loggen das Durchlaufen der start bzw stop Sequenz.

Zum Thema
was wird beim booten gerade noch vor dem Mounten in die alten /var/log/dateien geschrieben? Bei mir gar nichts. Nada. Habe die SD in meinen Desktoprechner getan und die alten Dateien in der /var/log gelöscht. Wieder zurück in den Raspi. Ein rehalt durchgeführt und die Karte im Desktop ausgelesen: Keine Einträge im /var/log.
Somit müssen hier auch keine gesonderten Mechanismen berücksichtigt werden. Wegen eines fehlenden umount-Befehls mache ich mir auch keinen Kopf, da die Partition beim shutdown sowieso ins Daten-Nirvana geschickt wird.

rpivpn · Nov 7th 2014

Moin,

nachdem eine meiner SD´s den Geist aufgegeben hat, machte ich mich auf die Suche und fand noch etliche Prozesse, die schreibend auf die SD zugreifen.
So z. B. die Datei dead.letter ("Mail Mülleimer" für nicht zugestellte Mails) und weitere Prozesse, die, gut versteckt, die SD beanspruchen.

Wie nun bändigen?
Eine Ramdisk ist ja schon vorhanden (/var/log....) und Links setzen ist ja auch keine Hexerei.
Beispiel anhand der Datei: /root/dead.letter

(vorher als root einloggen)
1)Datei in der RAMDisk verschieben:

Code

mv /root/dead.letter /var/log/dead.letter

2)Link auf ursprüngliche Datei setzen:

Code

ln -s /var/log/dead.letter /root/dead.letter

3)Test, ob Daten geschrieben werden und der Link funktioniert:

Code

echo testroot >> /root/dead.letter | echo testvarlog >> /var/log/dead.letter | tail /root/dead.letter

Die Ausgabe von tail sollte jetzt wie folgt aussehen:

Quote

.....
testroot
testvarlog

4)Prima, damit die Datei aber nicht im Laufe der Zeit anschwillt und unnötig Speicher frisst, kann diese in logrotate eingebunden werden oder vor der RAMDisk-Sicherung mit

Code

> /var/log/dead.letter

z. B. per cronjob geleert werden.

Da im Mail Mülleimer dann doch gelegentlich interessante Info´s schlummern lasse ich mir diese per Mail zustellen, vor dem Löschen.

Bye

Jürgen

Jasimo · Sep 5th 2015

Moin,

hab das script gestern getestet und es funktioniert soweit. Nur bekomme ich heute morgen eine Email mit der Info das logrotate probleme hat.

Code

/etc/cron.daily/logrotate:
error: skipping "/var/log/aptitude" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/dpkg.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/alternatives.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/php5-fpm.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/syslog" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail.info" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail.warn" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail.err" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/mail.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/daemon.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/kern.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/auth.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/user.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/lpr.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/cron.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/debug" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/messages" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/wtmp" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/btmp" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

Display More

Die Rechte von /var/log sehen so aus:

Code

/var $ ls -la
total 102448
drwxr-xr-x 12 root root       4096 Sep  4 12:34 .
drwxr-xr-x 23 root root       4096 Aug  2 17:58 ..
drwxr-xr-x  2 root root       4096 Aug 23 06:25 backups
drwxr-xr-x 11 root root       4096 May  7 01:29 cache
drwxr-xr-x 43 root root       4096 Aug  2 18:30 lib
drwxrwsr-x  2 root staff      4096 Jan 11  2015 local
lrwxrwxrwx  1 root root          9 May  7 00:12 lock -> /run/lock
drwxrwxrwt 10 root root       1620 Sep  4 19:28 log
drwxrwsr-x  2 root mail       4096 May  7 00:12 mail
drwxr-xr-x  2 root root       4096 May  7 00:12 opt
lrwxrwxrwx  1 root root          4 May  7 00:12 run -> /run
drwxr-xr-x 10 root root       4096 Sep  4 12:34 save.log
drwxr-xr-x  4 root root       4096 May  7 00:17 spool
-rw-------  1 root root  104857600 May  7 01:29 swap
drwxrwxrwt  2 root root       4096 Aug 22 19:31 tmp

Display More

hat jemand einen Tipp?
Gruß
Jan

meigrafd · Sep 5th 2015

Bitte poste die Rechte der Verzeichnisse die angekreidet werden.

Jasimo · Sep 5th 2015

Hallo,

danke für die Rückmeldung, logrotate kreidet ja nicht nur Verzeichnisse an sondern auch files in /var/log.
Scheint als wenn es an dem chmod 755 für /var/log/ liegt, welches in deinem Skript Anwendung findet. Ist vielleicht "zu viel Recht" für den Geschmack von logrotate. Hier trotzdem mal ein ls-la innerhalb von /var/log

Code

-rw-r--r--  1 root root      0 Sep  1 06:25 alternatives.log
-rw-r--r--  1 root root  51054 Aug 22 18:46 alternatives.log.1
drwxr-xr-x  2 root root    120 Sep  1 06:25 apt
-rw-r-----  1 root adm  130804 Sep  5 22:18 auth.log
-rw-r-----  1 root adm  114743 Aug 30 06:25 auth.log.1
-rw-r-----  1 root adm    8537 Aug 23 06:25 auth.log.2.gz
-rw-r-----  1 root adm    5861 Aug 16 06:25 auth.log.3.gz
-rw-r-----  1 root adm   13377 Aug  9 06:25 auth.log.4.gz
-rw-r--r--  1 root root 328694 May  7 00:19 bootstrap.log
-rw-rw----  1 root utmp      0 Sep  1 06:25 btmp
-rw-rw----  1 root utmp      0 May  7 00:12 btmp.1
drwxr-xr-x  2 root root     40 Aug 11  2012 ConsoleKit
-rw-r-----  1 root adm  209043 Sep  5 22:16 daemon.log
-rw-r-----  1 root adm  180844 Aug 30 06:15 daemon.log.1
-rw-r-----  1 root adm   17671 Aug 23 06:22 daemon.log.2.gz
-rw-r-----  1 root adm    5294 Aug 16 06:22 daemon.log.3.gz
-rw-r-----  1 root adm   28985 Aug  9 06:22 daemon.log.4.gz
-rw-r-----  1 root adm    5954 Sep  4 19:28 debug
-rw-r-----  1 root adm    1258 Aug 26 23:17 debug.1
-rw-r-----  1 root adm     728 Aug 22 12:52 debug.2.gz
-rw-r-----  1 root adm     457 Aug 19 09:12 debug.3.gz
-rw-r-----  1 root adm    1780 Aug  3 18:11 debug.4.gz
-rw-r--r--  1 root adm   15573 Sep  4 19:28 dmesg
-rw-r-----  1 root adm   15848 Aug 26 23:17 dmesg.0
-rw-r-----  1 root adm    6010 Aug 22 12:51 dmesg.1.gz
-rw-r-----  1 root adm    6092 Aug 22 12:28 dmesg.2.gz
-rw-r-----  1 root adm    6053 Aug 20 21:33 dmesg.3.gz
-rw-r-----  1 root adm    6011 Aug 20 21:30 dmesg.4.gz
-rw-r--r--  1 root root      0 Sep  1 06:25 dpkg.log
-rw-r--r--  1 root root 623966 Aug 22 18:46 dpkg.log.1
-rw-r--r--  1 root root  24024 May  7 01:02 faillog
-rw-r--r--  1 root root   1746 May  7 01:15 fontconfig.log
drwxr-xr-x  2 root root     80 May  7 00:16 fsck
-rw-r-----  1 root adm  142245 Sep  5 13:50 kern.log
-rw-r-----  1 root adm   40083 Aug 30 00:06 kern.log.1
-rw-r-----  1 root adm   26053 Aug 22 18:52 kern.log.2.gz
-rw-r-----  1 root adm     573 Aug  9 09:22 kern.log.3.gz
-rw-r-----  1 root adm   47070 Aug  8 11:14 kern.log.4.gz
-rw-rw-r--  1 root utmp 292292 Sep  5 22:18 lastlog
-rw-r-----  1 root adm       0 May  7 01:29 lpr.log
-rw-r-----  1 root adm       0 Aug 23 06:25 mail.err
-rw-r-----  1 root adm     300 Aug 22 18:50 mail.err.1
-rw-r-----  1 root adm     313 Sep  5 06:25 mail.info
-rw-r-----  1 root adm    2470 Aug 22 19:31 mail.info.1
-rw-r-----  1 root adm     313 Sep  5 06:25 mail.log
-rw-r-----  1 root adm    2470 Aug 22 19:31 mail.log.1
-rw-r-----  1 root adm       0 Aug 23 06:25 mail.warn
-rw-r-----  1 root adm     300 Aug 22 18:50 mail.warn.1
-rw-r-----  1 root adm  138235 Sep  5 13:50 messages
-rw-r-----  1 root adm   40420 Aug 30 06:25 messages.1
-rw-r-----  1 root adm   22422 Aug 23 06:25 messages.2.gz
-rw-r-----  1 root adm     752 Aug 16 06:25 messages.3.gz
-rw-r-----  1 root adm   45900 Aug  9 06:25 messages.4.gz
drwxr-xr-x  2 root root    100 May  7 01:29 news
drwxr-xr-x  2 root root    580 Sep  5 06:25 nginx
drwxr-xr-x  2 ntp  ntp      40 Apr 13 00:38 ntpstats
-rw-------  1 root root   1586 Sep  4 19:28 php5-fpm.log
-rw-------  1 root root    268 Aug 26 23:17 php5-fpm.log.1
-rw-------  1 root root    425 Aug 22 12:52 php5-fpm.log.2.gz
-rw-------  1 root root     76 Aug  9 06:25 php5-fpm.log.3.gz
-rw-------  1 root root    402 Aug  3 18:11 php5-fpm.log.4.gz
drwxr-xr-x  2 root root     60 Aug 23 09:51 raspiBackup
-rw-r--r--  1 root root    158 May  7 01:29 regen_ssh_keys.log
drwxr-x---  2 root adm      40 Feb 19  2015 samba
-rw-r-----  1 root adm  203420 Sep  5 22:17 syslog
-rw-r-----  1 root adm   67980 Sep  4 06:25 syslog.1
-rw-r-----  1 root adm    2038 Sep  3 06:25 syslog.2.gz
-rw-r-----  1 root adm    2353 Sep  2 06:25 syslog.3.gz
-rw-r-----  1 root adm    2470 Sep  1 06:25 syslog.4.gz
-rw-r-----  1 root adm    3680 Aug 31 06:25 syslog.5.gz
-rw-r-----  1 root adm    2642 Aug 30 06:25 syslog.6.gz
-rw-r-----  1 root adm    2548 Aug 29 06:25 syslog.7.gz
-rw-r-----  1 root adm     376 Sep  4 19:28 user.log
-rw-r-----  1 root adm     183 Aug 23 10:15 user.log.1
-rw-r-----  1 root adm     201 Aug 22 12:51 user.log.2.gz
-rw-r-----  1 root adm     100 Aug  9 09:24 user.log.3.gz
-rw-r-----  1 root adm     337 Aug  7 22:56 user.log.4.gz
-rw-rw-r--  1 root utmp  75264 Sep  5 22:18 wtmp
-rw-rw-r--  1 root utmp 324864 Aug 31 20:11 wtmp.1

Display More

auf einem anderes Raspi hat /var/log ursprünglich diese Rechte:

Code

drwxr-xr-x 10 root root       4096 Sep  5 06:25 log

anstatt nun:

Code

drwxrwxrwt 10 root root       1620 Sep  4 19:28 log

Jasimo · Sep 8th 2015

ich nochmal sowas lässt mir ja keine Ruhe.

Habe das nochmal genau nach deiner Anleitung gemacht (Wheezy Raspbian, frisch installiert, angemeldet mit User "pi").
Gleich am Anfang beim Script erstellen mittels "nano /etc/init.d/varlog" gibts einen Berechtigungsfehler, also mache ich es mit
sudo nano /etc/init.d/varlog

auch das "chmod +x /etc/init.d/varlog" braucht ein sudo
sudo chmod +x /etc/init.d/varlog

somit auch das "update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 ."
sudo update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .

Ist es vielleicht dann so, dass auch der chmod 755 auf /var/log in deinem script mittels sudo chmod 755 /var/log/ gemacht werden muss?

Denn bei mir ist es so dass nach jedem Reboot die Rechte auf /var/log/ wieder so aussehen.
drwxrwxrwt 10 root root 1620 Sep 4 19:28 log

Update: auch mit sudo chmod 755 /var/log/ im skript sind nach dem booten die rechte auf 777
Automatisch zusammengefügt:[hr]
jetzt nerve ich bestimmt aber ick habs.

Es liegt daran das ich in der fstab schon den Eintrag
tmpfs /var/log tmpfs size=70M 0 0
habe. Denn dadurch hat /var/log 777 und in dem skript wird der chmod ja nur gemacht wenn tmpfs nicht schon vorhanden ist.

meigrafd · Sep 8th 2015

In der Anleitung gehe ich davon aus das man root ist, und somit entfällt es vor jeden Befehl "sudo" zu setzen. Entweder man weiß dass man root Rechte brauch um solche Modifikationen vorzunehmen, wenn das jeder 0815 Benutzer könnte wäre das nicht besonders sicher - oder das man vorher zum root Benutzer wechseln sollte...

Das Script selbst wird bereits als root ausgeführt und benötigt daher kein "sudo", auch nicht die darin befindlichen Befehle.

Im Script wird der chmod nur dann gemacht wenn /var/log noch nicht gemountet ist: if [ -z "$(grep /var/log /proc/mounts)" ]; then
Mit /etc/fstab hat das an dieser Stelle nicht viel zu tun bzw nicht direkt.
Der Eintrag in /etc/fstab ist gewollt und so auch vorgesehen. Was Helfen könnte wäre den chmod unter die if zu setzen, also nach dem "fi"und vor "cp -Rpu ${varlogSave}* /var/log/"

Normalerweise wird /var/log/ nicht separat gemountet. Dh an dieser Stelle geht das Script davon aus, das falls ein mount von /var/log/ schon vorhanden ist das Scripts bereits gestartet wurde und somit diese Operation nicht nochmals machen sollte.

Jasimo · Sep 8th 2015

Hallo,

stimmt alles was Du sagst. Denke das mit dem chmod unter das if ist (zumindest für mich) die Lösung.
Danke! für das tolle Skript und Howto

Nea · Sep 19th 2015

Guten Abend,
die Optimierungen laufen bei mir nun und das sehr gut. Sehr gutes Tut und auch gut erklärt. Eine Frage hätte ich aber nun doch und zwar, ich habe bei meinem RPi kurzes rhytmisches leuchten der SD aktivitäts led, so ca alle sek. 1 mal. Aber wie gesagt das Leuchten ist ganz schwach und rhytmisch. Ist das Normal? Wenn ja ist es mir, anscheinend, vorher nie aufgefallen.

Als Tool habe ich bei mir IOTOP installiert um den lästigen Lese oder Schreibzugriffen Herr zu werden. Ich hänge hier mal einen Screanshot an.
Als OS läuft bei mir Raspbian (Wheezy) sowie Asterisk, DoorPi und den mjpg-streamer.

Kann ich hier noch verbessern?

Danke für Eure Hilfe

meigrafd · Sep 20th 2015

Quote from Nea

ich habe bei meinem RPi kurzes rhytmisches leuchten der SD aktivitäts led, so ca alle sek. 1 mal. Aber wie gesagt das Leuchten ist ganz schwach und rhytmisch. Ist das Normal? Wenn ja ist es mir, anscheinend, vorher nie aufgefallen.

Als Tool habe ich bei mir IOTOP installiert um den lästigen Lese oder Schreibzugriffen Herr zu werden. Ich hänge hier mal einen Screanshot an.

Die Grüne LED (ACT) zeigt allgemein Zugriffe auf die SD an, also sowohl Schreiben als auch Lesen.
Wie du deinem Screenshot entnehmen kannst laufen 4 Prozesse die für diese Zugriffe verantwortlich sind:
doorpi -> lesend
asterisk -> schreibend
jbd2 -> schreibend
ntpd -> schreibend

Lesende Zugriffe sind nicht schädlich und können ignoriert werden.
Was oder wo asterisk schreibt kann ich nicht beurteilen, kenne ich mich nicht mit aus...
jbd2 deutet darauf hin das die Journaling-Funktion des Dateisystems genutzt wird. Bedeutet zu Deutsch: Du nutzt ext4. Abhilfe erreicht man durchs abschalten des Journaling. Dazu musst du den Datenträger des Dateisystems aber aushängen/umounten und das würde bei der SD des PI's bedeuten das du ein anderes Linux-System benötigst, eine VM oder eine LiveCD o.ä... Und dort dann (ohne den Datenträger zu mounten): sudo tune2fs -O ^has_journal <DEVICE> Siehe dazu auch http://wiki.ubuntuusers.de/ext
ntpd mag ich allgemein nicht, aber nur weil ständig/permanent ein Dienst läuft... Ich bevorzuge stattdessen rdate über crontab.. Nichts desto Trotz synchronisiert der Dienst die Systemzeit..

Users Viewing This Thread