Re: periodic daily takes a very long time to run (14-stable)
- Reply: void : "Re: periodic daily takes a very long time to run (14-stable)"
- Reply: void : "Re: periodic daily takes a very long time to run (14-stable)"
- Reply: void : "Re: periodic daily takes a very long time to run (14-stable)"
- In reply to: void : "Re: periodic daily takes a very long time to run (14-stable)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 27 Oct 2023 15:38:58 UTC
On 27/10/23 17:24, void wrote: > 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. If this script is the culprit is easily tested, disable it and see. I guess you can stay a few days without checking for negative permissions. Also, $MP is defined in such a way to exclude filesystems that set "nosuid/noexec". I do happen to have those setup for my ccache directory so it is skipping that. With zfs it is especially easy to set these flags, and I think having noexec/nosuid/nodev for ccache cache is a good practice anyway. I have this for ccache FS (zfs): dumpster/ccache compression lz4 inherited from dumpster dumpster/ccache atime on local dumpster/ccache devices off local dumpster/ccache exec off local dumpster/ccache setuid off inherited from dumpster -- Guido Falsi <mad@madpilot.net>