From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id BC5771580E0 for ; Fri, 31 Jan 2025 14:25:25 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (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) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id A6E1C34317F for ; Fri, 31 Jan 2025 14:25:25 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 2B7AC11047D; Fri, 31 Jan 2025 14:24:19 +0000 (UTC) Received: from smarthost01b.sbp.mail.zen.net.uk (smarthost01b.sbp.mail.zen.net.uk [212.23.1.3]) (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 bobolink.gentoo.org (Postfix) with ESMTPS id E8E0A1103B6 for ; Fri, 31 Jan 2025 14:24:17 +0000 (UTC) Received: from [82.69.80.10] (helo=cube.localnet) by smarthost01b.sbp.mail.zen.net.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tdrwJ-00BDhw-I9 for gentoo-user@lists.gentoo.org; Fri, 31 Jan 2025 14:24:15 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Protecting init.d files from auto-update Date: Fri, 31 Jan 2025 14:24:15 +0000 Message-ID: <23817797.6Emhk5qWAg@cube> In-Reply-To: <871pwjofsd.fsf@gmail.com> References: <2207251.irdbgypaU6@cube> <6124699.lOV4Wx5bFT@cube> <871pwjofsd.fsf@gmail.com> 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-smarthost01b-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: 2ccfa60c-3c74-4542-9056-db30c1ffaa37 X-Archives-Hash: 251aee23406209c1d6747132dd2c6581 On Friday 31 January 2025 02:53:06 Greenwich Mean Time Alexis wrote: --->8 > If you set `retry` in boinc.conf to, say, "SIGTERM/10/SIGKILL/20", > for a 10-second timeout in response to a SIGTERM signal and a > 20-second timeout in response to a SIGKILL signal, does that > reduce the stopping time? If so, to what duration? Hopefully > setting different timeout periods for different signals will mean > we can deduce what signals are being received from the stopping > duration. In the -r1 version, with SIGTERM/60/SIGTERM/30/SIGKILL/30, BOINC activity stopped immediately*, but control wasn't returned to me until 60s later. That is, the first SIGTERM was obeyed but the system didn't become aware of it until it sent the second SIGTERM. So, apparently, the boinc code needed a second prod to report back. Today I set retry="SIGTERM/4/SIGTERM/3/SIGKILL/3" on this machine, which only ever runs one BOINC task at a time. That process stopped straight away, but control didn't return to me until 7s after the 'boinc stop' command. That is, the first SIGTERM was obeyed, but this time the system didn't know until it sent the SIGKILL command, having apparently not seen any effect from the second SIGTERM. Does that mean the code needs longer between signals? To test that I changed the intervals to SIGTERM/8/SIGTERM/6/SIGKILL/4, then started and stopped boinc. Its Asteroids@Home process stopped within about 6s, but control didn't return to me until 14s. I deduce that the boinc management code is not reacting to signals properly. > Even if it does, it's a concern that the timeout limit is being > reached; it suggests that the boinc service isn't shutting down > gracefully in response to a SIGTERM, even after 60 seconds, > resulting in it needing to be forcefully terminated. Well, it does seem so now, but until I started all this it was stopping on the second SIGTERM. I could spend hours on establishing definitely what's going on, but I hope it doesn't come to that - for one thing, I only have the two machines to test on: an i5 NUC and a Ryzen M9. At the moment I'm content that my settings are not going to be overwritten with every upgrade of sci-misc/ boinc. Incidentally, I've been seeing "A new version of BOINC is available (8.0.2)." for some months in messages from the boinc manager. * 'tail -f /var/lib/boinc/stdoutdae.txt' showed boinc exiting instantly, and gkrellm showed CPU use dropping to zero. It's hard to be definite about what /bin/top shows, as it only updates every 3s, gkrellm every 2s. That caveat applies to all the times I've mentioned in this thread. -- Regards, Peter.