[solved] man-page: cache veraltet? updaten?

[ingo2]

Ich habe beim Backup mit rsync folgendes beobachtet:

Vor dem Backup des gesamten Systems ermiitle ich von allen Dateien die md5sum.

Wenn ich dann das Backup mit den Optionen

Code: Alles auswählen

rsync -aP   

mache und anschließend über die md5sum verifiziere, stellte sich heraus das 5 Dateien mit dem Namen index.db eine falsche md5sum hatten, also nicht übertragen wurden. Das ist seitens rsync absolut korrekt - mit dem Parameter "-a" wird nur Dateigrße und Timestamp (m-time) überprüft, die sind aber identisch (mit der Option -c geht es natürlich). Meine Frage ist jetzt aber:

Wie kann es sein, daß überhaupt die Index-Dateien im man-cache verändert sind, obwohl das m-date identisch ist - darein schreiben macht ja nur das System?

Hier mal der Inhalt vom "Original" unter /usr/share/man.de

Code: Alles auswählen

ls -l /usr/share/man/de
insgesamt 144
drwxr-xr-x 2 root root 45056  8. Jan 16:58 man1
drwxr-xr-x 2 root root  4096 11. Okt 11:44 man2
drwxr-xr-x 2 root root  4096 11. Okt 11:58 man3
drwxr-xr-x 2 root root  4096 11. Okt 11:44 man4
drwxr-xr-x 2 root root 20480 11. Okt 11:45 man5
drwxr-xr-x 2 root root  4096 11. Okt 11:44 man6
drwxr-xr-x 2 root root 20480 11. Okt 11:45 man7
drwxr-xr-x 2 root root 36864 11. Okt 11:45 man8

und hier der Cache:

Code: Alles auswählen

ls -l /var/cache/man/de
insgesamt 244
-rw-r--r-- 1 man man    190 18. Jun 2017  CACHEDIR.TAG
drwxr-xr-x 2 man man   4096 17. Mai 2018  cat1
drwxr-xr-x 2 man man   4096 18. Jun 2017  cat2
drwxr-xr-x 2 man man   4096 18. Jun 2017  cat3
drwxr-xr-x 2 man man   4096 18. Jun 2017  cat4
drwxr-xr-x 2 man man   4096 18. Jun 2017  cat5
drwxr-xr-x 2 man man   4096 18. Jun 2017  cat6
drwxr-xr-x 2 man man   4096 18. Jun 2017  cat7
drwxr-xr-x 2 man man   4096 22. Mai 2018  cat8
-rw-r--r-- 1 man man 212992  8. Jan 16:58 index.db

Ode ist da evtl. ein Bit auf der SSD gekippt?

Den ganzen Cache unter /var/cache/man zu löschen, traue ich mich nicht, obwohl hier https://refspecs.linuxfoundation.org/FH ... 05s05.html steht:

Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories.

Gruß, Ingo

[eggy]

Den ganzen Cache unter /var/cache/man zu löschen, traue ich mich nicht,

mandb sagt

-c, --create
Standardmäßig versucht mandb zunächst, eine bestehende Datenbank zu aktualisieren. Ist keine Datenbank vorhanden, wird sie erstellt. Diese Option zwingt mandb dazu, die Datenbank von Grund auf neu zu erstellen und impliziert --no-purge. Dieses kann notwendig sein, wenn eine Datenbank beschädigt oder das Datenbank-Schema geändert wird.

ka, ob das schon ausreicht.
Man könnte die Dateien erstmal nur beiseite schieben und das einfach mal ausprobieren, falls Dir das zu heikel ist: benutz ne VM.

[MSfree]

Wie kann es sein, daß überhaupt die Index-Dateien im man-cache verändert sind, obwohl das m-date identisch ist - darein schreiben macht ja nur das System?

Alle Manpages liegen in /usr/share/man. Dort sind sie allerdings troff-formatiert, komprimiert und nicht direkt anzeigbar, weil sie diverse Steuersymbole für Fettdruck, erzwungene Zeilenumbrüce etc. beinhalten. Der Aufruf von man <Irgendwas> lliest die troff-Datei von "irgendwas" und formatiert sie für das Terminal. Gleichzeitig wird die umformatierte Manpage in /var/cache/man gespeichert. Wird man <Irgendwas> erneut aufgerufen, wird nicht die troff-Seite erneut formatiert sondern der Inahlt aus dem Cache bezogen. (Vor 30 Jahren hat man damit den Anzeigeprozeß auf den damals üblichen 25MHz Single-Core CPUs erheblich beschleunigt, auf heutigen Mutlicore-CPUs mit mehreren Gigahertz Takt spielt das eigentlich gar keine Rolle mehr.)

Der Index liefert die Ergebnisse für den apropos-Befehl, der eine Textsuche über alle Manpages ermöglicht.

Wenn also der Inhalt von /var/cache/man gelöscht wird, wird er ganz einfach neu ausgebaut. Es besteht also überhaupt kein Grund, Angst davor zu haben, diese Verzeichnisse zu löschen. Andererseits frage ich mich aber, was du damit erreichen willst. Der belegte Plattenplatz liegt im Bereich einiger Megabyte, fällt also gar nicht weiter auf .

Wenn es dir um das Backup mit rsync geht, solltest du es vielleicht mit --exclude /var/cache/man ganz vom Backup ausschließen, weil diese Daten ohnehin regenerierbar und somit redundant sind.

Den Grund, warum die index.db sich während des rsyncs geändert hat, könnte daran liegen, daß du nach der Erzeugung der Prüfsummen eine Manpage aufgerufen hast, die noch nicht im Cache lag, das würde dann auch den index verändern und die Prüfsumme ungültig machen.

[ingo2]

Man könnte die Dateien erstmal nur beiseite schieben und das einfach mal ausprobieren, falls Dir das zu heikel ist: benutz ne VM.

So, hab' es erst mal in einer VM getestet:

Code: Alles auswählen

rm -rf /var/cache/man/*

und dann:

Code: Alles auswählen

mandb -c

Läuft glatt durch und nach 1 Minute war der gesamte Cache neu aufgebaut.
Und alle Dateien und Verzeichnisse haben jetzt den aktuellen Timestamp!
Der Inhalt ist dabei von vorher 2,5MB auf 2,4MB geschrumpft, war also eigentlich noch voll in Ordnung.

Das ist die Lösung des Problems - Danke. Aber wieso vorher beim rsync-Backup die index.db trotz gleicher Dateigröße und gleichem Timestamp zu unterschiedlichen Hashes (md5sum) kommen, bleibt mir ein Rätsel.
Anmerkung:
ich hatte es vorher durch ein einfaches "touch" auf die betroffene(n) Datei/en) gelöst. Das betrifft u.a. auch Firefox, der hatte einzelne *.js Dateien ohne Timestamp, bzw. 1. Jan. 1970.

@MSfree
Danke für die Background-Info zum "man-cache"
Noch zur Info: das Backup des kompletten Systems mit rsync mache ich natürlich von einem Service-System aus, d.h. da ändern sich keine Daten während des Backups.

Ingo