slocate cron job fails if /etc/updatedb.conf not found

[Greg Ward]

Binary package hint: slocate

I get this email from cron every morning:

"""
From: Anacron <root@xxx>
To: root@xxx
Subject: Anacron job 'cron.daily' on gollum
Date: Tue, 05 Feb 2008 07:38:56 -0500

/etc/cron.daily/slocate: slocate: fatal error: load_file: Could not open file: /etc/updatedb.conf: No such file or directory
"""

This is on hardy (installed from scratch a few weeks ago and kept up-to-date since then). Obviously I haven't bothered to create /etc/updatedb.conf, but is that really a fatal error? If so, shouldn't the slocate package ship with an empty or skeletal /etc/updatedb.conf?

In fact, I can trivially workaround the problem:

  # touch /etc/updatedb.conf

[Richard Mancusi (vrman49)]

Just curious, why did you send this email to me?
I did not "manually" report this bug. Perhaps it was one of those
self-generating reports from one of my crashes. If that is the
case it becomes even more interesting because I received an
email this morning rejecting this bug because I didn't supply
enough information. That would be information created by the
system - not me. In any event, this isn't recent - perhaps from
Alpha-2 or 3 not Alpha-4.

On Feb 5, 2008 8:29 PM, Greg Ward <email address hidden> wrote:
> Public bug reported:
>
> Binary package hint: slocate
>
> I get this email from cron every morning:
>
> """
> From: Anacron <root@xxx>
> To: root@xxx
> Subject: Anacron job 'cron.daily' on gollum
> Date: Tue, 05 Feb 2008 07:38:56 -0500
>
> /etc/cron.daily/slocate: slocate: fatal error: load_file: Could not open file: /etc/updatedb.conf: No such file or directory
> """
>
> This is on hardy (installed from scratch a few weeks ago and kept up-to-
> date since then). Obviously I haven't bothered to create
> /etc/updatedb.conf, but is that really a fatal error? If so, shouldn't
> the slocate package ship with an empty or skeletal /etc/updatedb.conf?
>
> In fact, I can trivially workaround the problem:
>
> # touch /etc/updatedb.conf
>
> ** Affects: slocate (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> slocate cron job fails if /etc/updatedb.conf not found
> https://bugs.launchpad.net/bugs/189462
> You received this bug notification because you are a bug contact for
> slocate in ubuntu.
>

[Christian Mangold (neversfelde)]

8.04 uses mlocate instead of slocate on desktops now, so if you have an upgraded hardy you probably should change this too, if it is not done automatically.

http://ubuntuforums.org/archive/index.php/t-705205.html

[Matt LaPlante (cybrmatt)]

Regardless of mlocate, this problem exists on servers as well. It also doesn't excuse shipping broken packages, whether they're the default or not.

[Akkana Peck (akkzilla)]

I hit this too: the slocate package installs a cron.daily script that fails (and sends error mail) unless mlocate is also installed. So shouldn't slocate have a package dependency on mlocate? Or should they be mutually exclusive?

[Matt LaPlante (cybrmatt)]

@Akkana: The slocate package should not depend on mlocate. mlocate was written after slocate, and designed to function identically (with the exception of the update algorithm used by updatedb) to it. Hence, they both use the same /etc/updatedb.conf file. The mlocate package is "complete" and includes this file as it should. The slocate package is simply broken because it does not include a copy of this file as well.

Using the version included with the mlocate package should work fine as a workaround, however it's important to know this is simply a side-effect of the packaging and not because there's a dependency there.

[Seth (bugs-sehe)]

I hit the problem too. I upgraded to hardy, reviewed the packages 'deinstalled' (get-selections) and thought: hey, don't junk slocate, I use that!

So I apt-get install slocate, but it won't fly:

sehe@sehe-desktop:/etc/alternatives$ sudo updatedb
sehe@sehe-desktop:/etc/alternatives$ slocate bla
slocate: fatal error: Could not find user database '/var/lib/slocate/slocate.db': No such file or directory

I think it is broken. For one, it could be symlinked (perhaps using update-alternatives). Furthermore, it should be documented somewhere. It was never on a list of 'these packages are no longer supported' when deciding to upgrade.

I'll have a look at mlocate, but I feel bad about having to 'magically' guess what new command to use instead of slocate

[Abel Cheung (abelcheung)]

It has been said very clearly that <a href="https://lists.ubuntu.com/archives/ubuntu-devel/2008-February/025065.html">slocate would be removed</a>. Don't expect anything to be 'fixed' if the intention is to drop it completely.

Though I have not much idea why the final result is to add mlocate instead. For those who need command line access, change your habit is the way to go. Or maybe symlink.

[Matt LaPlante (cybrmatt)]

I don't know what thread you were reading, but I didn't see anywhere in the conversation that you linked that slocate would be removed. The conversation focused mainly on the possibility of not shipping it by default in desktop installs. It didn't really even address server installations, nor did it at any point appear to reach a clear conclusion.

Regardless, just because something isn't part of the default install doesn't mean that it isn't supported any longer. The vast majority of the apt packages are not installed by default, but they're supported all the same. Any package whose maintainer is the Ubuntu Devs is bound to be kept up to some degree... if they really wanted to cease support for a product it would be removed altogether, which I've seen no evidence of.

mlocate has become preferable because the algorithm it uses to update its database is more efficient, resulting in less of a system penalty. It may or may not also be more well supported upstream (but I haven't checked lately).

In bash:
~# alias slocate='mlocate'

[Seth (bugs-sehe)]

Matt, i can see how you are trying to simplify the matter, and I appreciate it, because it *is* helping me understand what happens.

However, as a distro I think there is also the goal of not 'surprising' your users. Both me and Akkana have been raising (imho) very valid points where, from a usage experience, the operation of their system is *actually* broken, by upgrading to hardy, and maintaining slocate installed (nothing special in fact).

Now it may be true, that it *actually* shows a latent issue in the packaging of slocate. I don't think the argument is relevant here, though, as slocate was standard in all previous versions of all Ubuntu version I worked with, and only upgrading to Hardy (a supported operation!) breaks it.

So, at the least, it could be said that it slipped through release testing. No biggie, but I hope this again explains to *you* why you are getting uninterested responses if you (correctly) rationalize the problem away :)

Anyways, I consider this issue well-fixed, and I hope users/dev gap is a little more bridged on this one :)

[Christoph Lechleitner (lech)]

Abel Cheung wrote:
>For those who need command line access, change your habit is the way to go.
This ignorance against command line users is annoying, at best!

Matt Zimmerman wrote in that link mailing list message:
>Today, at least, it doesn't seem to be used, and more featureful indexed
>searching is provided by tracker, and the overhead of re-indexing daily can
>be inconvenient for laptop users.
Daily reindexing is not necessary!
For years we used to call updatedb on demand only.
As of laptop users (and not only them) the system load and power consumation and installation slowdown produced by trackerd and some other stuff (that scans the disc multiple time during installation) is much more disturbing than the simple filename scan of *locate!

Seth wrote:
>Anyways, I consider this issue well-fixed, and I hope users/dev gap is a little more bridged on this one :)
The issue is not fixed!
Althought the fix would be very very easy, the hardy package is still broken!
And hardy as a LTS is supposed to be maintained really well.

Unfortunately it gets more and more clear that Ubuntu's interpretation of the term "support" is a joke.

[Seth (bugs-sehe)]

Christoph Lechleitner wrote:
> Abel Cheung wrote:
>
>> For those who need command line access, change your habit is the way to go.
>>
> This ignorance against command line users is annoying, at best!
>
> Matt Zimmerman wrote in that link mailing list message:
>
>> Today, at least, it doesn't seem to be used, and more featureful indexed
>> searching is provided by tracker, and the overhead of re-indexing daily can
>> be inconvenient for laptop users.
>>
> Daily reindexing is not necessary!
> For years we used to call updatedb on demand only.
> As of laptop users (and not only them) the system load and power consumation and installation slowdown produced by trackerd and some other stuff (that scans the disc multiple time during installation) is much more disturbing than the simple filename scan of *locate!
>
> Seth wrote:
>
>> Anyways, I consider this issue well-fixed, and I hope users/dev gap is a little more bridged on this one :)
>>
> The issue is not fixed!
> Althought the fix would be very very easy, the hardy package is still broken!
> And hardy as a LTS is supposed to be maintained really well.
>
> Unfortunately it gets more and more clear that Ubuntu's interpretation
> of the term "support" is a joke.
>
>

No need to shout at another user, mate. That was just my opinion. I was
frustrated by this change just like you. I chose to 'bend' (change of
habit). I still hate it because I am regularly typing mlocate instead of
slocate on my few Feisty boxes left around. I'm sorry to hear that the
slocate package is still in a broken state. I see this thread as an
example how users are welcome to shed their light, tell their
frustrations etc. etc.

I don't think it is realistic to expect every single frustration to be
ironed-out. After all, we all have make priorities. It turns out Ubuntu
didn't share ours in this issue. Bugger. We still let them know. I know
for a fact that that helps Ubuntu devs to be aware of what users need.

Cheers,
Seth

[NicDumZ (nicdumz)]

It also affects updatedb , because updatedb and slocate -u have the same behavior.

An interesting thing to notice, however, is that even if a so-called fatal error is raised, the [ms]?locate database is still updated:
> locate bochs
> sudo updatedb
[sudo] password for [snip]:
updatedb: fatal error: load_file: Could not open file: /etc/updatedb.conf: No such file or directory
> locate bochs
/var/cache/apt/archives/bochs-x_2.3.7-1ubuntu1_i386.deb
/var/cache/apt/archives/bochsbios_2.3.7-1ubuntu1_all.deb
/var/cache/apt/archives/bochs-wx_2.3.7-1ubuntu1_i386.deb
/var/cache/apt/archives/bochs_2.3.7-1ubuntu1_i386.deb
[snip, lot of results]
>

I do not exactly know how the default behavior differs from the "custom" behavior intended with a correct /etc/updateconf.db but I would still state that the troubles caused by this bug seem to be minor...

[Fran Boon (flavour)]

Still seems to be an issue with a fresh install of Hardy with all updates applied.
Using just slocate on my server gives this error when cron task is run.
Workaround via:
touch /etc/updatedb.conf

[Matt LaPlante (cybrmatt)]

To summarize the situation:

The README.debian in slocate claims that "Secure Locate uses /etc/updatedb.conf which is packaged in 'findutils'. This file is not packaged with Secure Locate." That's all well and good, except evidence indicates that findutils no longer supplies /etc/updatedb.conf. From findutils-4.4.0/debian/changelog: "Drop misnamed /etc/updatedb.conf and include its contents in cron.daily file. (updatedb.conf only configured the cronjob, but not any invocation of updatedb.)"

The quick fix would appear to be simply installing the updatedb.conf that ships with slocate. I've created a package below which I believe will accomplish this.

slocate_3.1-1.1ubuntu4~4 is available in my PPA:
deb http://ppa.launchpad.net/cybrmatt/ubuntu intrepid main
deb-src http://ppa.launchpad.net/cybrmatt/ubuntu intrepid main

debdiff is attached

Please test.

[Arnaud Soyez (weboide)]

Matt, I tried the package from your PPA on my Hardy server, it worked perfectly well!

I had:
slocate:
  Installé : 3.1-1.1ubuntu3

and now:
slocate:
  Installé : 3.1-1.1ubuntu4~4

And here's some proofs (sorry for the French, dpkg went perfectly fine):
$ sudo dpkg -i slocate_3.1-1.1ubuntu4~4_amd64.deb
(Lecture de la base de données... 28869 fichiers et répertoires déjà installés.)
Préparation du remplacement de slocate 3.1-1.1ubuntu3 (en utilisant slocate_3.1-1.1ubuntu4~4_amd64.deb) ...
Dépaquetage de la mise à jour de slocate ...
Paramétrage de slocate (3.1-1.1ubuntu4~4) ...

$ sudo updatedb
$ locate updatedb.conf
/etc/updatedb.conf

[papukaija (papukaija)]

Is this bug fixed in Karmic? Should this bug be included in "One Hundred Paper Cuts" ?

[Matt LaPlante (cybrmatt)]

I believe slocate was last shipped in intrepid, so if you define fixed as
"it's not there at all", then yes.

[papukaija (papukaija)]

So should this bug marked as fix released/committed?

[papukaija (papukaija)]

Do we need to keep this bug open?

[Seth (bugs-sehe)]

papukaija wrote:
> Do we need to keep this bug open?
>
>
Not according to me. This was an upgrade issue for me (breaking my
scripts because of unannounced swtich from slocate to mlocate, breaking
slocate install as well).

There has been another distrelease since so....

Seth

[papukaija (papukaija)]

I'm closing this bug because there is no slocate package in Karmic as commented in comment 7.

[nairboon (nairboon)]

This bug is still open in Hardy, which is LTS.

[Colin Watson (cjwatson)]

My apologies that the Ubuntu team has taken so long to get around to dealing with this bug.

Matt LaPlante: Thanks for your patch! My feeling is that causing slocate to own /etc/updatedb.conf is probably not actually the best approach here. Doing that introduces questions of upgrade handling (as is often the case when files move between packages) which aren't easy to answer quickly. It might be the case that it all works out, but we'd have to consider dapper->hardy-updates, hardy->hardy-updates, hardy-updates->lucid, etc., and ideally for a stable update I'd prefer that we could say confidently that no such issues will arise.

Can I suggest using something like /etc/updatedb.conf.slocate instead, passing the appropriate -c parameter to slocate? This should be safer. I know it's a bit of a pain for the configuration file not to be the same as in other releases, but since its contents and package ownership vary anyway, and since this was already broken for hardy users who haven't followed our move to mlocate, I think this should be OK.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Phillip Susi (psusi)]

This package has been removed from Ubuntu. Closing all related bugs.

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".

[Seth (bugs-sehe)]

@r0lf I always wonder what it is that makes people suddenly find the time to close tickets like this.

Almost 7 years after they have been reported.

Of course it's no longer relevant. The bloddy package has even been removed over a year ago.

Thanks for the update though :) I hope it was a side effect of automatic bug db cleanup :)