On 2022/10/19 09:47, Stuart Henderson wrote:
> On 2022/10/19 01:38, Theo Buehler wrote:
> > > The main part I want feedback on is a new patch that silently treats the
> > > dynamic_shared_memory_type = posix as dynamic_shared_memory_type = shm.
> > > Since 15beta1, I had an issue where the PostgreSQL server would stop
> > > working after a week.  I traced that issue to OpenBSD deleting the
> > > shared memory files in /tmp that shm_open(3) creates, since they were
> > > more than a week old.  Possibly this is only an issue on lightly loaded
> > > servers, but unless daily(8) skips deleting these files automatically, I
> > > consider the approach the patch uses necessary for reliable operation.
> > 
> > I think a patch that extends the list before -prune in daily(8) with
> > './*.shm' would be perfectly acceptable. I'd ok it once it's tested.
> 
> Since the decision to put these "files" in /tmp is OpenBSD's
> (see libc/gen/shm_open.c) it should definitely be handling them
> automatically in the system scripts.

It needs to be after the -prune, as that acts only to trim the
tree descended for the conditons after the "-o".

OK?


Index: daily
===================================================================
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.95
diff -u -p -r1.95 daily
--- daily       20 Oct 2020 22:42:29 -0000      1.95
+++ daily       19 Oct 2022 12:10:56 -0000
@@ -49,8 +49,8 @@ if [ -d /tmp -a ! -L /tmp ]; then
        cd /tmp && {
        find -x . \
            \( -path './ssh-*' -o -path ./.X11-unix -o -path ./.ICE-unix \
-               -o -path './tmux-*' \) \
-           -prune -o -type f -atime +7 -delete 2>/dev/null
+               -o -path './tmux-*' \) -prune -o \
+           -type f -and ! -path './*.shm' -atime +7 -delete 2>/dev/null
        find -x . -type d -mtime +1 ! -path ./vi.recover ! -path ./.X11-unix \
            ! -path ./.ICE-unix ! -name . \
            -delete >/dev/null 2>&1; }


> (I'm not entirely convinced /tmp is a great place to store them
> but I don't really have a better idea. On most Linux they use
> a separate /dev/shm ramdisk but I don't think adding a new fstab
> entry for a libc requirement is going to work out for us!)

...also, changing the path would require auditing ports for unveil.

Reply via email to