Hi, se...@debian.org (2020-12-08 at 0109.08 +0100): > On Tue, Dec 08, 2020 at 01:04:07AM +0100, GSR wrote: > > And the ulimit line is missing, so when testing manually it fails with > > ---8<--- > > /some/dir/somewhere: Too many open files > > Hint: Try `ulimit -n 8192' or similar (current limit is 4096). > > --->8--- > > That's odd; it should do setrlimit() itself at startup (LimitNOFILE= > in the systemd unit is just to set the hard limit). How can ulimit > in the shell succeed but setrlimit() fail?
That bash ulimit call (just -n, without -H or -S) sets both hard and soft at the same time (see bash(1)), and as it is run as root, it can change to anything including beyond current hard. If setrlimit() only request a change of rlim_cur, hard will act as ceiling. > > When run for personal databases the solution must come from the > > binary, as users will not be able to raise limit beyond the hard > > number. > > updatedb isn't privileged, so it's no more able to raise the hard limit than > the user is. The solution I meant is "try working with less concurrently opened files" or something similar. I understand the concept beyond io_uring, but I have not checked any code, so maybe it can be asked to behave inside the limits, or the calling code must limit the requests or the processing of the answers, or maybe something else completly. mlocate seems to work fine with 1024 as limit (or 4096 if it is also raising soft to hard). I just tried to create a private db of the troublesome tree using "/usr/sbin/updatedb.plocate -l 0 -o /tmp/ploc.db -U /path/" and failed again. "/usr/bin/updatedb.mlocate -l 0 -o /tmp/mloc.db -U /path/" created the database without issues. I would need to use root to generate the plocate db for normal accounts (not good, even if I have access to root), or keep mlocate and convert. BTW, notice sbin vs bin. Also plocate-build is under sbin. They are supposed to be usable by normal accounts. Cheers, GSR
