From nobody Fri Oct 27 16:38:34 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SH7dr25y0z4yRHY for ; Fri, 27 Oct 2023 16:38:40 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SH7dq3vY6z3QLN for ; Fri, 27 Oct 2023 16:38:39 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=Hj5rtu3O; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=IDd+pRyT; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.28 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F08145C01DA for ; Fri, 27 Oct 2023 12:38:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 27 Oct 2023 12:38:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1698424718; x=1698511118; bh=Dm 5dIRB5HkLCe+x7bbyBxe4odAOHz1zlBMlvjhIwqk4=; b=Hj5rtu3OHoy2MQyvJP 1L/9QNp8k6y8/BuBQGQMe773i1MO/3aw75GFx50cstQ1aTuqUJAGuLoJ1OBYLgFI yBJ2xQM0ab6SuF2AZQMfdA/tUVQBXxY9B5htGpSGGWWwtq0DZ3lbzxg5QMxV2eDu kwNH+8LU2Q3+CNCYfItI6LUsS4IYbp7YTZem4KwyXBzd6ETRPYU7RCBU9HhgrJyy iAlL00V5Pr26Z+snGijy9Yw39ELe2wvMcsea6J+r2ez+O0d+X6mxqLZLTxuTnokz cfFttHzHLljn1kfF4dwBDeGITYIn1qznERD7tmzPxpqMHiRgXQz9/mEkJFvjDogg swWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1698424718; x=1698511118; bh=Dm5dIRB5HkLCe +x7bbyBxe4odAOHz1zlBMlvjhIwqk4=; b=IDd+pRyTgpqGx35Hcr7/l1Mb1Ws7x scI+zv/8ms6Me8iEubF9l+aHwQjtW0PDnxcuQCrg+K17xlPj1avL3MMJrFVLZjuo DVELmy/tNPRFKWL1xy/ryRB5Pvn2TKWu8sOkrC79pljAhoMINO+Bmorhh6/J3J8+ Jn6dYLQZhz2dS9gptyrn6vu66Hp2K1YhEGgysoQIx10cZ3CiMaPkn390DLhWvqju og8kbjCBATUvA+dTCQyOuGo7FlUBm+htDnjzCWrx03QAVzgjotXDSdYzbJLMNtw8 Lpc6J1ybDiNVMvOCmBJkQZKdflVz7/03d7sRWwjzgyb3aQo0oMxtURyTw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleeggddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepteetvdeihfegueevheefveduleelvdelvdffvdegheekhefhheetgfdtud fgkeejnecuffhomhgrihhnpegtohhrvgdrshhonecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 27 Oct 2023 12:38:38 -0400 (EDT) Date: Fri, 27 Oct 2023 17:38:34 +0100 From: void To: freebsd-stable@freebsd.org Subject: Re: periodic daily takes a very long time to run (14-stable) Message-ID: Mail-Followup-To: freebsd-stable@freebsd.org References: <1122335317.4913.1698407124469@localhost> <794932758.6659.1698413675475@localhost> <1210534753.8409.1698420229888@localhost> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1210534753.8409.1698420229888@localhost> X-Spamd-Result: default: False [-4.68 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.98)[-0.980]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.28:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[66.111.4.28:server fail]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SH7dq3vY6z3QLN X-Spamd-Bar: ---- On Fri, Oct 27, 2023 at 05:23:49PM +0200, Ronald Klop wrote: >Well. You could remove daily_clean_disks_enable="YES" from /etc/periodic.conf. >That saves you the "find". I have never used it before. The default is "off". Yes, I'll try that, but it's a very recent addition. The periodic daily problem is something thats been happening since even before the machine went from 13-stable to 14-stable. The addition of daily_clean_disks has made a bad problem worse, because rather than the problem happening for ~1 hour it happens for 3. periodic daily should be finished soon, it's moved onto /usr/local/etc/periodic/security/460.pkg-checksum edit: it finished, took exactly 3 hrs: # date && periodic daily && date Fri Oct 27 13:40:15 BST 2023 Fri Oct 27 16:40:14 BST 2023 >The list of files it checks for doesn't look very useful to me in 2023. >This does do a full find over *all* directories and files. *every day* ??? yeah that was sort of my reaction. I've not looked yet for a monthly-clean_disks where I could define an exclude pattern for things like ccache. That to me would be useful. The reason it was enabled was no more than a "sounds like a good idea" variable to enable on a machine that is presently used mainly for poudriere, which can tend to generate a lot of core consequential to pkg build failures etc. >If you have a lot of *.core files you are better of putting this in >sysctl.conf: kern.corefile=/var/tmp/%U.%N.%I.%P.core . >So you know where to look to delete them. >Actually my RPI3 has this in cron: @daily find /var/tmp/ -name "*.core" -mtime +7 -ls -delete . thanks for these, have implemented both >That is pretty heavy for you setup if you manage to run things in parallel as the RPI4 >has 4CPUs. PARALLEL_JOBS=1 TMPFS=ALL # with excludes for things like llvm & rust & gcc >It doesn't help to run daily_cleanup together. ;-) Before I started asking about the issue, what I was trying to address/work around was that sometimes (if for example the poudriere run went over 24 hrs) it would run into periodic daily. This caused problems before I made it worse by adding daily cleanup LOL Now to test periodic daily without daily cleanup... How long does yours take? --