Re: periodic daily takes a very long time to run (14-stable)

From: void <void_at_f-m.fm>
Date: Fri, 27 Oct 2023 15:24:58 UTC
Hi,

On Fri, Oct 27, 2023 at 11:01:03AM -0400, Paul Mather wrote:

>This doesn't affect the periodic daily run (to my knowledge) 

# ps x | grep periodic

59319 14  S+       0:00.00 grep periodic
27376 17  I+       0:00.00 /bin/sh - /etc/periodic/security/110.neggrpperm
27987 17  I+       0:00.00 /bin/sh - /etc/periodic/security/110.neggrpperm
43295 17  I+       0:00.00 /bin/sh - /usr/sbin/periodic daily
44018 17  I+       0:00.00 lockf -s -t 0 /var/run/periodic.daily.lock /bin/sh /usr/sbin/periodic LOCKED daily
44447 17  I+       0:00.01 /bin/sh /usr/sbin/periodic LOCKED daily
47348 17  I+       0:00.01 /bin/sh /usr/sbin/periodic LOCKED daily
47882 17  I+       0:00.00 /bin/sh /etc/periodic/daily/450.status-security
48386 17  I+       0:00.00 /bin/sh - /usr/sbin/periodic security
49217 17  I+       0:00.00 lockf -s -t 0 /var/run/periodic.security.lock /bin/sh /usr/sbin/periodic LOCKED security
49566 17  I+       0:00.01 /bin/sh /usr/sbin/periodic LOCKED security
51783 17  I+       0:00.00 /bin/sh /usr/sbin/periodic LOCKED security

It's been like this (110.newgrpperm) for 2hrs 16 mins

/etc/periodic/security/110.neggrpperm has the following line, which I've put
in quote marks (the quote marks are not present in the actual file)

"n=$(find -sx $MP /dev/null \( ! -fstype local \) -prune -o -type f \"

although I'm not certain, it suggests to me it's looking through the entire disk,
not excluding anything.

>You can tinker with the settings in /etc/locate.rc and add your ccache
>file system/directory to PRUNEPATHS in order to get the
>/usr/libexec/locate.updatedb indexing script to skip that hierarchy.

thank you for that tip I didn't know there was a locate.rc

I used to run 310.locate in daily.local long ago ;)

In this context though, there's no daily.local it's all standard.

--