Date: Fri, 27 Oct 2023 17:38:58 +0200 From: Guido Falsi <mad@madpilot.net> To: freebsd-stable@freebsd.org Subject: Re: periodic daily takes a very long time to run (14-stable) Message-ID: <767774d4-50b5-47c8-9cf1-c0c99fe33e00@madpilot.net> In-Reply-To: <ZTvWSoCykzPzFKuw@int21h> References: <ZTuNvVMW_XG3mZKU@int21h> <1122335317.4913.1698407124469@localhost> <ZTuyXPjddEPqh-bi@int21h> <794932758.6659.1698413675475@localhost> <ZTvMODY-mcBImHZP@int21h> <8a5c1f89eb5842f20e463c7d60538e598da3bc46.camel@gromit.dlib.vt.edu> <ZTvWSoCykzPzFKuw@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?767774d4-50b5-47c8-9cf1-c0c99fe33e00>