On Jan 11, 2012, at 4:08 PM, L. V. Lammert wrote: > On Wed, 11 Jan 2012, Philip Guenther wrote: > >>> Agreed, .. but if locate.update does NOT run as root, that would seem to >>> indicate some problem other than permissions. >> >> If you're saying what I think you're saying, then I disagree and think >> your logic is backwards. >> What user do you think locate.updatedb is run as? >> > If it does not run as root, then it isn't a permission issue as running as > root provides all required permissions, eh?
eh? "if it does not run as root. . . running as root provides. . ."?? To put it bluntly, if updatedb runs as root, it has all possible permissions. If updatedb does NOT run as root, it does NOT have all possible permissions. > I have never seen locate.updatedb fail when run as root (3.0 to 5.0, > actually), .. but, then, it isn't exactly 'failing', it just isn't > indexing anything except "/home". FWIW, I've never had a problem with locate since, oh, I think 2.6. But the point is, *IS* updatedb running as root? > The only other possible hypothesis, is that it is running out of memory; > one would expect some sort of error to be returned in that case and a > blank database as a result, not one partially populated. No, your logic is backward, as Philip has been gently pointing out. So, to diagnose your problem (regardless of release -- this is diagnosing 101 here): 1) Find out *EXACTLY* how updatedb is being called, and run it, except don't redirect errors to /dev/null or files or such. Check for error messages and/or exit codes 2) Since updatedb is a *SHELL SCRIPT*, try running it with -x (this breaks 1), of course). If the above is not enough for you to figure it out, email me off list and I'll help. But I don't have a 4.3 machine handy (I have a 4.6 and a 4.7 machine). Sean [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
