From unknown Mon Jun 23 06:03:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74284: Shepherd does not respect ordering for one-shot? services Resent-From: Tomas Volf <~@wolfsden.cz> Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 09 Nov 2024 16:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 74284 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 74284@debbugs.gnu.org X-Debbugs-Original-To: bug-guix@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.173117120918974 (code B ref -1); Sat, 09 Nov 2024 16:54:02 +0000 Received: (at submit) by debbugs.gnu.org; 9 Nov 2024 16:53:29 +0000 Received: from localhost ([127.0.0.1]:54271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9oiG-0004vy-OD for submit@debbugs.gnu.org; Sat, 09 Nov 2024 11:53:29 -0500 Received: from lists.gnu.org ([209.51.188.17]:45350) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <~@wolfsden.cz>) id 1t9oiE-0004vn-Bl for submit@debbugs.gnu.org; Sat, 09 Nov 2024 11:53:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <~@wolfsden.cz>) id 1t9oiD-0002Ug-9t for bug-guix@gnu.org; Sat, 09 Nov 2024 11:53:25 -0500 Received: from wolfsden.cz ([37.205.8.62]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <~@wolfsden.cz>) id 1t9oiB-0001nR-0E for bug-guix@gnu.org; Sat, 09 Nov 2024 11:53:25 -0500 Received: by wolfsden.cz (Postfix, from userid 104) id EDE7E313920; Sat, 9 Nov 2024 16:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1731171199; bh=VFAIZgWoKEanmK9eTdDIL6rTl1SDA2/lNkLCHfibBME=; h=From:To:Subject:Date; b=GQB3ZFjP4Fzhd63AxyHDewh8KceiW9zvBoHaLUN++3Q95q2EktN0M911rUQpCTNO4 PpWAMLnMj5gyp+k/ChYtCWLjwcj351PCiYreDe67pfj4pd5n/udKHGjA6baDY4vlqP rM+jaieAQxiUufZ6Ulhlf+3RL6BViYPXv1NWpTexS5HhU8HTIsOS9i8Dw+Hw6aB0o4 9Pw5ixs+mYMb/fJKF/F2wLb8PEmP8PpVLeNrpv+mVr2vbr0LWmb085KymUxXoUHmyi OxOGMDv9jbDu8yHq7n6SOHVCi9AjrnWSmA9Jm4OGaX1TX4+NOApPa8k6grbjy3yrzv yauU7rJeW+Nm4M7YoD2SHtmo9TPkBs/pUW/+jCVQBWHWv1iUYMYUoqEk8a+tGYNg4U D5tmQWuXu9zhAsZq3qx9n98wwEeZv53xl9afZ6oGTCysX9ro7XkDu6aTA4P7PEyHS6 BCJwMCFqFI70l4X10XmzsrOVBrbpZKSerRO5QwlzxZQTDrvbFqKeTqPjGocGPxxhkU DtXCto4XbY5cKMHuYlcVzSn4WRRq/8ozIi7kw0edu5kFoXBM2ARDH9aC7vgAtFtDdD rMtKteWNiDL+PbhIhvCmEIN1ZSTYRosUYOYvIUZF3KZ3K/90eRj+Xd8bwspbLmqHH8 woRPTJ2+8M03K+37kpQdQTtA= X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from localhost (unknown [128.0.188.242]) by wolfsden.cz (Postfix) with ESMTPSA id 1BC1031359C for ; Sat, 9 Nov 2024 16:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1731171199; bh=VFAIZgWoKEanmK9eTdDIL6rTl1SDA2/lNkLCHfibBME=; h=From:To:Subject:Date; b=GQB3ZFjP4Fzhd63AxyHDewh8KceiW9zvBoHaLUN++3Q95q2EktN0M911rUQpCTNO4 PpWAMLnMj5gyp+k/ChYtCWLjwcj351PCiYreDe67pfj4pd5n/udKHGjA6baDY4vlqP rM+jaieAQxiUufZ6Ulhlf+3RL6BViYPXv1NWpTexS5HhU8HTIsOS9i8Dw+Hw6aB0o4 9Pw5ixs+mYMb/fJKF/F2wLb8PEmP8PpVLeNrpv+mVr2vbr0LWmb085KymUxXoUHmyi OxOGMDv9jbDu8yHq7n6SOHVCi9AjrnWSmA9Jm4OGaX1TX4+NOApPa8k6grbjy3yrzv yauU7rJeW+Nm4M7YoD2SHtmo9TPkBs/pUW/+jCVQBWHWv1iUYMYUoqEk8a+tGYNg4U D5tmQWuXu9zhAsZq3qx9n98wwEeZv53xl9afZ6oGTCysX9ro7XkDu6aTA4P7PEyHS6 BCJwMCFqFI70l4X10XmzsrOVBrbpZKSerRO5QwlzxZQTDrvbFqKeTqPjGocGPxxhkU DtXCto4XbY5cKMHuYlcVzSn4WRRq/8ozIi7kw0edu5kFoXBM2ARDH9aC7vgAtFtDdD rMtKteWNiDL+PbhIhvCmEIN1ZSTYRosUYOYvIUZF3KZ3K/90eRj+Xd8bwspbLmqHH8 woRPTJ2+8M03K+37kpQdQTtA= From: Tomas Volf <~@wolfsden.cz> Mail-Followup-To: bug-guix@gnu.org Date: Sat, 09 Nov 2024 17:53:18 +0100 Message-ID: <87ses073i9.fsf@wolfsden.cz> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=37.205.8.62; envelope-from=~@wolfsden.cz; helo=wolfsden.cz X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hello, I think I found a bug in the GNU Shepherd. Dependencies between one-shot? #t services do not seem to be respected. Documentation for #:requirement says the following (emphasis mine): --8<---------------cut here---------------start------------->8--- #:requirement is, like provision, a list of symbols that specify services. In this case, they name what this service depends on: before the service can be started, services that provide those symbols *must be started*. Note that every name listed in #:requirement must be registered so it can be resolved (see Service Registry). --8<---------------cut here---------------end--------------->8--- Documentation for #:one-shot? says the following: --8<---------------cut here---------------start------------->8--- Whether the service is a one-shot service. A one-shot service is a service that, as soon as it has been successfully started, is marked as =E2=80=9Cstopped.=E2=80=9D Other services can nonetheless require one-shot services. One-shot services are useful to trigger an action before other services are started, such as a cleanup or an initialization action. As for other services, the start method of a one-shot service must return a truth value to indicate success, and false to indicate failure. --8<---------------cut here---------------end--------------->8--- Nothing in there seems to mention that one-shot? services do not actually wait on each other. To reproduce I wrote a simple configuration file: --8<---------------cut here---------------start------------->8--- (define %one-shot #f) (use-modules (srfi srfi-1)) (define (make-waiting-service name wait requirement) (service (list name) #:requirement requirement #:start (=CE=BB _ (sleep wait) (format #t "~a\n" name) #t) #:one-shot? %one-shot)) (let ((svcs (pair-fold (=CE=BB (names waits svcs) (cons (make-waiting-service (car names) (car waits) (cdr names)) svcs)) '() '(a b c d) '(1 2 3 4)))) (register-services svcs) (start-in-the-background (map service-canonical-name svcs))) --8<---------------cut here---------------end--------------->8--- Each service sleeps for `wait' seconds to simulate some slow work being done. In effect that means that each of the services takes different time to start up. Now, when we run it as it is, we get the following (correct) output: --8<---------------cut here---------------start------------->8--- $ shepherd -c conf.scm Starting service root... Service root started. Service root running with value #t. Service root has been started. Configuration successfully loaded from 'conf.scm'. Starting service d... d Service d has been started. Service d started. Service d running with value #t. Starting service c... c Service c has been started. Service c started. Service c running with value #t. Starting service b... b Service b has been started. Service b started. Service b running with value #t. Starting service a... a Service a has been started. Service a started. Successfully started 4 services in the background. Service a running with value #t. --8<---------------cut here---------------end--------------->8--- Notice the start-up order (d c b a). If you run it, you will also notice that `d' takes 4 seconds to start up, `c' 3 seconds etc. However if we change the define at the top of the configuration file to #t, hence: --8<---------------cut here---------------start------------->8--- (define %one-shot #t) --8<---------------cut here---------------end--------------->8--- The behavior changes: --8<---------------cut here---------------start------------->8--- $ shepherd -c conf.scm Starting service root... Service root started. Service root running with value #t. Service root has been started. Configuration successfully loaded from 'conf.scm'. Starting service d... Starting service c... Starting service b... Starting service a... a Service a has been started. Service a started. Service a running with value #t. b Service b has been started. Service b started. Service b running with value #t. c Service c has been started. Service c started. Service c running with value #t. d Service d has been started. Service d started. Successfully started 4 services in the background. Service d running with value #t. --8<---------------cut here---------------end--------------->8--- Notice that the order changed to (a b c d, this matches the increasing wait time), the initial messages are all together: --8<---------------cut here---------------start------------->8--- Starting service d... Starting service c... Starting service b... Starting service a... --8<---------------cut here---------------end--------------->8--- and the whole start-up takes 4 seconds (the wait time of `d'). That seems to indicate that all 4 services are actually starting at the same time without waiting as they should per the #:requirement argument. Have a nice day, Tomas --=20 There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. From unknown Mon Jun 23 06:03:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74284: Shepherd does not respect ordering for one-shot? services Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 22 Nov 2024 14:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74284 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 74284@debbugs.gnu.org Cc: Dariqq Received: via spool by 74284-submit@debbugs.gnu.org id=B74284.173228628420858 (code B ref 74284); Fri, 22 Nov 2024 14:39:01 +0000 Received: (at 74284) by debbugs.gnu.org; 22 Nov 2024 14:38:04 +0000 Received: from localhost ([127.0.0.1]:53806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEUnL-0005QL-P5 for submit@debbugs.gnu.org; Fri, 22 Nov 2024 09:38:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEUnJ-0005Py-9o for 74284@debbugs.gnu.org; Fri, 22 Nov 2024 09:38:02 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tEUnD-00082n-Vb; Fri, 22 Nov 2024 09:37:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=BcZngg4Dz++/tbDueIhhfIc4ntVP9hwIgz9rDzC34zs=; b=pfmqSxZwxccdFVT3iqKA OBfPLDZSf54bnGD9ffUX7oelxIzcciUgYajgf6SimLN+7xhvvFB/Dk/gH6ZheFFlOygOma+9BxtEo paxadS+IQfSIN/4/gI2XyCzHo+aZgxjiAb6hrPP1ZR4/tFSf9nVgvHpLGzOp+uHIarclx2nrJaj1t oZaerlq4fpOL5snk7dz7G24P64d58Df9Ya/ZgP/lIUD/F8GZRd6grBzgH0vORbPysd6peEV1mza4+ HyXVGX3XcDn96UY0nOKM3PwgV051hvqpLVH/bsFj2+q/ExhvmSqGM7nAjo5G06z2gJvPo/HvjulJa 3a36prQzlXMXyg==; From: Ludovic =?UTF-8?Q?Court=C3=A8s?= In-Reply-To: <87ses073i9.fsf@wolfsden.cz> (Tomas Volf's message of "Sat, 09 Nov 2024 17:53:18 +0100") References: <87ses073i9.fsf@wolfsden.cz> Date: Fri, 22 Nov 2024 15:37:53 +0100 Message-ID: <87ed33qqpq.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Tomas, (+ Dariqq since we briefly discussed it on IRC yesterday.) Tomas Volf <~@wolfsden.cz> skribis: > Notice that the order changed to (a b c d, this matches the increasing > wait time), the initial messages are all together: > > Starting service d... > Starting service c... > Starting service b... > Starting service a... > > and the whole start-up takes 4 seconds (the wait time of `d'). That > seems to indicate that all 4 services are actually starting at the same > time without waiting as they should per the #:requirement argument. Indeed. As Dariqq found out, the problem was that we=E2=80=99d mark one-sh= ort services in =E2=80=98%one-shot-services-started=E2=80=99 as soon as we=E2= =80=99ve started them, effectively acting as if =E2=80=9Cstarted=E2=80=9D were synonymous with =E2= =80=9Crunning=E2=80=9D. This is fixed with 550c0370985022c5c90a7b477a5e0b84f6faf5d7. Let me know if you find anything fishy! Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 22 09:38:14 2024 Received: (at control) by debbugs.gnu.org; 22 Nov 2024 14:38:14 +0000 Received: from localhost ([127.0.0.1]:53810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEUnW-0005Ql-3U for submit@debbugs.gnu.org; Fri, 22 Nov 2024 09:38:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEUnU-0005QV-4Z for control@debbugs.gnu.org; Fri, 22 Nov 2024 09:38:12 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tEUnO-00083C-Ug for control@debbugs.gnu.org; Fri, 22 Nov 2024 09:38:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:Subject:From:To:Date:in-reply-to: references; bh=CFsqzyz1CWM7DWlMAaB6Oaa2lCR7e+cjeB+bZ6/84E8=; b=oNK0PoglTZj2FX EnHKFa1ELzW//CXk3Px/Vh/1dTjkLzQIsti1u8uaJABchKsOHkpnGwH3qvnGacrWoG7ju35qvIXww zx4xEunQp/BxdQYObfQ2qW9LMMPAelSvaDlp3jd3t6B2FvIypt4J8GIG6/c9HD85kGcVHf2jHHklZ xEVEYqa34wFEcofwDOleyymDepgDPan+/Wm8mhv24jvcgF+qfdy5zYEIzYGRTmJsGnNNY4jAWWPQE ayewRxq0LcTvKnhpIAYIy6PfHyqwGBLZZdOX3ohRVl8k+ZBz4WumGt46KPgebyJqhAhG1rOyLml/0 AXn5LxMJ8Uc6n/nXHbiQ==; Date: Fri, 22 Nov 2024 15:38:03 +0100 Message-Id: <87cyinqqpg.fsf@gnu.org> To: control@debbugs.gnu.org From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: control message for bug #74284 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 74284 quit From unknown Mon Jun 23 06:03:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74284: Shepherd does not respect ordering for one-shot? services Resent-From: Tomas Volf <~@wolfsden.cz> Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 22 Nov 2024 19:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74284 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Dariqq , 74284@debbugs.gnu.org Received: via spool by 74284-submit@debbugs.gnu.org id=B74284.173230451618902 (code B ref 74284); Fri, 22 Nov 2024 19:42:01 +0000 Received: (at 74284) by debbugs.gnu.org; 22 Nov 2024 19:41:56 +0000 Received: from localhost ([127.0.0.1]:55619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEZXQ-0004uo-8N for submit@debbugs.gnu.org; Fri, 22 Nov 2024 14:41:56 -0500 Received: from wolfsden.cz ([37.205.8.62]:43912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <~@wolfsden.cz>) id 1tEZXN-0004ub-JV for 74284@debbugs.gnu.org; Fri, 22 Nov 2024 14:41:55 -0500 Received: by wolfsden.cz (Postfix, from userid 104) id 16F73363720; Fri, 22 Nov 2024 19:41:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1732304512; bh=79PltnucZvOiT+kOpx0j/P/gQZFLx5fLMa5SDsr33z0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=M+o59bbzK3giVJ1Q9abd5vpKEnW7YoUjLe0hlCGt/syDVo3rUXFXuQhnB3RWixDwq D+0QauachIevMX8bbaev9Y/qLFBhTbK35T647ju8N7NzJ2Or9NXdmLdhfQOUPL+MA/ FAqgSEwFtfH+LP38FOkXV7KYopeRnrnZQ8qzaUq8rmXOOLHu9zvoClrL5+FOVReEF/ gDBoFybg0zf6FaDdGgaq0jAImIBSR6KghGdSO2e/Hp+2sblneIakz1sDmQqQDWdw3R 5DKrjpITUgnHfUCzL+2CL0M9zeaahzN3guw2mc7Ep0E0cOmWV2ncwQT7ox3LgYk8nE UUqH8OnMMDXglmsOLSRZmw8LjIeJjuOKp1QQOWeIVQnAq+QiGWKOYg5gMiHRiZvyzx ZnkctKyGkPkbOB5BALbMRCIjCIxfgeUNi+BrjhdjzQGcnDCv7j6kwNh+oN+39Buk2n ywQEcqoL4Sqx3rC0zQgrdWOL/4+TURO+IoXpqDaGwr0+omZacQXR4yTmEumy/V8Npt i0tuQ9pNabbM8vNqOj0ta0dkdh7hjJb9TpzbBO9G834w8xsyHYItkxglSHna6uuEPf Mq3QKm2wM96zWCkX7Qn03nZXo+EfrMb/3a/0gPUoXEFCgSVV7L9igVei9SZ8l2wPI8 a+3T8oOS5mMUxAm6wQWziQFc= X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from localhost (unknown [128.0.188.242]) by wolfsden.cz (Postfix) with ESMTPSA id BEB403624FB; Fri, 22 Nov 2024 19:41:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1732304511; bh=79PltnucZvOiT+kOpx0j/P/gQZFLx5fLMa5SDsr33z0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=AzPHiWj5F7u4GBsLzWKh7Rgjgg+CedNRGFm7ZULNMKtkUuLBIGhKGp5c5vh+JHCV6 LC1PlRbtMGCtj3xpHj1xcOPyI7s0iwNOd/I4W0D3Bu6jgcbMpN7gNcQmV5bmklsVAD tCw9Xvz3/ynlbFsW6fdVe6z+5yUXEAcWUUEY5mqSW+kBd1B/9mJMVu+KyVn6/wh90o oEyaUuiY407UlwgP7UBTPmZiGaa0bh+iM5SIqDe3PmxumPpky8uR8xXSC0vShIAe39 iSXqzg7vTdCm4DsrIYvKqNL3H8Jzl+teyOUXZtht/x38lOO+IUglvMO3DzpdmWXP6v XFm9Bu6RvozUwPXNQZhc5fdDr3ISfqBXqN6xeB5z6j1Bcw0qUB6PcLjSIIXbcmE0ZD rDRY5D1HAY7G+FtbuKn7KkTXKanqEyKGx2QSHeEpJI6A6wse5k00Sn3CBKGafW/IXB 0I1Q+VT+0JPblTmh14xtqhyc29N6OX7X9Ggr4csnop2ot/oHAqVJDvHwms76XJYvw0 pjTk4zF/+YqWdYIMebasPoWdkMnEkKF8HDOV2GdG8wh/5CQhKdvjudCW6hF+NQhWWT aV7bVLcQaDVPAosicO4F+qEJV4M6MipYdYqP24nVf2XLeErkFhyYlLp4ZjNIxuP1+u zAXuFtQaSKMAnO5N6cGsspl8= From: Tomas Volf <~@wolfsden.cz> In-Reply-To: <87ed33qqpq.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Fri, 22 Nov 2024 15:37:53 +0100") References: <87ses073i9.fsf@wolfsden.cz> <87ed33qqpq.fsf@gnu.org> Date: Fri, 22 Nov 2024 20:41:50 +0100 Message-ID: <87ttbzf43l.fsf@wolfsden.cz> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo', Ludovic Court=C3=A8s writes: > Indeed. As Dariqq found out, the problem was that we=E2=80=99d mark one-= short > services in =E2=80=98%one-shot-services-started=E2=80=99 as soon as we=E2= =80=99ve started them, > effectively acting as if =E2=80=9Cstarted=E2=80=9D were synonymous with = =E2=80=9Crunning=E2=80=9D. > > This is fixed with 550c0370985022c5c90a7b477a5e0b84f6faf5d7. I have checked out the commit and verified it with my original reproducer. Everything seems to work as it should, thank you for fixing it :) > Let me know if you find anything fishy! Did not notice anything, so once 1.0.0 lands in Guix we can just close this bug. Have a nice day, Tomas =2D-=20 There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmdA3n4OHH5Ad29sZnNk ZW4uY3oACgkQL7/ufbZ/wakgXQ//RED4qKlsW6bf0MVYZFjuXW6m26TivzvxWyUo fL/GSLWJjFxbhv6a7reBmYAfo6RH8O0HAQfY79wvJMMs5+BiOcUyY/1xubhZPMuC QnMW3GsRt107Msak7qhHA0ijRU7OpgqCWSUgrOeOImAa2ovA5RKBB3y6GC6+niw3 JqFTfZ8za3pMexJ1CeWtBRZjsyQJ6eF8X7BUYj/eruRGM7S4D+5oNW9R7suYqOuY 9+8P9txulFalAIvhWVn3ViLsmeZyp5A0kBqFrgX+Ax8lkUngDyU8aCRAdHuSQagD vUZ0FZb+PrUpFE2JuXqY3nSih7ezPoltVNn3YrIh4uBAEt2rgqOkfJPhH4NB/QWQ QkZi0uU+A71ZxwNQHzmbunRnqrVMseImyQlX/SESqEmLqws4r36PgT55d/r4UWKg e6b58GgogPtpGpC5zaj7Y4HbA1nJmEbtNGmcMW/3+qutXfAI4BJAyx78uUJh4oHI RjBBQhKx3i6ZHw0Nk00QC7Hp9iWUcsk8hh0ZLxx+hL5noVliq379Qm/E+f+1U9To 37LZxwbK7m/XH5GfoeYSghfDUjciBeVgAMgbtbsCiJCiw6Z4SB9nR/aYL/1apUCH kDUJ2eP1Bh5rPCx6a5nMOcpZm99eukA8xUHrDVUC/NesBE1KZPO8MxwtvvzN2smF fgeK6Ec= =xbtH -----END PGP SIGNATURE----- --=-=-=-- From unknown Mon Jun 23 06:03:35 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74284: Shepherd does not respect ordering for one-shot? services Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 26 Nov 2024 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74284 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Tomas Volf <~@wolfsden.cz> Cc: Dariqq , 74284@debbugs.gnu.org Received: via spool by 74284-submit@debbugs.gnu.org id=B74284.17326366254362 (code B ref 74284); Tue, 26 Nov 2024 15:58:02 +0000 Received: (at 74284) by debbugs.gnu.org; 26 Nov 2024 15:57:05 +0000 Received: from localhost ([127.0.0.1]:50187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFxw0-00018I-Hc for submit@debbugs.gnu.org; Tue, 26 Nov 2024 10:57:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFxvy-00017n-Ej for 74284@debbugs.gnu.org; Tue, 26 Nov 2024 10:57:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tFxvt-0005hH-5h; Tue, 26 Nov 2024 10:56:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=chgFydlXcz6aQ6/W97/0bT3OKtAwd1IHaIPjJmaJauo=; b=Lu5Gmhvc7Vru5e4tT4VK fplqG4htHp9vtDxZTbLBF2Eu3IvC8QFCcjTKS7U5njqZhEwVQ0gaR8NUxqnWF+KNTSKIhLYkW6619 uTubEeeLDMAvKRyXsqRPWw88ugwFvpav4Rh1qbTpXqGpEOi6vYPuZrmjfxNgm/5Bj6lJfjwsydFnI pyCwkAKT1wkkSQVP2J9Rnjqgvy7SNtcoISMxuLFgBMNAb3Y05K0LjimnYx127rehAYjya8ZSGuPBz YRf8/YN2qhCgu3Q/+/1JnrtbnM75xxu/zwkMlJqVk4WUJjdpm06nBGmWPzZjB0ideMMwHUIluxuUt PBitpndiopE9gA==; From: Ludovic =?UTF-8?Q?Court=C3=A8s?= In-Reply-To: <87ttbzf43l.fsf@wolfsden.cz> (Tomas Volf's message of "Fri, 22 Nov 2024 20:41:50 +0100") References: <87ses073i9.fsf@wolfsden.cz> <87ed33qqpq.fsf@gnu.org> <87ttbzf43l.fsf@wolfsden.cz> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Sextidi 6 Frimaire an 233 de la =?UTF-8?Q?R=C3=A9volution,?= jour de la =?UTF-8?Q?M=C3=A2che?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 26 Nov 2024 16:56:55 +0100 Message-ID: <877c8qaszc.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Tomas Volf <~@wolfsden.cz> skribis: > Ludovic Court=C3=A8s writes: > >> Indeed. As Dariqq found out, the problem was that we=E2=80=99d mark one= -short >> services in =E2=80=98%one-shot-services-started=E2=80=99 as soon as we= =E2=80=99ve started them, >> effectively acting as if =E2=80=9Cstarted=E2=80=9D were synonymous with = =E2=80=9Crunning=E2=80=9D. >> >> This is fixed with 550c0370985022c5c90a7b477a5e0b84f6faf5d7. > > I have checked out the commit and verified it with my original > reproducer. Everything seems to work as it should, thank you for fixing > it :) > >> Let me know if you find anything fishy! > > Did not notice anything, so once 1.0.0 lands in Guix we can just close > this bug. Awesome, thanks for checking!