staging.inyokaproject.org

UlfZibis schrieb:

von.wert schrieb:

Da wäre ja glattweg mal die Ausgabe hier sinnvoll gewesen.

Siehe 9278227

Dort steht nicht diese Befehlszeile mit zugehöriger Ausgabe.

von.wert schrieb:

Siehe 9278227

Dort steht nicht diese Befehlszeile mit zugehöriger Ausgabe.

Ich bin jetzt irritiert. Du meinst doch die Ausgabe von systemctl --user status tracker*. Genau die steht da in dem ersten mehrzeiligen Code-Block.

Ich bin jetzt am überlegen, ob ich mit gsettings reset-recursively org.freedesktop.Tracker mal aller Einstellungen auf default setzten soll. Ich habe aber Bedenken, dass dadurch alle erfasst werden, denn wie man hier sieht :

$ gsettings list-recursively org.freedesktop.Tracker
org.freedesktop.Tracker.Store graphupdated-delay 1000
org.freedesktop.Tracker.Store verbosity 'errors'
org.freedesktop.Tracker.DB journal-rotate-destination ''
org.freedesktop.Tracker.DB journal-chunk-size 50
org.freedesktop.Tracker.FTS ignore-numbers true
org.freedesktop.Tracker.FTS max-words-to-index 10000
org.freedesktop.Tracker.FTS ignore-stop-words true
org.freedesktop.Tracker.FTS enable-unaccent true
org.freedesktop.Tracker.FTS enable-stemmer false
org.freedesktop.Tracker.FTS max-word-length 30

geht die Rekursion nur in eine Ebene höher, und nicht in alle. Es gibt aber noch tiefere Ebenen, wie man hier sieht:

 gsettings list-recursively | grep -i org.freedesktop.Tracker | sort | uniq
org.freedesktop.Tracker.DB journal-chunk-size 50
org.freedesktop.Tracker.DB journal-rotate-destination ''
org.freedesktop.Tracker.Extract max-bytes 1048576
org.freedesktop.Tracker.Extract sched-idle 'first-index'
org.freedesktop.Tracker.Extract verbosity 'errors'
org.freedesktop.Tracker.Extract wait-for-miner-fs false
org.freedesktop.Tracker.FTS enable-stemmer false
org.freedesktop.Tracker.FTS enable-unaccent true
org.freedesktop.Tracker.FTS ignore-numbers true
org.freedesktop.Tracker.FTS ignore-stop-words true
org.freedesktop.Tracker.FTS max-word-length 30
org.freedesktop.Tracker.FTS max-words-to-index 10000
org.freedesktop.Tracker.Miner.Files crawling-interval -1
org.freedesktop.Tracker.Miner.Files enable-monitors true
org.freedesktop.Tracker.Miner.Files enable-writeback true
org.freedesktop.Tracker.Miner.Files ignored-directories ['po', 'CVS', 'core-dumps', 'lost+found']
org.freedesktop.Tracker.Miner.Files ignored-directories-with-content ['.trackerignore', '.git', '.hg', '.nomedia']
org.freedesktop.Tracker.Miner.Files ignored-files ['*~', '*.o', '*.la', '*.lo', '*.loT', '*.in', '*.csproj', '*.m4', '*.rej', '*.gmo', '*.orig', '*.pc', '*.omf', '*.aux', '*.tmp', '*.vmdk', '*.vm*', '*.nvram', '*.part', '*.rcore', '*.lzo', 'autom4te', 'conftest', 'confstat', 'Makefile', 'SCCS', 'ltmain.sh', 'libtool', 'config.status', 'confdefs.h', 'configure', '#*#', '~$*.doc?', '~$*.dot?', '~$*.xls?', '~$*.xlt?', '~$*.xlam', '~$*.ppt?', '~$*.pot?', '~$*.ppam', '~$*.ppsm', '~$*.ppsx', '~$*.vsd?', '~$*.vss?', '~$*.vst?', 'mimeapps.list', 'mimeinfo.cache', 'gnome-mimeapps.list', 'kde-mimeapps.list', '*.directory']
org.freedesktop.Tracker.Miner.Files index-on-battery-first-time true
org.freedesktop.Tracker.Miner.Files index-on-battery true
org.freedesktop.Tracker.Miner.Files index-optical-discs false
org.freedesktop.Tracker.Miner.Files index-recursive-directories ['&DESKTOP', '&DOCUMENTS', '&MUSIC', '&PICTURES', '&VIDEOS']
org.freedesktop.Tracker.Miner.Files index-removable-devices false
org.freedesktop.Tracker.Miner.Files index-single-directories ['$HOME', '&DOWNLOAD']
org.freedesktop.Tracker.Miner.Files initial-sleep 15
org.freedesktop.Tracker.Miner.Files low-disk-space-limit -1
org.freedesktop.Tracker.Miner.Files removable-days-threshold 3
org.freedesktop.Tracker.Miner.Files sched-idle 'first-index'
org.freedesktop.Tracker.Miner.Files throttle 0
org.freedesktop.Tracker.Miner.Files verbosity 'errors'
org.freedesktop.Tracker.Store graphupdated-delay 1000
org.freedesktop.Tracker.Store verbosity 'errors'
org.freedesktop.Tracker.Writeback verbosity 'errors'

Also die Frage ist, wie ich alle Einstellungen bis in die letzte Tiefe auf default zurücksetzen kann, bzw., wie ich feststellen kann, welche Werte auf default gesetzt sind, und welche nicht.

Ich hab' jetzt mal folgendes gemacht:

$ sudo apt --purge --reinstall install tracker tracker-miner-fs tracker-extract

Nach dem Neustart:

$ systemctl --user status tracker*
● tracker-extract.service - Tracker metadata extractor
     Loaded: loaded (/usr/lib/systemd/user/tracker-extract.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-10-06 18:26:09 CEST; 29min ago
   Main PID: 1203 (tracker-extract)
     CGroup: /user.slice/user-1000.slice/user@1000.service/tracker-extract.service
             └─1203 /usr/libexec/tracker-extract

Okt 06 18:26:09 T540p systemd[1196]: Starting Tracker metadata extractor...
Okt 06 18:26:09 T540p tracker-extract[1203]: Set scheduler policy to SCHED_IDLE
Okt 06 18:26:09 T540p tracker-extract[1203]: Setting priority nice level to 19
Okt 06 18:26:09 T540p tracker-extract[1203]: Could not create notifier: no such table: Resource
Okt 06 18:26:09 T540p tracker-extract[1203]: invalid (NULL) pointer instance
Okt 06 18:26:09 T540p tracker-extract[1203]: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance>
Okt 06 18:26:09 T540p tracker-extract[1203]: Could not create notifier: no such table: Resource
Okt 06 18:26:09 T540p tracker-extract[1203]: invalid (NULL) pointer instance
Okt 06 18:26:09 T540p tracker-extract[1203]: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance>
Okt 06 18:26:09 T540p systemd[1196]: Started Tracker metadata extractor.

● tracker-miner-fs.service - Tracker file system data miner
     Loaded: loaded (/usr/lib/systemd/user/tracker-miner-fs.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-10-06 18:26:10 CEST; 29min ago
   Main PID: 1204 (tracker-miner-f)
     CGroup: /user.slice/user-1000.slice/user@1000.service/tracker-miner-fs.service

Es scheint so, dass der tracker-store.service nun nicht mehr aktiv ist. Der Befehl systemctl --user disable --now tracker-store.service hat also auch nach dem Neustart noch Auswirkung. Jetzt fragt sich nur, ob ich ihn wieder anwerfen sollte, für irgendwas muss er ja gut sein.

Ich bekomme jedenfalls:

$ systemctl --user enable --now tracker-store.service
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Jetzt nach 20 Min. ist es noch ruhig in ~/.cache/tracker/, also nur 77.9 MB in 9 Dateien werden verbraucht. Das sieht ja gut aus.

Der Befehl tracker reset -c gibt aber immer noch den CRITICAL-Fehler aus.

Jetzt nach einem weiteren Neustart ist der tracker-store.service wegen systemctl --user enable --now tracker-store.service wieder aktiv und es geht wieder los mit dem "Wachstun ins Unendliche".

Dann weiß ich ja jetzt, was ich zu tun habe:

systemctl --user disable --now tracker-store.service
tracker reset -r

alles in ~/.cache/tracker/ löschen und Neustart.

Jau, das klappt.

Dennoch würde mich interessieren, welche Funktion, Bedeutung und Nutzen der tracker-store.service hat ... und evtl. auch der tracker-extract.service.

Auf meinem eigenen Rechner, wo ich noch nie was an diesen Einstellungen geschraubt habe, läuft nur der tracker-miner-fs.service Der tracker-extract.service scheint also auch nicht so wichtig zu sein.

Und insgesamt bin ich dann mal gespannt, ob auf dem Rechner meiner Tochter hier MS Teams den 3. fatalen Dienst demnächst wieder startet. Dann hätten wir den Übeltäter.

Jetzt hat sich doch nach ein paar Stunden der tracker-store.service wieder eingeschaltet. Und ~/.cache/tracker/ ist wieder randvoll. Dafür ist aber merkwürdigerweise der tracker-extract.service untergetaucht:

$ systemctl --user status tracker*
● tracker-miner-fs.service - Tracker file system data miner
     Loaded: loaded (/usr/lib/systemd/user/tracker-miner-fs.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-10-06 23:41:12 CEST; 2h 3min ago
   Main PID: 1195 (tracker-miner-f)
     CGroup: /user.slice/user-1000.slice/user@1000.service/tracker-miner-fs.service
             └─1195 /usr/libexec/tracker-miner-fs

Okt 06 23:41:11 T540p systemd[1186]: Starting Tracker file system data miner...
Okt 06 23:41:11 T540p tracker-miner-f[1195]: Set scheduler policy to SCHED_IDLE
Okt 06 23:41:11 T540p tracker-miner-f[1195]: Setting priority nice level to 19
Okt 06 23:41:12 T540p systemd[1186]: Started Tracker file system data miner.

● tracker-store.service - Tracker metadata database store and lookup manager
     Loaded: loaded (/usr/lib/systemd/user/tracker-store.service; static; vendor preset: enabled)
     Active: active (running) since Wed 2021-10-06 23:41:12 CEST; 2h 3min ago
   Main PID: 1386 (tracker-store)
     CGroup: /user.slice/user-1000.slice/user@1000.service/tracker-store.service
             └─1386 /usr/libexec/tracker-store

Okt 07 01:41:52 T540p tracker-store[1386]: Could not delete FTS text: database or disk is full (strerror of errno (not >
Okt 07 01:41:52 T540p tracker-store[1386]: Could not insert FTS text: database or disk is full (strerror of errno (not >
Okt 07 01:41:52 T540p tracker-store[1386]: Could not insert FTS text: database or disk is full (strerror of errno (not >
Okt 07 01:41:52 T540p tracker-store[1386]: Could not insert FTS text: database or disk is full (strerror of errno (not >

So ein Mist !!! Es ist zum Verzweifeln. Was mache ich bloß?

Hilft das?

https://wiki.gnome.org/Projects/Tracker/Documentation/GettingStarted#Data_.26_Logging

Knarf68 schrieb:

Hilft das?

https://wiki.gnome.org/Projects/Tracker/Documentation/GettingStarted#Data_.26_Logging

Nicht wirklich, aber danke für den Link zur Doku.

Tja, der Tracker ist echt unberechenbar. Mal kollabiert er schon kurz nach dem Start, mal bleibt alles gemäßigt über 12 Stunden lang.

Es scheint, dass er ein riesiges /home voraussetzt. Wenn ich ihn nach tracker reset -r und tracker daemon -s mit tracker daemon -f beobachte, kommt er auf ca. 95 % Fortschritt, bevor die zur Verfügung stehenden 4,6 GB verbraucht sind. Bei ca. 45 GB in /home und Datenpartition (größtenteils Fotos) finde ich das eine Menge Holz. Auf meinem eigenen Rechner verbraucht Tracker gerade mal 80 MB bei 200 GB Daten. Sehr merkwürdig.

Bei der Interpretation von org.freedesktop.Tracker.Miner.Files.low-disk-space-limit machte ich bisher einen Denkfehler. Ich dachte, mit -1 würde die ganze Indexierung deaktiviert, aber nein, ganz im Gegenteil, die Überwachung des Speicherplatzes wird deaktiviert.

Also hab' ich den Wert mal auf 20 % eingestellt. doch auch das nützt nichts, denn es zeigt sich, dass das nur den tracker-miner-fs.service pausiert. Da der aber zuerst durchläuft, hat er noch genug Platz, aber dann setzt tracker-extract.service ein, und der rennt durch bis der ganze Platz auf /home verbraucht ist. Ich vermute mal, dass der erst mal Daten sammelt, und diese dann erst danach analysiert und von tracker-store.service komprimiert in die Datenbank gepackt werden. Doch dazu kommt es eben nicht mehr.

Leider habe ich bisher noch keine Möglichkeit gefunden, dem Tracker beizubringen, das Dateisystem nur häppchenweise zu durchsuchen, zu analysieren und dann komprimiert die Indexe abzuspeichern. Vielleicht hat jemand ja eine Idee dazu.

UlfZibis schrieb:

T[…] Es scheint, dass er ein riesiges /home voraussetzt.

Er setzt voraus, dass derjenige, welcher von ihm die Erzeugung eines Indexes über viele Dateien erwartet, ihm auch einen ausreichend großen Speicherplatz für diesen Index zur Verfügung stellt. Ein Spezialfell der allgemein gültigen Erkenntnis: Zur erfolgreichen Erledigung einer Aufgabe müssen die benötigten Arbeitsmittel verfügbar sein.

Wenn ich ihn nach tracker reset -r und tracker daemon -s mit tracker daemon -f beobachte, kommt er auf ca. 95 % Fortschritt, bevor die zur Verfügung stehenden 4,6 GB verbraucht sind. Bei ca. 45 GB in /home und Datenpartition (größtenteils Fotos) finde ich das eine Menge Holz. Auf meinem eigenen Rechner verbraucht Tracker gerade mal 80 MB bei 200 GB Daten. Sehr merkwürdig.

Daran ist gar nichts merkwürdig. Tracker schürft Metadaten aus den von ihm untersuchten Dateien. Dabei kommt es weniger auf die Größe des Datenbestandes, sondern eher auf die Anzahl der Dateien an, weil jede Datei ja im Index/der Datenbank Speicherplatz für ihre Metadaten benötigt. Lediglich bei der Volltextsuche in Textdokumenten spielt zusätzlich auch die Dateigröße (eigentlich der Umfang des Textes) eine Rolle.

Du hast diese Möglichkeiten:

1. Tracker gar nicht benutzen.

2. Tracker zwar benutzen, aber seinen Suchbereich einschränken. Das kann durch Auswahl der zu durchsuchenden Ordner oder durch Beschränkung der Dateiart geschehen, z.B. kann man auf die Volltextsuche in Textdokumenten verzichten. Das hängt natürlich von der individuellen Aufgabenstellung ab.

3. Einfach genügend freien Speicherplatz zur Verfügung stellen.

Entscheide Dich bitte für eine Vorgehensweise, welche Deinen Bedürfnissen entspricht und setze diese um. Wenn dabei Probleme entstehen, stelle konkrete Fragen. Jammern über erklärbares Verhalten eines Programms hilft dagegen nicht.

kB schrieb:

Er setzt voraus, dass derjenige, welcher von ihm die Erzeugung eines Indexes über viele Dateien erwartet, ihm auch einen ausreichend großen Speicherplatz für diesen Index zur Verfügung stellt. Ein Spezialfell der allgemein gültigen Erkenntnis: Zur erfolgreichen Erledigung einer Aufgabe müssen die benötigten Arbeitsmittel verfügbar sein.

Wenn ein Indexer an die 20 % des Speicherplatzes der Daten, die er indizieren soll, braucht, bewerte ich das als unangemessen viel, also riesig. Immerhin stehen ihm 12 % zur Verfügung, doch damit kommt er hier nicht aus.

Daran ist gar nichts merkwürdig. Tracker schürft Metadaten aus den von ihm untersuchten Dateien. Dabei kommt es weniger auf die Größe des Datenbestandes, sondern eher auf die Anzahl der Dateien an, weil jede Datei ja im Index/der Datenbank Speicherplatz für ihre Metadaten benötigt.

Werden wir mal Konkret. Es geht hier um ca. 50.000 Dateien, davon ca. 16.000 Bilder und ca. 8.000 epub-Dateien. Die Dateinamen inkl. Pfad sind durchschnittlich 50 Zeichen lang. Das wären dann ca. 2,5 MB im Index für die Dateinamen. Dann kämen noch Metadaten dazu. Für beides sollten dann doch 4,6 GB Platz ausreichen. Aus welchem Grund sollte man das anders sehen?

Lediglich bei der Volltextsuche in Textdokumenten spielt zusätzlich auch die Dateigröße (eigentlich der Umfang des Textes) eine Rolle.

Genau. Da könnten z.B. die epub-Dateien eine Rolle spielen, sie umfassen ca. 7,5 GB. Wenn der Tracker tatsächlich so dämlich programmiert ist, dass er diese Menge erst mal in seine Datenbank kopiert, bevor er sie auf Tags untersucht, wäre das eine Erklärung, warum er mit 4,6 GB nicht auskommt. Deshalb fände ich es ja hilfreich, wenn man dem Tracker beibringen könnte, den Datenbestand häppchenweise zu untersuchen. Dass die epub-Dateien DRM-verschlüsselt sind, scheint ihn auch nicht zu interessieren, denn mit den ausgelesenen Bytes kann er eh nichts anfangen.
Ich werde beim nächsten Start unter org.freedesktop.tracker.miner.files.ignored-files mal *.epub ergänzen. Schaun wir mal.

Du hast diese Möglichkeiten:

1. Tracker gar nicht benutzen.

Das wüsste ich ja gerne, wie das geht, außer mit dieser Holzhammer-Methode.

1. Tracker zwar benutzen, aber seinen Suchbereich einschränken. Das kann durch Auswahl der zu durchsuchenden Ordner oder durch Beschränkung der Dateiart geschehen,

Unter Einstellungen->Suche->Orte habe ich bereits "Bilder" deaktiviert. Das scheint ihn aber nicht zu interessieren, denn wie man mittels tracker info * feststellen kann, wird der Ordner dennoch durchsucht.

z.B. kann man auf die Volltextsuche in Textdokumenten verzichten. Das hängt natürlich von der individuellen Aufgabenstellung ab.

Wo hast Du denn diese Einstellung gefunden?

1. Einfach genügend freien Speicherplatz zur Verfügung stellen.

Wieviel wäre das denn für 50.000 Dateien mit 45 GB Volumen?

Installiere das eben in einer VM erstellte Dummy-Package! Da ist nichts drin von dafür nötigen Textdateien abgesehen. Keine Abhängigkeiten. Danach beendest Du den Daemon und kannst "/usr/bin/tracker" einfach umbenennen. Quick & dirty (über das Originalpaket installierte Pakete bleiben erhalten, könntest Du jetzt aber auch deinstallieren).

Die Version ist absichtlich hoch gesetzt, damit nicht so schnell ein echtes Update ersetzen kann.

UlfZibis schrieb:

Genau. Da könnten z.B. die epub-Dateien eine Rolle spielen, sie umfassen ca. 7,5 GB. Wenn der Tracker tatsächlich so dämlich programmiert ist, dass er diese Menge erst mal in seine Datenbank kopiert, bevor er sie auf Tags untersucht, wäre das eine Erklärung, warum er mit 4,6 GB nicht auskommt. Deshalb fände ich es ja hilfreich, wenn man dem Tracker beibringen könnte, den Datenbestand häppchenweise zu untersuchen. Dass die epub-Dateien DRM-verschlüsselt sind, scheint ihn auch nicht zu interessieren, denn mit den ausgelesenen Bytes kann er eh nichts anfangen.

Es liegt tatsächlich an den epub-Dateien. Ich habe mal einen Teil davon ausgelagert, sodass noch 3,6 GB übrig blieben. Um die zu indizieren, hat der Tracker 1,8 GB verbraucht.

Ich werde beim nächsten Start unter org.freedesktop.tracker.miner.files.ignored-files mal *.epub ergänzen. Schaun wir mal.

Und wenn ich das mache, dann wird der Index nur noch ca. 70 MB groß.

kB schrieb:

Entscheide Dich bitte für eine Vorgehensweise, welche Deinen Bedürfnissen entspricht und setze diese um. Wenn dabei Probleme entstehen, stelle konkrete Fragen. Jammern über erklärbares Verhalten eines Programms hilft dagegen nicht.

Ein paar Fragen sind nun tatsächlich noch offen, siehe meinen letzten Post.

von.wert schrieb:

Installiere das eben in einer VM erstellte Dummy-Package! Da ist nichts drin von dafür nötigen Textdateien abgesehen. Keine Abhängigkeiten. Danach beendest Du den Daemon und kannst "/usr/bin/tracker" einfach umbenennen. Quick & dirty (über das Originalpaket installierte Pakete bleiben erhalten, könntest Du jetzt aber auch deinstallieren).

Die Version ist absichtlich hoch gesetzt, damit nicht so schnell ein echtes Update ersetzen kann.

Noch eine interessante Art an Holzhammer-Methode. Wie Du siehst, brauche ich sie aber nicht mehr. Danke, dass Du Dir die Mühe gemacht hast.

Ich hab' mal einen Fehler gemeldet.

Kommentare und "affects me" dort sind erwünscht.