Re: periodic daily takes a very long time to run (14-stable)
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. --