• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

/var/log/messages [closed]

Jägerschlürfer

Moderator
Teammitglied
Ich hoffe mein Thema ist hier richtig,... ansonsten bitte entsprechend verschieben.

Und zwar steh ich momentan vor einem kleinen Rätsel bzgl. der messages Datei.

Sobald dieses Datei ja eine gewisse Größe erreicht hat, wird diese ja gepackt und eine neue Datei wird erstellt. Dies ist bei mir nicht mehr der Fall. D.h. ich habe noch eine Sicherungsdatei von Ende Oktober und ansonsten enthält meine messages Datei auch nicht mehr wirklich viele Einträge unterschiedlicher Tage.
Sprich ein Blick heute in die Datei und der letzte Tag der Protokollierung ist von gestern. Gestern war noch der 15.11. in der Datei enthalten, was nun nicht mehr der Fall ist.

Das kann doch nicht normal sein, oder?

edit: betrifft opensuse 11.3
 
OP
Jägerschlürfer

Jägerschlürfer

Moderator
Teammitglied
ich hab ehrlich gesagt noch nie einen Blick in diese Datei geworfen.
daher mal hier die Ausgabe der Datei:

Code:
mathias@linuxplanet:~> cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# comment these to switch compression to use gzip or another
# compression scheme
compresscmd /usr/bin/bzip2
uncompresscmd /usr/bin/bunzip2

# former versions had to have the compressext set accordingly
#compressext .bz2

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
#/var/log/wtmp {
#    monthly
#    create 0664 root utmp
#       minsize 1M
#    rotate 1
#}
#
# /var/log/btmp {
#   missingok
#    monthly
#    create 0600 root utmp
#    rotate 1
#}

# system-specific logs may be also be configured here.
 
A

Anonymous

Gast
gropiuskalle schrieb:
Nö, sieht absolut normal aus. War nur so 'ne Ahnung von mir.
Dort steht das auch nicht drin sondern wenn dann in der /etc/logrotate.d/syslog

mal in die Datei schauen, in der ersten Zeile vor der { stehen immer die Logdateinamen auf die dieser Abschnitt gilt, mal den oder die Abschnitte in denen die messages, steht posten.

robi
 
OP
Jägerschlürfer

Jägerschlürfer

Moderator
Teammitglied
ok, dann hier mal die gewünschte Ausgabe:
Code:
/var/log/warn /var/log/messages /var/log/allmessages /var/log/localmessages /var/log/firewall /var/log/acpid /var/log/NetworkManager {
    compress
    dateext
    maxage 365
    rotate 99
    missingok
    notifempty
    size +4096k
    create 640 root root
    sharedscripts
    postrotate
        /etc/init.d/syslog reload
    endscript
}
 
A

Anonymous

Gast
Das ist der default Eintrag, der ist ok, deine messages soll rotiert werden wenn die größer als 4MB oder älter als ein Jahr ist.
Das reicht mir auf meinen normalen Rechnern meist für ein paar Monate.

Entweder irgendwas müllt dort soviel rein, das alle 2 Tage die 4 MB voll sind, dann solltest du aber bis zu 99 gepackte Kopien haben, oder aus irgend einen Grund wird die Datei ständig neu erstellt, oder mal ganz paranoid gedacht, ist da irgend etwas das dort regenmäßig mal ein "> messages" macht und somit diese Datei leert. Hast du "Marker" in der Datei, dann mal den Zeitverlauf manuell überprüfen. Eventuell mal schauen welchen der 3 möglichen Syslogs du am arbeiten hast, dort würde ich noch am ehesten nach der Ursache suchen. Aber ist von hier aus so nicht einschätzbar was du mit deinem Rechner machst wie oft du bootest und wieviel dort in der Datei bei dir normalerweise an Meldungen ankommt.

Irgend ein Bug oder anderweilige Fehlkonfiguration, ein defektes Filesystem und ähnliches währe durchaus auch noch möglich. Fällt mir aber im Moment nichts dazu ein, was solche Auswirkungen hätte. Ich würde das aber auf alle Falle mal etwas genauer beobachten. wann laufen die cronjobs, wie groß ist die Datei und was ist der erste und letzte Zeitstempel. Nicht das du dort doch einen lieben Untermieter auf dem Rechner hast. Auch mal die anderen Logdateien und die Ausgabe von "last" prüfen.

robi
 
OP
Jägerschlürfer

Jägerschlürfer

Moderator
Teammitglied
kopien werden ja keine erstellt, das ist das komische daran. Bei den anderen log Dateien konnte ich bisher nichts auffälliges beobachten. Die sollten soweit passen. Jedenfalls reichen diese weit zurück.

Einzig was andauernd neu erstellt wird ist die wtmp Datei.

last liefert:
Code:
mathias@linuxplanet:~> last
mathias  pts/2                         Wed Nov 17 23:21   still logged in   
mathias  pts/2                         Wed Nov 17 22:20 - 23:21  (01:01)    
mathias  pts/2                         Wed Nov 17 22:16 - 22:17  (00:00)    
mathias  pts/2                         Wed Nov 17 22:04 - 22:05  (00:01)    
mathias  pts/2                         Wed Nov 17 21:17 - 21:35  (00:18)    
mathias  pts/2                         Wed Nov 17 21:11 - 21:16  (00:05)    
mathias  pts/2                         Wed Nov 17 18:40 - 18:46  (00:05)    
mathias  pts/2                         Wed Nov 17 18:32 - 18:36  (00:04)    
mathias  pts/2                         Wed Nov 17 17:51 - 17:52  (00:00)    
mathias  pts/2                         Wed Nov 17 17:40 - 17:41  (00:01)    
mathias  pts/1                         Wed Nov 17 17:05   still logged in   
mathias  pts/0                         Wed Nov 17 17:05   still logged in   
mathias  :0           console          Wed Nov 17 17:04   still logged in   
reboot   system boot  2.6.34.7-0.5-def Wed Nov 17 17:03 - 23:21  (06:18)    

wtmp begins Tue Nov 16 23:23:58 2010

ich hab auch mal die letzte Sicherung der var/log/messages angeschaut. Der letzte Eintrag lautet:
Code:
rsyslogd: [origin software="rsyslogd" swVersion="5.4.0" x-pid="1727" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
wenn ich danach in google suche, scheint das wohl irgend ein Bug zu sein, jedoch werde ich daraus nicht wirklich schlau,...
 
A

Anonymous

Gast
Eine abgeschlossene messages Logdatei sollte am Ende bzw die neue am Anfang typescherweise schon "rsyslogd was HUPed" haben. Das bedeutet hier wurde der Syslog neu durchgestartet damit die offenen Dateien die jetzt andere Namen haben könnten jetzt geschlossen werden und dafür gegebenenefalls neue Dateien angelegt werden. Wenn das aber bei deiner aktuellen Datei allerdings auch der Fall sein sollte, das dieses immer der letzte Eintrag ist, dann würde diese Meldung wohl schon andeuten, das hier regelmäßig zB bei dem logrotate Jobs anschließend der rsyslog nicht mehr sauber nach gestartet werden kann und desshalb keine Einträge nach messages mehr gemacht werden, Das könnte dann ein ähnlicher Fehler sein, wie dieser hier den du wahrscheinlich auch gefunden hast. Das würde auch zu deinen Beobachtungen passen. Aber bei Suse wird das Ganze eigentlich ganz anders gehändelt, zumindestens kann es nicht genau der selbe Fehler sein.

Ich hab jetzt kein 11.3 hier, such mal ob es da eine neuere/andere Version oder eine Update für rsyslog gibt. Jedenfalls sind dort auf den Projektseiten von rsyslog schon einige neuere Versionen zu finden, so dass Suse da eigentlich schon was gepatcht haben dürfte/sollte, wenn dort wirklich was an dieser Stelle nicht passt, das sollte recht schnell aufgefallen sein. Ansonsten wenn du auf die Logs angewiesen bist schau mal ob bei 11.3 noch der alte syslogd als Paket erhältlich ist, dann nimm den und schmeiß den rsyslog runter.

robi
 
OP
Jägerschlürfer

Jägerschlürfer

Moderator
Teammitglied
ich schau mir das heute abend nochmal an.
Allerdings werden bei mir ja Einträge gemacht. Allerdings sind immer nur die letzten Tage zu sehen.

Obs ein Update gibt schaue ich heute auch mal.
 
Jägerschlürfer schrieb:
Allerdings werden bei mir ja Einträge gemacht.
Obs ein Update gibt schaue ich heute auch mal.
Laut Update-Repository gibt es so etwas nicht, openSUSE 11.3 verwendet die vorletzte stabile Version 5.4.0 (die neue stabile Version 5.6.0 gibt es erst seit einem Monat). Wenn ein Ersatz durch syslog-ng (oder syslogd) das Problem nicht löst, dann drängt sich mir der Gedanke auf, daß doch etwas in der Art von
robi schrieb:
mal ein "> messages" macht
am Werk sein könnte.
 
OP
Jägerschlürfer

Jägerschlürfer

Moderator
Teammitglied
robi schrieb:
ist da irgend etwas das dort regenmäßig mal ein "> messages" macht und somit diese Datei leert. Hast du "Marker" in der Datei, dann mal den Zeitverlauf manuell überprüfen.
wie kann ich das denn prüfen?

Ich werd mir später, wenn ich daheim bin, die Datei noch mal genauer anschauen,... Evtl finde ich noch was auffälliges.
Übers We versuch ich auch mal zu schauen, wann die Datei denn gekürzt wird. Also ob das beim Herunterfahren ist, oder beim Neustarten.
 
Jägerschlürfer schrieb:
wann die Datei denn gekürzt wird. Also ob das beim Herunterfahren ist, oder beim Neustarten.
Wenn ich mir
Jägerschlürfer schrieb:
Sprich ein Blick heute in die Datei und der letzte Tag der Protokollierung ist von gestern. Gestern war noch der 15.11. in der Datei enthalten, was nun nicht mehr der Fall ist.
vor Augen halte, ist weder das eine noch das andere der Fall. syslog-ng schreibt die letzte Zeile vor dem Herunterfahren und die erste Zeile nach dem Systemstart, ich vermute, rsyslog wird ähnlich agieren. Mir sieht es danach aus, daß im laufenden Betrieb die Datei "vergessen" und neu begonnen wird. Mit welcher Eintragung beginnt Deine Datei? Vielleicht ist das ein Anhaltspunkt zur Ausforschung des Übeltäters.
 
OP
Jägerschlürfer

Jägerschlürfer

Moderator
Teammitglied
so, ich hab eben mal die Datei nochmals angeschaut mittels cat /var/log/messages auf der Konsole und hier war der erste Eintrag einer vom 16.11. Aber jetzt nicht einer seit dem Bootvorgang, sondern ein Eintrag der während dem laufenden Betrieb eingetragen wurde.

Also sehr sehr komisch,....

Aber wie sag ich das jetzt nur,... ich denke ich habe den Fehler gefunden.
Wenn ich mir die Datei mittels dolphin in kwrite anschaue, sehe ich alle Enträge seit Oktober. Es scheint also so zu sein, dass mir die Datei einfach nicht komplett angezeigt wird in der Konsole. Sprich nach einer gewissen Zeilenanzahl ist Schluss.
Somit ist also meine Datei komplett und nicht wie von mir angenommen nicht komplett.

Einen fragwürdigen Eintrag habe ich aber noch gefunden, was aber bestimmt was ganz normales ist.
Und zwar hab ich eben ein Update gefahren und danach hab ich mir die messages nochmal angeschaut und fand folgende Angaben:
Code:
Nov 18 19:03:01 linuxplanet polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session1 successfully authenticated as unix-user:root to gain TEMPORARY authorization for action org.freedesktop.packagekit.system-update for system-bus-name::1.41 [/usr/bin/kupdateapplet] (owned by unix-user:mathias)
Nov 18 19:03:15 linuxplanet shadow[6820]: default group changed - account=nobody, uid=65534, gid=65533, old gid=65533, by=0
Was mir hier auffällt ist der Eintrag mit dem Shadow und default group changed. Ist das denn normal?
Einen ähnlichen Eintrag bekomme ich, wenn ich z.B. yast starte, in die Benutzerverwaltung gehe und mir hier die Authentifizierungseinstellungen anzeige lasse. Hier lautet der Eintrag in der messages dann
Code:
Nov 18 19:37:46 linuxplanet su: (to root) mathias on /dev/pts/5
Nov 18 19:37:47 linuxplanet su: (to root) mathias on /dev/pts/5
Nov 18 19:38:39 linuxplanet su: (to nobody) root on none
kann mir dieses Verhalten jemand bestätigen? Sind die Einträge bedeutungslos?
 
Jägerschlürfer schrieb:
Es scheint also so zu sein, dass mir die Datei einfach nicht komplett angezeigt wird in der Konsole. Sprich nach einer gewissen Zeilenanzahl ist Schluss.
Das ist klar, der sogenannte "Verlaufsspeicher" ist standardmäßig mit 1000 Zeilen (wenn eine Zeile in der Datei zu lang ist und daher auf 2 Zeilen aufgeteilt wird, sind es für die Zählung auch 2 Zeilen) festgelegt, kann aber unter "Einstellungen" angepaßt werden. (Auf die Idee, sich diese Datei in der Konsole anzuschauen, bin ich noch nicht gekommen.)

Jägerschlürfer schrieb:
Nov 18 19:37:46 linuxplanet su: (to root) mathias on /dev/pts/5
Jeder "Benutzerwechsel" mit su wird protokolliert.

Zu /usr/bin/kupdateapplet kann ich nichts sagen, da das Ding bei mir nicht läuft. nobody wird verwendet, wenn nur ein Minimum an Rechten vorhanden zu sein braucht, mit mehr Informationen kann ich nicht dienen.
 
OP
Jägerschlürfer

Jägerschlürfer

Moderator
Teammitglied
mir gings eher um das nobody. Dass protokolliert wird, wenn man zu root wird, is mir bekannt. Nur das mit nobody wusste ich nicht.

Aber dass es normal zu sein scheint, beruhigt mich doch sehr.
 
Oben