On Sat, Mar 15, 2025 at 03:11:45PM +0100, Paul Slootman wrote:
Hi,
> > > > > > I suggest that the default configuration be changed thusly:
> > > > > >
> > > > > > TMPREAPER_PROTECT_EXTRA='/tmp/user/[0-9]*'
> > > > > > TMPREAPER_DIRS='/tmp/. /tmp/user/*/.'
> > > > >
> > > > > TMPREAPER_DIRS is the list of directories to search for old files, so
> > > > > only the TMPREAPER_PROTECT_EXTRA list is what you want.
> > > >
> > > > Even if /tmp/user (or a particular subdir under /tmp/user) is a
> > > > mountpoint?
> > >
> > > tmpreaper stays on the filesystem(s) the TMPREAPER_DIRS are on.
> > > So if /tmp/user is a separate filesystem, you don't need to protect it
> > > anyway as tmpreaper won't go there, unless you do specify /tmp/user/*/*
> > > but I thought the point of this bug report was _not_ to delete stuff
> > > under /tmp/user/* . If you do also want to remove files under /tmp/user/
> > > that don't start with a digit, then sure, then it also needs to be added
> > > to TMPREAPER_DIRS. Please let me know what the exact intention is.
> >
> > The intention is to have tmpreaper descend /tmp/user/^[0-9]+$/ and delete
> > old files in there in the same way files under /tmp itself are deleted, BUT
> > not to delete the /tmp/user/^[0-9]*$ directories themselves even if they
> > are "old"; whether /tmp/user or any particular /tmp/user/^[0-9]+$/ is a
> > mountpoint or not.
>
> OK, thanks for clarifying.
>
> > The problem this solves is that if a long-running process is started with
> > TMP=/tmp/user/4242 and it tries to create its first tempfile months after
> > it was started, its individual tmp directory will have been reaped by
> > tmpreaper, causing the tempfile creation to fail.
> >
> > (Yes, I used regexes instead of proper glob patterns.)
>
> Hmm the problem is that tmpreaper only does glob.
> The additional problem with supplying /tmp/user/*/. per default with
> TMPREAPER_DIRS is that if those files don't exist, tmpreaper will give
> an error as it can't chdir to that.
>
> I think that I will leave this as a local configuration change when
> needed.
>
> In light of this, does adding /tmp/user/[0-9]* to
> TMPREAPER_PROTECT_EXTRA anyway make sense?
This is what I use locally:
# TMPREAPER_DIRS must exist, otherwise the cronjob aborts with an error
install -d -o root -g root -m 711 /tmp/user
install -d -o root -g root -m 700 /tmp/user/0
TMPREAPER_PROTECT_EXTRA=''
TMPREAPER_DIRS='/tmp/.'
set +f # /etc/cron.daily/tmpreaper sets "-f", which prevents wildcard expansion
for i in /tmp/user/[0-9]*; do
TMPREAPER_DIRS="$TMPREAPER_DIRS $i/."
TMPREAPER_PROTECT_EXTRA="$TMPREAPER_PROTECT_EXTRA $i"
done
TMPREAPER_DELAY='256'
TMPREAPER_ADDITIONALOPTIONS=''
[ -r /etc/tmpreaper.local.conf ] && . /etc/tmpreaper.local.conf
set -f
(The tmpreaper.local.conf bit is there because I distribute the main file
using ansible and may want local overrides here and there.)
It's fugly, but works well enough for my particular use case. I haven't
thought much about further implications.
It's obviously racy (one of the per-user dirs could be deleted by something
else while tmpreaper works, so that one of the TMPREAPER_DIRS would not
exist), but since this will just cause an abort and presumably succeed on
the next run, it doesn't seem so bad. It would be better if tmpreaper could
be told to treat certain TMPREAPER_DIRS as optional.
András
--
I spilled spot remover on my dog, and now he's gone!
