Solved Attempting to run "sudo updatedb" for the locate command - getting a permission denied error.

Solved issue
No worries, mate. ;)

@Priest_Apostate thanks for that post.

I am still somewhat confused myself.

Package List at DistroWatch for Debian 12 lists as installed

• locate 4.9.0-4

• mlocate 1.1.18-1

and

• plocate 1.1.18-1

But if you type in and enter

Code: 
man locate

You get the plocate manual entry.

I don't have a KDE Plasma edition of Bookworm, but I have one in Debian 11 'Bullseye', and I have a Cinnamon of Debian 12 'Bookworm', and they both have the same setup as I have described.

In any event, if the OP has a running functionality now, he could mark this thread as Solved when he feels it appropriate.

Cheers

Wizard
 


osprey said:
One needs to be very careful about anything with "gnome" in it's package name. The dpkg command above will likely show that there are many packages with "gnome" in their names, but even though the gnome desktop environment (DE) in not installed, a number of other desktop environments do depend on some gnome utilities or packages which have gnome in their name, and if these are removed, those other desktops will have their functions affected, some in seriously impaired ways.
Click to expand...
That's why I also said.
f33dm3bits said:
Then remove all the packages that have gnome listed. Then afterwards you can run "sudo apt autoremove" again and check again if there is anything on the list to be removed that you use or is important.
Click to expand...
I'll test it out myself today by installing Debian with Gnome and then installing KDE Plasma, after which I will remove Gnome the way I would if I would do it myself.
 
osprey said:
There are means of showing the files which packages install. In the case here with debian, the following would be useful to discover those files of interest and packages you mention:
Click to expand...
Yeah sure I hadn't caught that configuration file was installed by the package plocate.
Code: 
root@debian:~# apt-file search  /etc/updatedb.conf
plocate: /etc/updatedb.conf
But when you install mlocate.
Code: 
root@debian:~# apt install mlocate
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  plocate
The following NEW packages will be installed:
  mlocate plocate
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 131 kB of archives.
After this operation, 550 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Both mlocate and plocate get pulled in and therefore placing the configuration file(/etc/updatedb.conf) for it. So it seems that they actually want you to use plocate instead of mlocate. I've never had to think about which one I use. As long as I can use locate I am a happy camper.

Priest_Apostate said:
,g$$P" """Y$$.". OS: Debian GNU/Linux 12 (bookworm) x86_64
Click to expand...
Looks like Bookworm to me or did I miss something?

I oversaw my little detail(about mlocate/plocate) and now my answer is all of a sudden invalid or not good enough? ;)
 
Last edited:
f33dm3bits said:
I'll test it out myself today by installing Debian with Gnome and then installing KDE Plasma, after which I will remove Gnome the way I would if I would do it myself.
Click to expand...
I tested it out myself. What I did was the following.
1. Installed Debian selecting Gnome as my DE during installation.
2. Installed KDE with Debian's selection of applications for a KDE Desktop: apt install task-kde-desktop (Select to switch to sddm when prompted for it)
3. Removed Gnome: apt remove gnome gnome-core
4. Removed dependencies: apt autoremove
After point 4 there were still the option to select Gnome from the login session, so I continued.
5. Remove all packages with Gnome in it: dpkg --list | grep gnome | awk -F "ii" '{ print $2 }' | awk -F" " '{ print $1 }' | xargs apt remove -y
6. Removed all the dependencies: apt autoremove
7. Reboot.
I am now left with a login screen that only has Gnome sessions available for selecting and a still working KDE Plasma desktop.

I also installed a Debian installation where I selected KDE Plasma and Debian desktop environment as my DE during the installation process. Here's the list of Gnome applications that are installed with a Debian KDE Plasma installation.
root@kdesktop:~# dpkg --list | grep -i gnome | awk -F "ii" '{ print $2 }' | awk -F" " '{ print $1 }'
adwaita-icon-theme
gcr
gnome-keyring
gnome-keyring-pkcs11:amd64
libgail-common:amd64
libgail18:amd64
libpam-gnome-keyring:amd64
libxml2:amd64
libxml2-utils
pinentry-gnome3
xdg-desktop-portal-gtk
Click to expand...
So you can still install those manually if those were removed when removing gnome gnome-core and anything with gnome in the package name.
apt install adwaita-icon-theme gcr gnome-keyring gnome-keyring-pkcs11 libgail-common libgail18 libpam-gnome-keyring libxml2 libxml2-utils pinentry-gnome3 xdg-desktop-portal-gtk
Click to expand...
 
While the initial issue of the sudo command being refused has been solved for the updatedb command, for the mlocate and plocate package, does anyone have any idea as to why the updatedb command no longer works for the locate package itself?

EDIT TO ADD: I am aware of @osprey's answer in #56 - but as that seems to be in conflict with the documentation below, which might be causing me to spiral a bit...

As per here:

1719242426180.png


That seems to be the case for Debian - but I didn't have to go through this issue with the Rocky install, which begs the question as to what gives with the Debian version?

ETA: I know that I am fixating on this - but my reasoning is that this begs a larger question as to whether I should be using Debian to study for the LPIC, as this is the second unpublished change that diverges from what is expected in the study material (or online documentation) that I've encountered.
 
Last edited:
Priest_Apostate said:
or the mlocate and plocate package, does anyone have any idea as to why the updatedb command no longer works for the locate package itself?
Click to expand...
It does work the problem with your case was that the /etc/updatedb.conf configuration file wasn't placed for some reason while it should have been place. That file is provided by the plocate package as @osprey mentioned.
Code: 
root@debian:~# apt-file search /etc/updatedb.conf
plocate: /etc/updatedb.conf
When install mlocate, both mlocate and plocate get installed.
Code: 
root@debian:~# apt install mlocate
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  plocate
The following NEW packages will be installed:
  mlocate plocate
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 131 kB of archives.
After this operation, 550 kB of additional disk space will be used.
Do you want to continue? [Y/n]
So it seems Debian wants people to start using plocate instead of mlocate, doesn't matter which one you use. They have the same functionality, but plocate is faster. The man page even says it.
plocate - find files by name, quickly
Click to expand...

Code: 
If you check alternatives on Debian, that also verifies that.
[CODE]
root@debian:~# update-alternatives --get-selections | grep locate
locate                         auto     /usr/bin/plocate
So when using locate, you are actually using plocate.

Priest_Apostate said:
That seems to be the case for Debian - but I didn't have to go through this issue with the Rocky install, which begs the question as to what gives with the Debian version?
Click to expand...
They are two different distributions, doing different things and having different priorities. It doesn't matter why Debian does things one way and Rocky/RHEL does things another way. They both have their reasons for doing something and making different choices.

In short [m]locate is old plocate is new but they both do the same, Debian prefers people to start using plocate instead of [m]locate. Maybe in RHEL10 they will switch over to plocate as well, does it matter? So what's the big deal about this? Seems you're making an elephant of mosquito about this specific command, why or are just trying to understand why you get two different outcomes on two different distributions when it comes to [m]locate?
 
Last edited:
f33dm3bits said:
In short [m]locate is old plocate is new but they both do the same, Debian prefers people to start using plocate instead of [m]locate. Maybe in RHEL10 they will switch over to plocate as well, does it matter? So what's the big deal about this? Seems you're making an elephant of mosquito about this specific command, why?
Click to expand...


This is the second time I've encountered issues in which Debian's functionality diverges from both the study documentation and online content. The unpublished contradictions cause me to waste significant time investigating as to whether I'm fat-fingering stuff, causing me to spiral to pinpoint what I could have done wrong to cause the issue - when that wasn't the case. It makes me wonder as to whether I will experience the same thing with not just Debian - but other Debian derivative OS systems.

There is also the point of wasti--er, spending 2-400 dollars to get tested for certification on stuff, in which I wasted time studying contradictory information.

In any case, I'll consider the matter closed.
 
Last edited:
Priest_Apostate said:
The unpublished contradictions cause me to waste significant time investigating as to whether I'm fat-fingering stuff, causing me to spiral to pinpoint what I could have done wrong to cause the issue - when that wasn't the case.
Click to expand...
I can understand that!

Priest_Apostate said:
This is the second time I've encountered issues in which Debian's functionality diverges from both the study documentation and online content.
Click to expand...
What Debian version are they using in your study documentation? With online content some of the things you come across can be 10 years or older and isn't really applicable anymore, so be sure to check the date of the online sources you are using when it was published.

Priest_Apostate said:
It makes me wonder as to whether I will experience the same thing with not just Debian - but other Debian derivative OS systems.
Click to expand...
Yes probably because Debian and Ubuntu based distributions use different configuration file names and package names than lets say Fedora/RHEL based distributions and Arch based distributions do those things differently too and fill in distribution X for whatever other distribution does things differently.

I hope that helps? If in doubt just post your question in the forum and someone will come a long and try to do their best to answer your question or help you.
 
One final question, if you would humour me.

What is the output from

Code: 
locate plocate

TIA

Wizard
 
wizardfromoz said:
One final question, if you would humour me.

What is the output from

Code: 
locate plocate

TIA

Wizard
Click to expand...


As follows:


Code: 
priestapostate@XXXXXX:~$ locate plocate
/etc/cron.daily/plocate
/etc/systemd/system/timers.target.wants/plocate-updatedb.timer
/home/priestapostate/.local/share/tldr/pages/common/plocate.md
/home/priestapostate/.local/share/tldr/pages.en/common/plocate.md
/home/priestapostate/backup/priestapostate/.tldr/cache/pages/common/plocate.md
/home/timeshift/snapshots/2024-06-09_15-00-01/localhost/home/priestapostate/.local/share/tldr/pages/common/plocate.md
/home/timeshift/snapshots/2024-06-09_15-00-01/localhost/home/priestapostate/.local/share/tldr/pages.en/common/plocate.md
/home/timeshift/snapshots/2024-06-17_07-00-01/localhost/home/priestapostate/.local/share/tldr/pages/common/plocate.md
/home/timeshift/snapshots/2024-06-17_07-00-01/localhost/home/priestapostate/.local/share/tldr/pages.en/common/plocate.md
/usr/bin/plocate
/usr/lib/systemd/system/plocate-updatedb.service
/usr/lib/systemd/system/plocate-updatedb.timer
/usr/sbin/plocate-build
/usr/sbin/updatedb.plocate
/usr/share/doc/plocate
/usr/share/doc/plocate/changelog.Debian.gz
/usr/share/doc/plocate/copyright
/usr/share/man/man1/plocate.1.gz
/usr/share/man/man8/plocate-build.8.gz
/usr/share/man/man8/updatedb.plocate.8.gz
/var/lib/plocate
/var/lib/dpkg/info/plocate.conffiles
/var/lib/dpkg/info/plocate.list
/var/lib/dpkg/info/plocate.md5sums
/var/lib/dpkg/info/plocate.postinst
/var/lib/dpkg/info/plocate.postrm
/var/lib/dpkg/info/plocate.prerm
/var/lib/plocate/CACHEDIR.TAG
/var/lib/plocate/plocate.db
/var/lib/systemd/deb-systemd-helper-enabled/plocate-updatedb.timer.dsh-also
/var/lib/systemd/deb-systemd-helper-enabled/timers.target.wants/plocate-updatedb.timer
/var/lib/systemd/timers/stamp-plocate-updatedb.timer
priestapostate@XXXXXX:~$

Not to sound rude - but what's up?
 
Also, did something happen to the website?
I've been unable to access it for hours...
 
Priest_Apostate said:
Also, did something happen to the website?
I've been unable to access it for hours...
Click to expand...

Unsure, I have been in and out intermittently today.

Priest_Apostate said:
Not to sound rude - but what's up?
Click to expand...

The reference I was looking for was

/etc/cron.daily/plocate
Click to expand...

...which you have now.

Previously, you only had an rkhunter reference.

What appears to happen is that once plocate is introduced into the equation, it usurps the file associations attributed to the others, and so, when you run a locate command, it automatically runs plocate.

If that is so, then I do not know why the Devs include locate and mlocate at all.
 
Your plocate reference in /etc/cron.daily/ is a script which likely has content similar to this

Code: 
#! /bin/sh

set -e

UPDATEDB=/usr/sbin/updatedb.plocate

# Skip if systemd timer is available.
if [ -d /run/systemd/system ]; then
    exit 0
fi

[ -x $UPDATEDB ] || exit 0

if which on_ac_power >/dev/null 2>&1; then
    ON_BATTERY=0
    on_ac_power >/dev/null 2>&1 || ON_BATTERY=$?
    if [ "$ON_BATTERY" -eq 1 ]; then
        exit 0
    fi
fi

# See ionice(1).
IONICE=
if [ -x /usr/bin/ionice ] &&
    /usr/bin/ionice -c3 true 2>/dev/null; then
    IONICE="/usr/bin/ionice -c3"
fi

# See nocache(1).
NOCACHE=
if [ -x /usr/bin/nocache ]; then
    NOCACHE="/usr/bin/nocache"
fi

flock --nonblock /run/plocate.daily.lock $NOCACHE $IONICE nice $UPDATEDB

The pivotal factor here is the setting of the environment variable

Code: 
set -e

UPDATEDB=/usr/sbin/updatedb.plocate

so that when you run

Code: 
sudo updatedb

...well, you can no doubt follow my train of thought :)

Hope this helps.
 
wizardfromoz said:
Your plocate reference in /etc/cron.daily/ is a script which likely has content similar to this

Code: 
#! /bin/sh

set -e

UPDATEDB=/usr/sbin/updatedb.plocate

# Skip if systemd timer is available.
if [ -d /run/systemd/system ]; then
    exit 0
fi

[ -x $UPDATEDB ] || exit 0

if which on_ac_power >/dev/null 2>&1; then
    ON_BATTERY=0
    on_ac_power >/dev/null 2>&1 || ON_BATTERY=$?
    if [ "$ON_BATTERY" -eq 1 ]; then
        exit 0
    fi
fi

# See ionice(1).
IONICE=
if [ -x /usr/bin/ionice ] &&
    /usr/bin/ionice -c3 true 2>/dev/null; then
    IONICE="/usr/bin/ionice -c3"
fi

# See nocache(1).
NOCACHE=
if [ -x /usr/bin/nocache ]; then
    NOCACHE="/usr/bin/nocache"
fi

flock --nonblock /run/plocate.daily.lock $NOCACHE $IONICE nice $UPDATEDB

The pivotal factor here is the setting of the environment variable

Code: 
set -e

UPDATEDB=/usr/sbin/updatedb.plocate

so that when you run

Code: 
sudo updatedb

...well, you can no doubt follow my train of thought :)

Hope this helps.
Click to expand...


The text shows there as such:


Code: 
#! /bin/sh

set -e

UPDATEDB=/usr/sbin/updatedb.plocate

# Skip if systemd timer is available.
if [ -d /run/systemd/system ]; then
    exit 0
fi

[ -x $UPDATEDB ] || exit 0

if which on_ac_power >/dev/null 2>&1; then
    ON_BATTERY=0
    on_ac_power >/dev/null 2>&1 || ON_BATTERY=$?
    if [ "$ON_BATTERY" -eq 1 ]; then
        exit 0
    fi
fi

# See ionice(1).
IONICE=
if [ -x /usr/bin/ionice ] &&
    /usr/bin/ionice -c3 true 2>/dev/null; then
    IONICE="/usr/bin/ionice -c3"
fi

# See nocache(1).
NOCACHE=
if [ -x /usr/bin/nocache ]; then
    NOCACHE="/usr/bin/nocache"
fi

flock --nonblock /run/plocate.daily.lock $NOCACHE $IONICE nice $UPDATEDB
priestapostate@XXXXXX:~$

which does show that line.
 
You must log in or register to reply here.

Similar threads

Y
ProFTPD fails to start with PID file error after manual installation from source
Replies
18
Views
964
f33dm3bits
f33dm3bits
P
Sudo/root permissions not being accepted for access to /usr/local/share/tor-browser
2
Replies
23
Views
6K
Priest_Apostate
P
sedation
Solved How to find a running script? (theoretical)
Replies
3
Views
571
sedation
sedation
Jarret B
Linux Security Check
Replies
1
Views
5K
Trenix25
Trenix25
P
Attempting to run a command at boot / before user login not working
Replies
3
Views
1K
dos2unix
dos2unix


Staff online

Members online

Total: 759 (members: 5, guests: 754)

Latest posts

Top