I'm running current with ktown and multilib.I'm trying to stop baloo. I believe this can be done from the pane

System Settings -> Search

On this pane I clear the <Enable File Search> check box and then press <Apply>

When I go back to System Settings -> Search I find that the <Enable File Search> checkbox is still enabled and that baloo is still running.

I've tried logging out and rebooting the machine, but baloo still runs.

How do I make baloo go away?

Hello,

Maybe this can help you (see section enable/disable).

--
SeB

1 members found this post helpful.

Certainly did.

Created a configuration containing this


When I now go back to System Settings -> Search I find that the <Enable File Search> checkbox is no longer enabled. Result.

Thanks

I'm curious, why? baloo using system resources or you use some other search tool?

baloo does use a lot of system resources initially.

So I wanted to stop baloo on my VirtualBox guests which I use as test machines and for compiling. I have no need to search them.

Should Baloo be turned on by default? It is the only thing that has ever caused me problems with Plasma 5.

My problem was I couldn't disable desktop search from System Settings, forcing me to manually edit the config file .config/baloofilerc. I would have thought that not being able to disable desktop search from System Settings is a bug. I've not raised a ticket for this.

I don't know what I'll do when the next Slackware stable release is installed on my production machines. Probably, leave baloo running. I have desktop search enabled on my production machines (Slackware 14.2) at the moment. I seem to remember it caused me grief initially, but then settles down after 4 or more hours after it's done the initial heavy indexing.

On my test boxes and compile box I have no need for searching other than using a combination of locate, find and grep. Which was why I wanted to disable desktop searching. I could have left it running overnight, but routinely I delete everything in .config and .local and all other configuration files in the testing home directory. This causes baloo to start indexing all over again.

No, it most certainly should not. This assumption that "the user needs it" is just plain wrong.

Sensible default settings please.

2 members found this post helpful.

But these are likely the default settings from KDE devs. It is likely Pat (or Eric if Plasma5) is just using upstream defaults and considering Slackware likes to be as vanilla as possible, I don't know if that warrants patching it. It would likely either require a patch or a file residing in /etc/skel/ to make sure that the correct configuration gets added to new profiles. That seems unlikely, but Pat does like to keep us on our toes

I'm not a KDE user, but might "chmod a-x /usr/bin/baloo*" do the trick? Or does it make KDE unhappy?

Try to remove the checkmark from autostart and reboot. Worked for me

If I understand the question correctly,
the following may help you.

Over the last couple of hours I installed kde5 to a recent installtion of -current. As usual, many kde5 settings options end up being mixed in with the Xfce settings.
I'm now back in Xfce-4.12 and under Settings>Session and Startup>Application Autostart, there is now an option for the Baloo File Daemon. You might try removing the check mark in the box to the left of the Baloo Daemon and then go back into kde5 and see if it makes a difference.
Just a thought.

On my system if the user is logged on, baloo will start and can be stopped from the command line

In the same session baloo can be started again from the command line

If baloo is subsequently disabled, If the user then logs out and back in again baloo will start again!

Playing around with the Search System Settings seems to make no difference, though it does show the existing status.

The only simple way I've found to stop baloo starting on the next log in (i.e. permanently) is to edit the file .config/baloofilerc to add to the front of this file the lines

2 members found this post helpful.

I installed Slackware 14.2-current this week on my Thinkpad A285. When I bought the laptop I had switched to Mint, believing the Slackware kernel didn't support the Ryzen at that stage - I've no idea whether I could have juggled matters at the time, I merely note my reason. I did the same with several other Ryzen machines.

Anyway, the present kernel is 5.12.12 so the reason has lapsed. The install was clean except the kernel panics not knowing how much memory I have (thank you rennj on the IRC channel for the suggestion) - the Thinkpad BIOS is perhaps an in-house proprietary variant of AMI and odd (again a guess). Adding

mem=16G

fixed the panic.

The LUKS/LVM section of the CRYPTO.TXT guide still works flawlessly for at-rest partition encryption. I note Mint does the same thing with a single checkbox. If I were a linux newbie I'd find that a bit of a slog.

But to my point - the preamble so far was only to improve search engine responses about recent Thinkpads. What follows is "Trying to stop baloo in current".

We remember the history? Indexed file content and metadata abstracted by Strigi and Nepomuk, the two merging at some stage and then being replaced by Baloo? And the pervasive expansion of Akonadi to handle PIM passwords? I've fought to remove these from every Slackware installation I've done for my personal machines and an infuriating exercise I've found it too. I regard them as wasteful and a potential security hazard. The fact that these programs are still installed by default just shows how far along an obscure limb I am, of course.

With appropriate permissions,

rm /usr/bin/baloo*
rm /usr/bin/akonadi*

and reboot. I may need to blacklist them in slackpkg later.

I've encountered no untoward consequence in multi-user mode, with or without xfce. Doubtless if I used KDE components I'd be stuffed but I seem not to.

I think this is the right thread, old or not. I'll add a note if any problems arise but I'm long past the stage of trying to find configuration toggles to beg either system to suppress its activity.

1 members found this post helpful.