Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

is mlocate useful for toolbox? #391

Closed
juhp opened this issue Mar 17, 2020 · 7 comments
Closed

is mlocate useful for toolbox? #391

juhp opened this issue Mar 17, 2020 · 7 comments

Comments

@juhp
Copy link
Contributor

juhp commented Mar 17, 2020

I am not sure how well mlocate works in Toolbox.

Recently when I tried it, I ended up with a 340MB database, maybe because of ~/.local/share/containers?

Are people using it or should we drop it from the default fedora-toolbox packages?

@maxwell-k
Copy link

I am not using it and would be happy if you dropped it.

@HarryMichal
Copy link
Member

Until now I didn't know such tool even existed :)

@juhp
Copy link
Contributor Author

juhp commented Mar 18, 2020

Until now I didn't know such tool even existed :)

Oh it's useful on Workstation at least.

@juhp
Copy link
Contributor Author

juhp commented Mar 29, 2020

On Silverblue, locate only shows me entries for /etc and /boot basically... so yeah, but maybe the config could be fixed to index /usr, /home, /var, etc also?

See also https://bugzilla.redhat.com/show_bug.cgi?id=906591

@juhp juhp changed the title Is mlocate useful for toolbox is mlocate useful for toolbox? Mar 29, 2020
@debarshiray
Copy link
Member

Until now I didn't know such tool even existed :)

Oh it's useful on Workstation at least.

The problem is that we expect many CLI users, such as developers, to live inside a toolbox container. If so, the lack of mlocate can be felt.

Recently when I tried it, I ended up with a 340MB database, maybe because of
~/.local/share/containers?

We also have the problem that the database doesn't get automatically created.

I think we can solve this by having toolbox init-container periodically invoke updatedb with a carefully crafted set of command line arguments that skip things like ~/.local/share/containers in addition to the static configuration in /etc/updatedb.conf.

Note that toolbox init-container is the entry-point process for all Toolbox containers, and is always running for any container that's in use. Currently it invokes sleep +Inf but we can make it do more than that. (Thanks to @HarryMichal for this clever observation!)

@HarryMichal HarryMichal added this to Needs triage in Priority Board Jul 28, 2020
@HarryMichal
Copy link
Member

I believe for now we can close this since @juhp went ahead and removed the tool from the fedora-toolbox image and considering that there were no reports complaining about the tool being gone.

Priority Board automation moved this from Needs triage to Closed Sep 10, 2020
@debarshiray
Copy link
Member

I was playing with this a bit today.

Recently when I tried it, I ended up with a 340MB database, maybe
because of ~/.local/share/containers?

How do the sizes of /var/lib/mlocate/mlocate.db on the host and inside the container compare?

In my case on a Fedora Workstation system, they were 101M and 100M respectively. Silverblue doesn't have a working mlocate on the host, so the comparison there is less meaningful.

See also https://bugzilla.redhat.com/show_bug.cgi?id=906591

Strangely enough, having PRUNE_BIND_MOUNTS = "yes" doesn't seem to prevent updatedb from indexing all the bind mounts inside a Toolbox container. eg., locate Downloads or locate pam_xauth.so returns results from locations that are known to be bind mounts.

debarshiray added a commit to debarshiray/toolbox that referenced this issue Oct 30, 2020
debarshiray added a commit to debarshiray/toolbox that referenced this issue Nov 3, 2020
... by running updatedb(8) on start-up and then at 24 hour intervals
from there on.

This isn't as nice as using a systemd.timer(5) because the current
timer goes away when the toolbox container is stopped and is rearmed
when it's started. Therefore, repeatedly restarting a container will
also run updatedb(8) again and again.

Fortunately, this isn't so bad with updatedb(5) implementations that
are able to incrementally update the database [1], which is what Fedora
uses.

The 24 hour interval was chosen based on the systemd.timer(5) settings
used by Fedora's mlocate RPM.

[1] https://pagure.io/mlocate

containers#391
debarshiray added a commit to debarshiray/toolbox that referenced this issue Nov 3, 2020
... by running updatedb(8) on start-up and then at 24 hour intervals
from there on.

This isn't as nice as using a systemd.timer(5) because the current
timer goes away when the toolbox container is stopped and is rearmed
when it's started. Therefore, repeatedly restarting a container will
also run updatedb(8) again and again.

Fortunately, this isn't so bad with updatedb(5) implementations that
are able to incrementally update the database [1], which is what Fedora
uses.

The 24 hour interval was chosen based on the systemd.timer(5) settings
used by Fedora's mlocate RPM.

[1] https://pagure.io/mlocate

containers#391
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Priority Board
  
Closed
Development

No branches or pull requests

4 participants