/etc/periodic/weekly/310.locate failing

[Glorious1]

Since the man pages were added to FreeNAS, I noticed now an email about the whatis database being built on Saturday morning. I think that is part of the weekly periodic scripts. Another one is the locate database.

I do have a whatis database now, but no locate database (should be in /var/db/locate.database) and the locate command doesn't work. When I try to run directly as root the script that builds the locate database, I get what is apparently an error:

# source /etc/periodic/weekly/310.locate
if: Expression Syntax.

Does anyone understand what's going on here?

 

[dlavigne]

Does running /usr/libexec/locate.updatedb give the same error? This is the typical method for manually updated the db.

Please create a feature request asking that those scripts run again (as well as mention the error so that script can be reviewed). The locate and whatis db maintenance scripts were disabled ages ago due to the limited boot size but this is no longer an issue.

 

[Glorious1]

Feature #8781

Thanks - I did try running /usr/libexec/locate.updatedb, but it will only run as root, and then you get a warning that everything on the server will be visible to anyone running locate, which is not what I want. The script somehow is supposed to run it as "nobody" so only public stuff gets added to the database.

 

[Glorious1]

Apparently locate is broken intentionally and "not to be fixed". The locate database can become very large in some circumstances and it currently resides on the boot device.

 

[cyberjock]

And yet another problem BECAUSE we added those Mother f*#^*$ manpages.... /disgusted

 

[Glorious1]

:p Well, I don't get the connection between man pages and periodic weekly tasks like whatis and locate. In fact, I don't get what the deal is about putting the whole system on a little flash drive. Why don't we just put it on a hard drive like almost every other operating system on the planet? Seems every time you turn around you hear "no, can't do that, it would take too much space on the boot device".

 

[Glorious1]

Oh, another change that accompanied this - Now all attached disks are spun up daily at 3 am - presumably some new periodic daily task. Another foil for those who prefer to sleep some disks.

 

[cyberjock]

Seems every time you turn around you hear "no, can't do that, it would take too much space on the boot device".

We don't say that anymore. The problem with disk space is not a problem with 9.3+.

Oh, another change that accompanied this - Now all attached disks are spun up daily at 3 am - presumably some new periodic daily task. Another foil for those who prefer to sleep some disks.

Well, I can't say I didn't tell people that they can bend the OS however they want, but don't be surprised when upgrades keep breaking yo' shiz.

 

[Glorious1]

We don't say that anymore. The problem with disk space is not a problem with 9.3+.

Except that's the reason they won't enable the locate database - it could get too big.

 

[cyberjock]

Except that's the reason they won't enable the locate database - it could get too big.

Well, yeah. It's trivial to get a multi-GB database if you have 100s (or 1000s) of TB of data. And some people *do* have that much space. I've even worked on one server that had over 4 billion files. We figured this out because NFS doesn't like working with more than 4.2 billion files. Whoops!

So yes, this is a bit of an exception to the rule because the externalties (the pool's file system) can grow to enormously large sizes.

Honestly, I'm doubting even a database of 4.2 billion files would necessarily produce an excessively large database. But, depending on the performance of the pool and such, creating that database could be potentially damaging to the performance of a sufficiently large but sufficiently underresourced or overworked server. Add in the fact that, for the most part, the whole idea of the locate command isn't too terribly useful for most users as the locate database doesn't tie into CIFS, NFS, iSCSI, or AFP, and most of its usefulness disappears. Don't get me wrong, it *can* be useful, for very specific situations. I've used it a bit. But you and I are the exception, not the norm. If the locate database worked with CIFS I have no doubt it would be setup to work with settings in the WebGUI. :P

 

[Alvin]

Let's test this! I do use the locate(1) command quite frequently.

Fearing to fill the boot partition, I symlinked /var/db/system/locate.database to /var/db/locate.database and started locate.updatedb(8).
(On reboot, the symlink will be gone of course, but it's only for testing.)
On a system of > 9.5 million files, this results in a database of 46M!

Of course, the .system volume uses lz4 compression by default. The real size is 46M, but it probably uses less.

 

[Glorious1]

Yes I tried it too and it was only 1.5 MB. But I deleted it because I don't know how to build it except as root, and then you get a security warning.