A lot of people use laptops like mobile phones, they use it mostly being on
battery and plug it over night, when the device is turned off, or when battery
level is really down. Then most likely the laptop is on battery when the
plocate update job is due. If you are on battery, systemd services with
ConditionACPower=true do silently nothing, the job is not started and there is
only a minor log notice about it which will go unnoticed most likely. As
plocate is really fast, remove ConditionACPower=true from
plocate-updatedb.service.in.
A variety of sandboxing options, as long as they do not introduce bind
mounts. (Bind mounts cause problems, as noted in commit 1acc100b09, so
leave out ProtectSystem= and a few other options.) The system call
filter is relatively broad, so it will hopefully not break things.
(@chown and CAP_CHOWN are needed because the updater fchown’s the
database file.)
CAP_DAC_READ_SEARCH and CAP_CHOWN together are unfortunately mostly
equivalent to CAP_DAC_OVERRIDE, in that the updater can access any file,
chown it to itself, and then write to it. Users who do not need
--prune-bind-mounts support may wish to enable ProtectSystem=strict
(together with ReadWritePaths= or an equivalent option to make the
database file writable again). But at least this still filters out a lot
of other capabilities.
On my workstation, plocate-updatedb often starts right after waking up
from suspend in the morning, consuming a lot of CPU time and slowing
down other running processes. Mitigate this by specifying a low
scheduling priority in the unit file.
For reference, man-db's unit file does the same:
0df248b30b/init/systemd/man-db.service.in (L13)
Signed-off-by: Ondrej Mosnáček <omosnacek@gmail.com>
This reverts commit 6e7991e5e0.
David Caldwell pointed out that this breaks prunepaths that are not
directly on the root, since we now get /b before /a/a and this breaks
the expectation that the prunepaths list is iterated through in order.
This should fix https://bugs.debian.org/1055450, where /home and
/run/schroot/mount/<something>/home were found to be duplicates
and the latter had the lower ID, but then /run was pruned out
and there was no indexing of the directory at all.
We can still see things like this in the form of prunepaths,
I believe.
This makes sure we never even try to enter a directory if it is
in prunepaths (much like we already do with prunenames).
Inspired by https://bugs.debian.org/1025099, although it doesn't
fix that issue (we still open it before checking prunefs).
This is mostly useful in the case where you are root, but the directories
in question no longer exist (or were never there to begin with) and you
still want to search in the database, or dump all of it using plocate ''.
Obviously, this needs to drop the sgid flag like --debug already does,
so we do that.
Using this together with -e/--existing doesn't make any sense,
but we don't have any explicit checks for it.
The previous configuration caused the updatedb timer to run
potentially in the late morning. However this should be avoided to not
affect normal users. Furthermore, the low setting of AccuracySet to
20m caused a low chance of systemd to coalesce the updatedb timer with
other timers.
Increase the AccuracySec to 6h so that systemd is more likely to be
able to coalesce the timer with others in an effort to optimize power
consumption.
Furthermore, lower RandomizedDelaySec to 1h, to ensure that the
plocate updatedb job runs before 07:00 in the morning (and after
midnight).
Cf. https://lwn.net/Articles/947941/, not escaping - will change
e.g. “plocate-build” to “plocate(Unicode dash)build”, which breaks
cut-and-paste. We had this right most places, but not all.
As of liburing 2.4-to-be, liburing has ceased using malloc for its
probe allocations: it's concealed behind layers of confusing macros,
but io_uring_get_probe_ring() doesn't actually use libc's malloc
but ratehr its own __uring_alloc/__uring_free functions. So it no
longer works to free() the return value of io_uring_get_probe_ring():
you have to use io_uring_free_probe() instead.
I am going to report this to liburing upstream as a possible bug,
but it is easy to work around in plocate in any case.
* plocate.1: Document this new behavior.
* plocate.cpp (do_search_file, main): Exit with code 1 if no matches were found.
This behavior is consistent with that of mlocate except with --limit=0, which
plocate rejects.
This helps compatibility with certain configurations of musl libc.
Note that the output format on updatedb.conf errors will change somewhat,
and only the first one will be reported followed by immediate exit
(unlike earlier, where all updatedb.conf errors would be output before exit).
Based on a patch by Alfred Persson Forsberg.
