On Fri, 2021-08-20 at 02:59 +0930, Tim via users wrote:
> On Wed, 2021-08-18 at 18:59 +0200, francis.montag...@inria.fr wrote:
> > Commenting PRUNE_BIND_MOUNTS = "yes" in /etc/updatedb.conf solves
> > this problem.
>
> So, does that mean it'll also scan through other areas it shouldn't?
>
> Or ar
On Wed, 2021-08-18 at 18:59 +0200, francis.montag...@inria.fr wrote:
> Commenting PRUNE_BIND_MOUNTS = "yes" in /etc/updatedb.conf solves
> this problem.
So, does that mean it'll also scan through other areas it shouldn't?
Or are the other prunes enough to take care of them? (I just couldn't
resi
On Thu, 2021-08-19 at 12:40 +0200, Roberto Ragusa wrote:
> On 8/19/21 12:05 AM, Patrick O'Callaghan wrote:
>
> > Looks like it. My /home is a BTRFS subvolume. Extraordinary that
> > this
> > hasn't been fixed, given that F34 uses BTRFS by default.
>
> Being forced to have all the bind mounts scan
On 8/19/21 12:05 AM, Patrick O'Callaghan wrote:
Looks like it. My /home is a BTRFS subvolume. Extraordinary that this
hasn't been fixed, given that F34 uses BTRFS by default.
Being forced to have all the bind mounts scanned because BTRFS subvolumes
are similar to bind mounts is annoying.
The r
On Wed, 2021-08-18 at 21:51 -0500, Dave Ulrick wrote:
> On 8/18/21 2:16 PM, Jan-Henrik Sorsimo via users wrote:
> > > I see the same behavior since using a btrfs subvol for /
> > >
> > > Commenting PRUNE_BIND_MOUNTS = "yes" in /etc/updatedb.conf solves
> > > this
> > > problem.
> > Indeed, that wa
On 8/18/21 2:16 PM, Jan-Henrik Sorsimo via users wrote:
I see the same behavior since using a btrfs subvol for /
Commenting PRUNE_BIND_MOUNTS = "yes" in /etc/updatedb.conf solves this
problem.
Indeed, that was it for me at least. Looks like the issue has been written
about:
https://pagure.io/
On Wed, 2021-08-18 at 18:59 +0200, francis.montag...@inria.fr wrote:
>
> Hi.
>
> On Wed, 18 Aug 2021 16:34:50 +0100 Patrick O'Callaghan wrote:
>
> > On Wed, 2021-08-18 at 15:25 +, Jan-Henrik Sorsimo via users
> > wrote:
>
> > > I took a look at the service unit file
> > > (/usr/lib/systemd/
> I see the same behavior since using a btrfs subvol for /
>
> Commenting PRUNE_BIND_MOUNTS = "yes" in /etc/updatedb.conf solves this
> problem.
Indeed, that was it for me at least. Looks like the issue has been written
about:
https://pagure.io/mlocate/issue/36
https://lore.kernel.org/linux-btr
Hi.
On Wed, 18 Aug 2021 16:34:50 +0100 Patrick O'Callaghan wrote:
> On Wed, 2021-08-18 at 15:25 +, Jan-Henrik Sorsimo via users wrote:
>> I took a look at the service unit file
>> (/usr/lib/systemd/system/mlocate-updatedb.service). It has some
>> sandboxing features set. When I set the valu
On Wed, 2021-08-18 at 15:25 +, Jan-Henrik Sorsimo via users wrote:
> > I have several binaries matching /usr/bin/myth*. When mlocate-
> > updatedb
> > runs via a timer, the / file system is skipped so no files under
> > /usr/bin are listed when I run "locate bin/myth".
>
> I'm experiencing t
> I have several binaries matching /usr/bin/myth*. When mlocate-updatedb
> runs via a timer, the / file system is skipped so no files under
> /usr/bin are listed when I run "locate bin/myth".
I'm experiencing the same issue.
I took a look at the service unit file
(/usr/lib/systemd/system/mloca
On 8/2/21 10:52 AM, Dave Ulrick wrote:
Any thoughts? Have I discovered a bug with mlocate-updatedb.timer or
mlocate-updatedb.service?
Just now I disabled mlocate-updatedb.timer and added an entry to root's
crontab (using 'crontab -e'):
SHELL=/bin/sh
PATH=/usr/local/bin:/usr/local/sbin:/sb
I have several binaries matching /usr/bin/myth*. When mlocate-updatedb
runs via a timer, the / file system is skipped so no files under
/usr/bin are listed when I run "locate bin/myth".
$ locate bin/myth
/home/mythtv/bin/mythconverg-create
/home/mythtv/bin/mythconverg-drop
/home/mythtv/bin/myth
13 matches
Mail list logo
