Systemd Will Be Working To Improve Out-Of-Memory Linux Handling With Facebook OOMD

[fkoehler]

Finally something is being done about this. Gnome's tracker routinely completely thrashes my system at startup because it is completely buggy and goes into endless loops using endless memory on some files, which it does not tell you and thus gives you no options to explicitely exclude, god beware even trying to do so automatically. So I have to switch to konsole and 'pkill tracker' if I even get that far. Not using tracker is not an option either, as principally a search function is really usefull, as you know if you are using Windows 10 :-/

At least with the systemd's professional developers around Poettering on the case we can now hope that something functional is being done instead of endless circlejerking and blame gaming.

[Britoid]

Finally something is being done about this. Gnome's tracker routinely completely thrashes my system at startup because it is completely buggy and goes into endless loops using endless memory on some files, which it does not tell you and thus gives you no options to explicitely exclude, god beware even trying to do so automatically. So I have to switch to konsole and 'pkill tracker' if I even get that far. Not using tracker is not an option either, as principally a search function is really usefull, as you know if you are using Windows 10 :-/

At least with the systemd's professional developers around Poettering on the case we can now hope that something functional is being done instead of endless circlejerking and blame gaming.

99% of problems with tracker can be fixed with tracker reset -r

[fkoehler]

99% of problems with tracker can be fixed with tracker reset -r

"Although most content indexed by Tracker can be safely reindexed, it can?t (sic ...) be assured that this is the case for all data. Be aware that you may be incurring data loss situation (sic ...), proceed at your own risk."

Well, now I feel really confident that nothing can go wrong with 'tracker reset -r', the developers of this indexing software clearly are competent and 99% confident in their capabilities. :-(

I'll try it anyways, thanks for the tip ;-)

[FPScholten]

Finally something is being done about this. Gnome's tracker routinely completely thrashes my system at startup because it is completely buggy and goes into endless loops using endless memory on some files, which it does not tell you and thus gives you no options to explicitely exclude, god beware even trying to do so automatically. So I have to switch to konsole and 'pkill tracker' if I even get that far. Not using tracker is not an option either, as principally a search function is really usefull, as you know if you are using Windows 10 :-/

use either GSettings or DConf-editor to add your files to this list:

org.freedesktop.Tracker.Miner.Files Ignored-files

Then restart the tracker deamon.

[fkoehler]

use either GSettings or DConf-editor to add your files to this list:

org.freedesktop.Tracker.Miner.Files Ignored-files

Then restart the tracker deamon.

I don't know the filenames and don't know how to find out, the computer simply gets unresponsive without printing the "critical filenames" :-/ If I knew them, I prolly would either just delete them or move them into a non-indexed path :-/

I'm doing the 'tracker reset -r' + reboot thing now, let's see what happens. Anyways, reliable OOM-killing for rogue tracker processes sounds splendid :-)

[fkoehler]

And just for the record, tracker-extract is at it again and will thrash the system for 10 .. 10 000 minutes until getting oom-killed every reboot. :-/

[FPScholten]

And just for the record, tracker-extract is at it again and will thrash the system for 10 .. 10 000 minutes until getting oom-killed every reboot. :-/

To find out which files it is choking on, use lsof
something like

sudo lsof -c tracker-miner-fs

should give you a list.
Also check out the other processes tracker uses. (not using tracker myself so not sure about the names of the daemons, check them first!

[NotMine999]

So if Fedora implements their version first and then comes systemd update with its own modified FB version, which one of those versions will Fedora use in the end? Or I misunderstood and they will all integrate into one OOM solution later on?

Good question.

It would be nice to see the Fedora code used and not the systemd code.

It would be one of those times when some of us can when a Redhat product quietly says to Lennart: "Hold my beer. We got this. Go off and write a systemd replacement for /dev/null"

[pal666]

Why not more developers collaborate to make this happen earlier and not be done only by Facebook developers?

because only for facebook developers fixing it is important enough?

[pal666]

Finally something is being done about this. Gnome's tracker routinely completely thrashes my system at startup because it is completely buggy and goes into endless loops using endless memory on some files

it can be fixed by assigning memory limit to one process