Nixpkgs: option request: services.baloo.enable

Created on 19 Jun 2019  Â·  17Comments  Â·  Source: NixOS/nixpkgs

something like the title - an option for turning the KDE baloo file indexer stuff on and off
Edit: maybe under services.kde or whatever is appropriate

stale nixos qkde user experience module (update)

Most helpful comment

Not to bikeshed, but I don't think "need to wait for upstream to provide mechanism" is reasonable for closing an issue? I'd just wait till upstream does indeed "do the thing", and then continue...

All 17 comments

For the longest time, I have been using baloo running as a systemd user service because the older baloo versions had a tendency to run wild and it was quite convenient to be able to definitely kill it.

The problem is that the running of various KDE subsystems is all set up in ksystemsettings5. So if you were to run it as a systemd user service, you wouldn't have a way to disable it again from inside KDE.

There is some work under way to have ksmserver use systemd user services and when that happens, this will be much easier to expose properly as a nixos option.

Is there any way to control things through ksystemsettings?

As of this moment, no. But it's WIP according to: http://blog.davidedmundson.co.uk/

On my nixos 19.09 baloo is extremely buggy. It leads to crashes because it has a memory leak. I need to kill it manually all the time. Reseaching a bit reveals that baloo has these problems since years and many people just recommend disabling it by default. There should definately be an option for disabling it i think. Seems to be a very common usecase.

Yeah, I just found this after seeing in syslog that baloo is constantly running:

Dec 08 17:10:15 nixos xsession[27723]: "/home/cody/emacs-config/straight/repos/org/lisp/ob-haskell.el" id seems to have changed. Perhaps baloo was not running, and this file was deleted + re-created
Dec 08 17:10:15 nixos xsession[27723]: mdb.c:2127: Assertion 'rc == 0' failed in mdb_page_dirty()
Dec 08 17:10:15 nixos systemd[1]: Started Process Core Dump (PID 31064/UID 0).
Dec 08 17:10:15 nixos systemd-coredump[31065]: Process 31056 (.baloo_file_ext) of user 1000 dumped core.
Dec 08 17:10:15 nixos systemd[1]: [email protected]: Succeeded.
Dec 08 17:10:15 nixos xsession[27723]: "/home/cody/emacs-config/straight/repos/org/lisp/ob-haskell.el" id seems to have changed. Perhaps baloo was not running, and this file was deleted + re-created
Dec 08 17:10:15 nixos xsession[27723]: mdb.c:2127: Assertion 'rc == 0' failed in mdb_page_dirty()
Dec 08 17:10:15 nixos systemd[1]: Started Process Core Dump (PID 31074/UID 0).

It's also constantly using 4% of my cpu.

This probably doesn't help you very much, but I'd like to point out that baloo has gotten a lot better than it was in the past and the only cases where where it has run wild recently has been because it just did what it was supposed to - index files.

You probably want to exclude network file systems and remote FUSE systems (I had a particularly bad experience with MP3FUSE) but as long as it just does local files, it absolutely flies.

This was a local directory synced by syncthing if that matters.

On Sun, Dec 8, 2019, 20:31 Peter Hoeg notifications@github.com wrote:

This probably doesn't help you very much, but I'd like to point out that
baloo has gotten a lot better than it was in the past and the only cases
where where it has run wild recently has been because it just did what it
was supposed to - index files.

You probably want to exclude network file systems and remote FUSE systems
(I had a particularly bad experience with MP3FUSE) but as long as it just
does local files, it absolutely flies.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/issues/63489?email_source=notifications&email_token=AABXEN7X252VR56U7T3P44DQXWUYRA5CNFSM4HZE37G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGHUBWY#issuecomment-563036379,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABXEN4I7F62P5F2IJW3QQLQXWUYRANCNFSM4HZE37GQ
.

This probably doesn't help you very much, but I'd like to point out that baloo has gotten a lot better than it was in the past and the only cases where where it has run wild recently has been because it just did what it was supposed to - index files.

Good, to know that it has improved but i have to disagree with you. For me it re-indexed the same two files over and over again in an endless loop taking my whole system into an out of memory state after a few hours. It was a normal file on my btrfs. I don't use any kind of network sync. I'm quite sure that there was no process running changing anything in those files. And even if it did, baloo should not 'memory leak'. So it is definitely buggy. I commented my problem on some exiting bug report which seemed similar to mine: See here: https://bugs.kde.org/show_bug.cgi?id=413694

That definitely doesn't look good.

That being said, we should close this issue for now as we don't have a mechanism to properly disable this until the ksmserver is done.

Not to bikeshed, but I don't think "need to wait for upstream to provide mechanism" is reasonable for closing an issue? I'd just wait till upstream does indeed "do the thing", and then continue...

agree, it seems strange to close this, even if there is nothing to be done at the moment. also here to mention that since upgrading to 19.09 my machine produced hundreds of baloo coredumps every startup, thrashing my CPU and disk.

that is, until i found that ksystemsettings does in fact let you disable baloo now. it's the Enable File Search checkbox on the Search pane. hope this saves somebody else from nightmares

forgot to mention that i also use btrfs.

baloo can indeed be disabled from the systemsettings (this has been the case for years) but it really isn't a system level setting as it very much depends on the individual users and a system level knob doesn't make much sense.

If anything this should belong in home-manager.

Once upstream transitions to systemd user sessions, it will be trivially easy to disable by masking the unit, but that doesn't mean we should do it here.

How to disable baloo on the command line? Maybe we can put the shell commands into the nix files.

I disabled it via balooctl disable. I guess this could be baked into some service.

baloo can indeed be disabled from the systemsettings (this has been the case for years) but it really isn't a system level setting as it very much depends on the individual users and a system level knob doesn't make much sense.

I respect the KDE project and all it does, but respectfully my experience with baloo has been unstable. A system level knob makes sense if baloo is unstable. Doubly so if nix used KDE and baloo by default.

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

teto picture teto  Â·  3Comments

copumpkin picture copumpkin  Â·  3Comments

tomberek picture tomberek  Â·  3Comments

edolstra picture edolstra  Â·  3Comments

spacekitteh picture spacekitteh  Â·  3Comments