Re: September 2024 stabilization week
- In reply to: Simon J. Gerraty: "Re: September 2024 stabilization week"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 01 Oct 2024 21:23:00 UTC
On Sun, Sep 29, 2024 at 09:42:17AM -0700, Simon J. Gerraty wrote: S> Michael Butler <imb@protected-networks.net> wrote: S> > > I have found that *only* on arm64, locate errors like so: S> > > S> > > # sh /etc/periodic/weekly/310.locate S> S> This runs /usr/libexec/locate.updatedb as nobody S> and ensures that /var/db/locate.database exists and is owned by nobody, S> but /var/db itself is root:wheel and 755 so the error from install does S> not seem surprising. S> S> Though that begs the question of how this ever works ;-) The way it always worked is that /var/db/locate.database always exists and is owned by nobody. This is done by the periodic job before soing su: locdb="$FCODES" touch "$locdb" && rc=0 || rc=3 chown nobody "$locdb" || rc=3 chmod 644 "$locdb" || rc=3 After that it runs su: echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3 Before f62c1f3f8e91 the file was installed with cat(1): cat $tmp > $FCODES # should be cp? After f62c1f3f8e91 the install(1) is used. The latter is designed to use a temporary file to avoid race conditions. But we can create a temporary file in /var/db when we are nobody. I'm going to change this line back to cat(1) in a week unless Dag-Erling responds. -- Gleb Smirnoff