Bug 1492858
| Summary: | The whole log is full of messages "tracker-store[5035]: Could not insert FTS text: constraint failed" and tracker-store process continue consume 100% CPU | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mikhail <mikhail.v.gavrilov> | ||||
| Component: | tracker | Assignee: | Igor Raits <igor.raits> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 28 | CC: | amigadave, awilliam, dakingun, debarshir, eb30750, igor.raits, kparal, mikhail.v.gavrilov, next.little.owl, robatino | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | RejectedBlocker | ||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-05-28 23:27:28 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Mikhail
2017-09-18 18:44:31 UTC
This began happens after fixing this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1488707 Proposed as a Blocker and Freeze Exception for 27-beta by Fedora user mikhail using the blocker tracking app because: Because whole log is full of messages "tracker-store[5035]: Could not insert FTS text: constraint failed" this makes it difficult to view logs. And some performance degradation because one of CPU core 100% loaded with tracker-store process. Mikhail, not everything that is broken on your system is a good candidate for a release blocker. Have you seen this occur on a different system as well? Or a cleanly installed F27 perhaps? Have you tried this under a different user account? Have you tried to figure out which files cause this failure? We need more information when deciding whether something is a blocker or not. Also, you're not providing enough information for debugging. Rpm package versions of affected software is missing. A full journal from a clean boot while only reproducing this issue would be beneficial. Try to find out how to enable debug logging for tracker and attach that. Try not to muddle the report with unimportant information, like reprinting licensing terms in program output. When you say "consumes 100% CPU", you need to add how long you've left it running. Maybe the CPU usage goes away after a minute or two. When proposing a blocker, please try to go through the release criteria and tell us which criterion you believe this violates. Thanks. Discussed during blocker review [1]: RejectedBlocker (beta) - This lacks any proper details and seems to be related to a single setup with particular files. Please re-propose if it affects multiple people and has serious consequences. unproposing as FE because there's no sign of a fix coming yet [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-25/ Created attachment 1331222 [details]
full system log
verbosity debug for tracker:
systemd[1561]: Starting Tracker metadata database store and lookup manager...
tracker-store[28869]: Starting tracker-store 2.0.0
tracker-store[28869]: General options:
tracker-store[28869]: Verbosity ............................ 3
tracker-store[28869]: Store options:
tracker-store[28869]: Readonly mode ........................ no
tracker-store[28869]: GraphUpdated Delay .................... 1000
tracker-store[28869]: Domain................................. org.freedesktop.Tracker1
tracker-store[28869]: Cache location......................... file:///home/mikhail/.cache/tracker
tracker-store[28869]: Data location.......................... file:///home/mikhail/.local/share/tracker/data
tracker-store[28869]: Ontology location...................... file:///usr/share/tracker/ontologies/nepomuk
tracker-store[28869]: Log verbosity is set to 3, enabling D-Bus client lookup
tracker-store[28869]: Registering D-Bus object...
tracker-store[28869]: Path:'/org/freedesktop/Tracker1/Status'
tracker-store[28869]: Type:'TrackerStatus'
tracker-store[28869]: Registering D-Bus object...
tracker-store[28869]: Path:'/org/freedesktop/Tracker1/Statistics'
tracker-store[28869]: Type:'TrackerStatistics'
tracker-store[28869]: Registering D-Bus object...
tracker-store[28869]: Path:'/org/freedesktop/Tracker1/Resources'
tracker-store[28869]: Type:'TrackerResources'
tracker-store[28869]: Registering D-Bus object...
tracker-store[28869]: Path:'/org/freedesktop/Tracker1/Steroids'
tracker-store[28869]: Type:'TrackerSteroids'
tracker-store[28869]: Registering D-Bus object...
tracker-store[28869]: Path:'/org/freedesktop/Tracker1/Backup'
tracker-store[28869]: Type:'TrackerBackup'
tracker-store[28869]: Registering D-Bus service...
Name:'org.freedesktop.Tracker1'
systemd[1561]: Started Tracker metadata database store and lookup manager.
tracker-store[28869]: Setting database locations
tracker-store[28869]: Checking database directories exist
tracker-store[28869]: Checking database version
tracker-store[28869]: Checking whether database files exist
tracker-store[28869]: Loading databases files...
tracker-store[28869]: Didn't shut down cleanly last time, doing integrity checks
tracker-store[28869]: Opened sqlite3 database:'/home/mikhail/.cache/tracker/meta.db'
tracker-store[28869]: Setting page size to 8192
tracker-store[28869]: Setting cache size to 250
tracker-store[28869]: Opened sqlite3 database:'/home/mikhail/.cache/tracker/meta.db'
tracker-store[28869]: Setting page size to 8192
tracker-store[28869]: Setting cache size to 250
tracker-store[28869]: Closed sqlite3 database:'/home/mikhail/.cache/tracker/meta.db'
tracker-store[28869]: Unable to insert multiple values for subject `http://www.tracker-project.org/temp/nmm#albumTitle' and single valued property `rdfs:comment' (old_value: 'nmm:albumTitle is deprecated, use nie:title instead, extractors still need updating', new value: 'nmm:albumTitle is deprecated, use nie:title instead')
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Could not insert FTS text: constraint failed
tracker-store[28869]: Transaction rollback failed: cannot rollback - no transaction is active
tracker-store[28869]: Cannot initialize database: constraint failed
systemd[1561]: tracker-store.service: Main process exited, code=exited, status=1/FAILURE
systemd[1561]: tracker-store.service: Unit entered failed state.
systemd[1561]: tracker-store.service: Failed with result 'exit-code'.
systemd[1561]: tracker-store.service: Service hold-off time over, scheduling restart.
systemd[1561]: Stopped Tracker metadata database store and lookup manager.
$ rpm -qa | grep tracker | sort
mesa-libxatracker-17.2.1-1.fc27.x86_64
tracker-2.0.0-2.fc27.x86_64
tracker-miners-2.0.0-3.fc27.x86_64
> consumes 100% CPU", you need to add how long you've left it running. Maybe the CPU usage goes away after a minute or two.
100% CPU usage is observed all the time while the computer is running. My computer never switched off. So it permanent process (tracker daemon start and stop with error)
cleaning blocks: for rejected blocker. This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. Experiencing the same behavior, 50% - 100% cpu usage, in rawhide fc30 and tracker-store is more broken. Almost every command ends with a failure
The cpu fans runs comparably as high indicating the that the cpu is being overloaded and it is doing nothing else but tracker.
This needs to be elevated to an "URGENT" bug fix as users' computers are being slowly damaged. (shortened life expectancy)
Linux BRSINC-01Fed 4.20.0-0.rc6.git0.1.fc30.x86_64 #1 SMP Mon Dec 10 16:44:23 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
To dangerouse to run tracker reset -r at until more is know about this issue.
The /tmp/tracker-extract-files.1001 directory contains no entries
[01Fed tmp]$ tracker daemon list
Store:
(tracker daemon:5987): Tracker-CRITICAL **: 10:14:04.994: Could not retrieve tracker-store status,
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
Miners:
13 Dec 2018, 10:14:04: ✗ File System - Not running or is a disabled plugin
13 Dec 2018, 10:14:04: ✗ Extractor - Not running or is a disabled plugin
13 Dec 2018, 10:14:04: ✗ Applications - Not running or is a disabled plugin
13 Dec 2018, 10:14:04: ✗ RSS/ATOM Feeds - Not running or is a disabled plugin
[01Fed tmp]$ tracker status
Could not establish a connection to Tracker: Failed to load SPARQL backend:
GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected
[01Fed tmp]$ tracker reset -c
Tracker-Message: 10:16:40.443: Path is OK
Removing configuration files…
Resetting existing configuration…
Store
verbosity
graphupdated-delay
Extract
max-media-art-width
verbosity
wait-for-miner-fs
max-bytes
sched-idle
Writeback
verbosity
Files
(tracker reset:6390): GLib-GIO-CRITICAL **: 10:16:40.456:
g_settings_schema_list_keys: assertion 'schema != NULL' failed
Tracker after thoughts. Just as Tracker is potentially reducing the lifespan of my cpu it is also reducing the lifetime of my SSD with millions of unnecessary writes. In fact, Tracker is bloatwear installed as part of the distro. After researching Tracker even more I learned that it is the reason behind the desktop cursor/mouse will "freezing" at random. I have experienced this also. One user once eliminating Tracker commented they had got control of the computer back. I agree. I have disabled Tracker and Tracker-miner as well as a few other bloatwear applications I discovered. After disabling these the only user application running more than 1% cpu and 1% memory is Firefox which is user app. In the rested state with only a terminal and "top" running no application is consuming more than 1% of cpu or 1% of memory on a continuous basis. And then, only a short burst by apps such Dropbox, Xorg and gnome-shell. This is where I want to be. I let my computer run for days and never turn it off. It's got a smart AMD energy saver CPU that essentially shuts the system down without turning it off. The equivalent of suspend. But wait there's more! I tested the gnome window search (the principal reason for Tracker) for the file "abcdefghijklmnopqrstuvwxyz" from the root (/) and the time to return was 12-15 seconds. I performed this same test from the shell using find / -name "abcdefghijklmnopqrstuvwxyz" -print and the return time was LESS THAN 3 SECONDS. There you have it, Tracker is bloatwear that is inferior to UNIX code written 50 years ago. So there is no bug hear for me, just disable it. Now the issue is how to stop installing this bloatwear in the first place, because not only will it eat up the cpu and ssd but it requires way to much space on my SSD TOO! This is not a forum. Please hold the rants. This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |