Hi,
on opensuse 13.1 (x86_64) cron started to send me an error message a few days ago:
running daily cronjob scripts
SCRIPT: output (stdout && stderr) follows
compress_ext is /usr/bin/xz
compress_ext was changed to .xz
SCRIPT: logrotate
------- END OF OUTPUT
SCRIPT: mlocate.cron exited with RETURNCODE = 1.
SCRIPT: output (stdout && stderr) follows
/usr/bin/updatedb: unexpected operand on command line
SCRIPT: mlocate.cron
------- END OF OUTPUT
Running /usr/bin/updatedb as root also gives the error message complaining about the “unexpected operand”. The cron file starting the daily update of the mlocate data base has been renewed during a recent on-line update.
You can of course just ignore the error message until the new update is out, if you don’t use locate very often (the locate database won’t get updated, so you won’t find new files of course).
thanks, I use locate quite often, so the data base should be up-to-date.
The change suggested helps -
updatedb runs with RUN_UPDATEDB_AS set to either root or nobody in /etc/sysconfig/locate. Before, the variable was empty (with quotes): RUN_UPDATEDB_AS="".
However, there is another problem with mlocate, that was intriguing me for a long time, but I had a workaround.
I have set my UMASK to 077, thus, when running updatdb the resulting /var/lib/mlocate/mlocate.db is read/writable for root (or user nobody, see variable RUN_UPDATEDB_AS above, and not accessible by a normal user.
My workaround was to have a command chmod 644 /var/lib/mlocate/mlocate.db in mlocate.cron, which overrides the UMASK for this particular file. Not nice, but working. If there is an update of mlocate, which brings in a new mlocate.cron, of course, my workaround disappears and the cron file has to be edited again.
Is there also a better (and long-lived) solution for this?
IIUIC, this should set the default permissions for new files in that directory to rwx for the owning group. If updatedb runs as nobody, you might want to use “other” instead of “group” I guess.
I got the idea from http://askubuntu.com/questions/44534/how-to-set-umask-for-a-specific-folder, haven’t tried that myself.
I know about setfacl, but unfortunately, this does not work.
If I set the file acl as you suggested, a run of the cron job still gives only rw for “nobody”, and no rights for group or other. Possibly, updatedb overrides the default acl?
On 2014-04-05 13:26, wolfi323 wrote:
>
> BerndSpeiser;2635172 Wrote:
>> Running /usr/bin/updatedb as root also gives the error message
>> complaining about the “unexpected operand”. The cron file starting the
>> daily update of the mlocate data base has been renewed during a recent
>> on-line update.
>>
>> Does anyone have a solution?
>>
> See https://bugzilla.novell.com/show_bug.cgi?id=861955#c21
> Setting RUN_UPDATEDB=“nobody” (which is the default) in
> /etc/sysconfig/locate should work as well I think.
I’ll have a look later at this (no time now), but just a comment: if you
are using mlocate, it should run as root, not nobody. It uses a
different control mechanism than the classical “locate”.
The idea is that when you run “mlocate” you only get results for the
files you do have access as that user, even if the database has
knowledge of other hits as some other user.
Running it as “nobody” would defeat the purpose. It is useful for me to
use “locate” as root to find a file sometimes.
Both “mlocate” and “locate” use the same app name, “locate”.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I don’t think so. How should it override the acl, especially if it is running as “nobody”?
But AFAICS in the source code, updatedb explicitely calls chmod on the db file according to the umask, so “rw-------” in your case.
I’m not sure if it’s possible to override that somehow.
Well, maybe create a separate cron job that changes the permissions every day (or even more frequently)?
I don’t have any other idea at the moment (except for changing the umask of course).
Well, I think, if it creates the file as nobody in /var/lib/mlocate, the default acl is used. If it calls chmod later according to the umask then it does what I am afraid of … and the default acl should not have an effect - and that explains exactly what I observe.
OK, that would at least take the chmod out of /etc/cron.daily/mlocate. Thanks, I could try that.
Still better were a way to convince updatedb NOT to use the umask permissions but some user defined value …
Am curious how the observed problems began in the fist place.
I’ve been using locate continuously in many openSUSE versions (including mlocate in 13.1) and have run it both as root and as an ordinary user without any noticeable differences (default configurations, no tweaking).
It started a few days ago, after I run an on-line update (which included an update of the mlocate package).
The variable RUN_UPDATEDB_AS in /etc/sysconfig/locate was set as
RUN_UPDATEDB_AS=""
If this becomes
RUN_UPDATEDB_AS=root
the problem disappears.
There was no problem on other systems I am using, that had root as the updatedb user alreday before the on-line update.