From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9948D15813A for ; Tue, 14 Jan 2025 16:31:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 290F4E0831; Tue, 14 Jan 2025 16:31:49 +0000 (UTC) Received: from smarthost01c.sbp.mail.zen.net.uk (smarthost01c.sbp.mail.zen.net.uk [212.23.1.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E0394E07D7 for ; Tue, 14 Jan 2025 16:31:48 +0000 (UTC) Received: from [82.69.80.10] (helo=cube.localnet) by smarthost01c.sbp.mail.zen.net.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tXjpQ-001lwk-4P for gentoo-user@lists.gentoo.org; Tue, 14 Jan 2025 16:31:47 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Protecting init.d files from auto-update Date: Tue, 14 Jan 2025 16:31:47 +0000 Message-ID: <2227042.irdbgypaU6@cube> In-Reply-To: <1992899.PYKUYFuaPT@rogueboard> References: <2207251.irdbgypaU6@cube> <1992899.PYKUYFuaPT@rogueboard> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-Originating-smarthost01c-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: e4091190-17be-41c9-9e8c-3d8b60b8836a X-Archives-Hash: 3a54d1c17dc34038d170df37d73b05cd On Tuesday 14 January 2025 12:01:02 Greenwich Mean Time Michael wrote: > I am not familiar with the BOINC application. Is the program taking a long > time to stop because it is completing whatever calculation it was processing > and then have to store/upload the result and its current status before it > shuts down? If not, then I agree 60 seconds is a long time to wait. > > I've tried adding the file to CONFIG_PROTECT in make.conf, to no avail. No, it isn't that. All BOINC operations are local on the machine. Each project runs its calculations on its batch of downloaded data, then sends the result back. Each batch may take from many minutes to several days, even on a powerful machine. The stop function has this, as Michael O. says: local stop_timeout="SIGTERM/60/SIGTERM/30/SIGKILL/30" It's just setting arbtrary times by which SGTERM should have stopped the program. In practice, the first SIGTERM is ignored, or otherwise fails, but the second one succeeds. Those periods are far too long here. > The existing CONFIG_PROTECT in /usr/share/portage/config/make.globals ought > to protect unwanted changes. Have you inadvertently set > CONFIG_PROTECT_MASK somewhere? Make.conf includes settings of both CONFIG_PROTECT and CONFIG_PROTECT_MASK. It's assuming that init scripts should never be customised to suit local conditions, but that assumption is unhelpful in this case. And changing the order of those entries makes no difference either: the mask takes precedence. -- Regards, Peter.