Results 1 to 10 of 10

Thread: updatedb fails

  1. #1

    Default updatedb fails

    Hi,
    on opensuse 13.1 (x86_64) cron started to send me an error message a few days ago:
    Code:
    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.

    Does anyone have a solution?

    Best regards
    Bernd

  2. #2

    Default AW: updatedb fails

    Quote Originally Posted by BerndSpeiser View Post
    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.

    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).
    Last edited by wolfi323; 05-Apr-2014 at 04:25.

  3. #3

    Default Re: updatedb fails

    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?

    Best regards
    Bernd

  4. #4

    Default AW: Re: updatedb fails

    Quote Originally Posted by BerndSpeiser View Post
    Is there also a better (and long-lived) solution for this?
    Maybe something like this would work?
    Code:
    setfacl -d -m group::rwx /var/lib/mlocate/
    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...pecific-folder, haven't tried that myself.

  5. #5

    Default Re: updatedb fails

    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?

  6. #6
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: updatedb fails

    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)

  7. #7

    Default Re: updatedb fails

    Quote Originally Posted by BerndSpeiser View Post
    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?
    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).

  8. #8

    Default Re: updatedb fails

    Quote Originally Posted by wolfi323 View Post
    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, 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.

    Quote Originally Posted by wolfi323 View Post
    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).
    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 ...

  9. #9
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,109
    Blog Entries
    2

    Default Re: updatedb fails

    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).

    TSU

  10. #10

    Default Re: updatedb fails

    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
    Code:
    RUN_UPDATEDB_AS=""
    If this becomes
    Code:
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •