From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: jami service failing following 'guix deploy' update Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 11 Jun 2022 05:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 55898@debbugs.gnu.org X-Debbugs-Original-To: bug-guix Received: via spool by submit@debbugs.gnu.org id=B.165492681632193 (code B ref -1); Sat, 11 Jun 2022 05:54:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Jun 2022 05:53:36 +0000 Received: from localhost ([127.0.0.1]:51718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nzu3z-0008N9-Hn for submit@debbugs.gnu.org; Sat, 11 Jun 2022 01:53:35 -0400 Received: from lists.gnu.org ([209.51.188.17]:43092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nzu3w-0008Mz-6o for submit@debbugs.gnu.org; Sat, 11 Jun 2022 01:53:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41638) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzu3v-0004XP-TC for bug-guix@gnu.org; Sat, 11 Jun 2022 01:53:31 -0400 Received: from mail-qv1-xf31.google.com ([2607:f8b0:4864:20::f31]:45782) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nzu3u-00014q-Br for bug-guix@gnu.org; Sat, 11 Jun 2022 01:53:31 -0400 Received: by mail-qv1-xf31.google.com with SMTP id ea7so971346qvb.12 for ; Fri, 10 Jun 2022 22:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:mime-version; bh=2vV1OyCIMZH3yFVifRcIFYUxNxVN18dwsP0YaBlKjfY=; b=Q9ySCWbKXfrrUOJ/4oCScDSO2eeSIb+RHkhCxkUXd3TZdaCz72h1CvVLQZJGcm08eU 6vnTlRhTTgEyg0wGBr6lSMemVYKJhDcR/2y/WR8MMfMo+Mytou375VCowLP/fruqJSIP Yc4jx0qWy8cAaejKf7yDaYIL65g7nWXx02nuBpJIEOyjSQtG50CD1DjazCydlkh8G0Mo QSBADN6gX691d4yacAxPhxp7ykibr2PdroX5gkU4NqMoB8qPaErEKDO1sjjaQAx0jxFG NY/qZ/BeBzyufqj3TOOVJjT5T/wuSAZ6qTl2FJzgW5tTb/IWq1jgqf856TQM+EonukWb 90Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=2vV1OyCIMZH3yFVifRcIFYUxNxVN18dwsP0YaBlKjfY=; b=2jo+qH5gjDAzIu//9OnpstwUc2PGb3dI8DBOXox9BD+TH/4lqeLBha5t9+zsvO7piY ck2iJwMvj7z7XcPVeI/qiRx0DC3YN9yuNVaF3RcW47QtedKcPO5C/upehNgXS02GAgov wg2zErgoSeompmi6dGWvCXcbNarPCxTZlz+zPqyKvIeNJBnjzi6aXy43Z8B0Qo9rMkFl nAMKS/s27DxDYzp4T8BcGQ+Cu0aDXT4EGQiUrHd8bjtDR7kRUYXD+YRXxtHBXSMLApru zqdkTwbLw2nyv5QWy7R4TAHSMmaPqQE8p/AQpQnX9SkCE6xoyn05hcHjXrXYZixz5Nax 7jtA== X-Gm-Message-State: AOAM530wNHSyC0hYzZ38w0aVopEpMCTHqcoeHX5N39aJwO5qZ1KojZkT 1ro+hBMOF0ftz0+OlDQuFBKMv2PZrruB7A== X-Google-Smtp-Source: ABdhPJwQa8XX45d2DWZIYu8bVWOac+ARv7R36Va7PpnPZZP/XZrQ/yhnu+6RRQa7Lj9/ZFo+svVyLQ== X-Received: by 2002:a05:6214:21c6:b0:464:47ca:fafa with SMTP id d6-20020a05621421c600b0046447cafafamr52504970qvh.130.1654926808291; Fri, 10 Jun 2022 22:53:28 -0700 (PDT) Received: from hurd (dsl-155-254.b2b2c.ca. [66.158.155.254]) by smtp.gmail.com with ESMTPSA id u18-20020a05622a199200b0030503a897b1sm817064qtc.42.2022.06.10.22.53.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 22:53:27 -0700 (PDT) From: Maxim Cournoyer Date: Sat, 11 Jun 2022 01:53:24 -0400 Message-ID: <87a6ajg2zv.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::f31; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qv1-xf31.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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 Guix! After having fixed the tests of the jami-service-type and pushed the fix as 85b4dabd94d53f8179f31a42046cd83fc3a352fc, I was confident it would work, but my freshly 'guix deploy'ed machine says otherwise: --8<---------------cut here---------------start------------->8--- $ sudo herd stop jami $ sudo herd start jami Service jami-dbus-session has been started. herd: exception caught while executing 'start' on service 'jami': Unbound variable: jami-service-available? $ guix system describe Generation 141 Jun 11 2022 01:38:12 (current) file name: /var/guix/profiles/system-141-link canonical file name: /gnu/store/vx9sd4vb2yfv0zhycd461m9wfvgzclsp-system label: GNU with Linux-Libre 5.17.14 bootloader: grub-efi root device: label: "btrfs-pool-1" kernel: /gnu/store/zf4062hz23485dp1xr8w6zbk2m8igpsk-linux-libre-5.17.14/bzImage configuration file: /gnu/store/n2wqba6npybjd8i730cpi9qc61p16jkr-configuration.scm --8<---------------cut here---------------end--------------->8--- I don't get it; how can the service runs fine in the instrumented VMs the system tests use, and fail in my updated machine? Could it be a fault in 'guix deploy'? To be investigated... Thanks, Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: jami service failing following 'guix deploy' update Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 11 Jun 2022 14:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.165495907816542 (code B ref 55898); Sat, 11 Jun 2022 14:52:01 +0000 Received: (at 55898) by debbugs.gnu.org; 11 Jun 2022 14:51:18 +0000 Received: from localhost ([127.0.0.1]:53724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o02SL-0004Ij-Uw for submit@debbugs.gnu.org; Sat, 11 Jun 2022 10:51:18 -0400 Received: from andre.telenet-ops.be ([195.130.132.53]:46372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o02SF-0004IX-Vz for 55898@debbugs.gnu.org; Sat, 11 Jun 2022 10:51:15 -0400 Received: from [172.20.10.9] ([188.189.6.179]) by andre.telenet-ops.be with bizsmtp id hqr82700E3rlPAs01qr9eF; Sat, 11 Jun 2022 16:51:10 +0200 Message-ID: <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> From: Maxime Devos Date: Sat, 11 Jun 2022 16:51:05 +0200 In-Reply-To: <87a6ajg2zv.fsf@gmail.com> References: <87a6ajg2zv.fsf@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-u2ACpbWMpAKejaiK0MsF" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1654959070; bh=brN1lK0mYlas6yvKOFKze46k3/U5RIIm9ShPZoe0L+k=; h=Subject:From:To:Date:In-Reply-To:References; b=RA4C8Pv1EtM9wJ8fWFhxxIfaM18g+/B1IYOy96qrBBoNmlzAq4ytwnRgIAQfDI+9l ZFj/4zGvaQ2JuOYighKU4lHQW65QcsklOBR+rM+daUkaqaOYMHH9TzXHNxCE2P5mFh eh0dnQS/kTwOMmxXh7GcpadFGarQcGe1aBXVQKyoupQI8wYz7DPn4uc0s+XPlGJTe7 9h5eoSc/mayTiIfW6DbJB5gt4QD9mdY/YeT4JtrkFqNQSk5cHcSE8KCKrfD2DhQcCp DdssyM1sKedBikTwzvJJgPcgBqOuDO80FL8J+wGplYJm9os2HH2AV5/0ou5Pi8uuS5 4BUEL0l3TDIjg== 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 (-) --=-u2ACpbWMpAKejaiK0MsF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maxim Cournoyer schreef op za 11-06-2022 om 01:53 [-0400]: > I don't get it; how can the service runs fine in the instrumented VMs > the system tests use, and fail in my updated machine?=C2=A0 Could it be a > fault in 'guix deploy'? Maybe the shepherd has the old (gnu build jami-service) module loaded and it doesn't know know to reload modules during reconfiguration? Greetings, Maxime. --=-u2ACpbWMpAKejaiK0MsF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYqSr2RccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7k8FAP9hlar7xP3IHawtI1wLXjXnxRp0 cbdlFmEs08Ex8uCz3wD/YAiRVRIL6f18vnmp7Er9gvzM/3bm9Uq9iT4YCswNIAs= =BDRp -----END PGP SIGNATURE----- --=-u2ACpbWMpAKejaiK0MsF-- From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: jami service failing following 'guix deploy' update Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 14 Jun 2022 19:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxime Devos Cc: 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.16552356721086 (code B ref 55898); Tue, 14 Jun 2022 19:42:02 +0000 Received: (at 55898) by debbugs.gnu.org; 14 Jun 2022 19:41:12 +0000 Received: from localhost ([127.0.0.1]:35857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o1CPY-0000HR-GN for submit@debbugs.gnu.org; Tue, 14 Jun 2022 15:41:12 -0400 Received: from mail-qk1-f171.google.com ([209.85.222.171]:42587) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o1CPL-0000Gd-5N for 55898@debbugs.gnu.org; Tue, 14 Jun 2022 15:41:10 -0400 Received: by mail-qk1-f171.google.com with SMTP id 68so7181158qkk.9 for <55898@debbugs.gnu.org>; Tue, 14 Jun 2022 12:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=CNKUzysPC3M4pQbseOrTUuhoQmJlqfUOEoM8tHIMQCQ=; b=VcxY4X0hS2bkOih+KV12m4T6jXAp0XERYqVy8eRv5zJNBS6EePmVKTHR2cc734Zr56 X7L8jvXfy0iwglSohjptNfb3cj3DsLuEaiZOhPXv+D2+0o2GFibc52AZZ5mtRooxrBYi CHcmxoYmtjVDGA+1OrWkOj83kLvPRhZnLr2oUyQ3QIyQiMJD97GY8mBa1JdNvIN9dbmk rk/LQYCVPWP1LatcAXgnxBKVKMbz9HuVxEK52QgpCNP6C0KohN1HZkFFXHNtb88k+Ce2 JGEB05tg0JoRMq41bXGlPRdTGwRqWNqlcsAB4c6TUZGYVpPzPoFghq1Cqd/y1zCYXf35 bi1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=CNKUzysPC3M4pQbseOrTUuhoQmJlqfUOEoM8tHIMQCQ=; b=HH8D4JeMfNmhuRrsijgBshrGo3CJM+0OjiiRLhsS5g0Z1hACxcCv729e2jga0AyC7f xlCXA9SOW+IQzEIw5/Bzh8m3M0obeEpjnlZnMJwBL5t4457ES9KTdfskkOEqMcKmZYZ0 yxxX5WehPUywKY+4I/KFHM01aGuqNuf0bOxyCH5QtsU4q9CarX7/KES4vUVvIBcAeNFu byEl2m68FCOEA5D+xvTmN7EkcmOqWSUxDih2vu3/Xfx6z7mXWz9Ceuc2ZmWtaewKxdbe uf+v5t9YIRA8Mq2zZ6lbabDjfA/TrCMyzYjyqLZsNvnVN0MmnU9iRm7OeGKML5NFT8TG rFPg== X-Gm-Message-State: AOAM531I2yVQ7YdPvHFdZBCHCyXqaayz0uZqEZlsTqR+hlcNMrLnEb5o sVM/m9dJqQnPN+gjEd02Aqlc1QQSChaori9X X-Google-Smtp-Source: ABdhPJydqc2AqVM6JhEyEgPKe6+M3Gu1eN9V4iTT54JTVLVEdEgvj0FpGAa+mLB5JJcENFMs5MuvHA== X-Received: by 2002:a37:5f41:0:b0:6a6:b397:f59c with SMTP id t62-20020a375f41000000b006a6b397f59cmr5602731qkb.195.1655235653177; Tue, 14 Jun 2022 12:40:53 -0700 (PDT) Received: from hurd (dsl-10-149-55.b2b2c.ca. [72.10.149.55]) by smtp.gmail.com with ESMTPSA id ea26-20020a05620a489a00b006a6a6f148e6sm9580220qkb.17.2022.06.14.12.40.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jun 2022 12:40:52 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> Date: Tue, 14 Jun 2022 15:40:51 -0400 In-Reply-To: <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> (Maxime Devos's message of "Sat, 11 Jun 2022 16:51:05 +0200") Message-ID: <87bkuvdoe4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Hello Maxime, Maxime Devos writes: > Maxim Cournoyer schreef op za 11-06-2022 om 01:53 [-0400]: >> I don't get it; how can the service runs fine in the instrumented VMs >> the system tests use, and fail in my updated machine?=C2=A0 Could it be a >> fault in 'guix deploy'? > > Maybe the shepherd has the old (gnu build jami-service) module loaded > and it doesn't know know to reload modules during reconfiguration? If true, that would indeed explain it. Thanks, Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: jami service failing following 'guix deploy' update Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 24 Jun 2022 17:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxime Devos Cc: 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.165609313820105 (code B ref 55898); Fri, 24 Jun 2022 17:53:02 +0000 Received: (at 55898) by debbugs.gnu.org; 24 Jun 2022 17:52:18 +0000 Received: from localhost ([127.0.0.1]:43449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4nTd-0005ED-T4 for submit@debbugs.gnu.org; Fri, 24 Jun 2022 13:52:18 -0400 Received: from mail-qv1-f43.google.com ([209.85.219.43]:34661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4nTb-0005Dz-Hr for 55898@debbugs.gnu.org; Fri, 24 Jun 2022 13:52:15 -0400 Received: by mail-qv1-f43.google.com with SMTP id t16so5676304qvh.1 for <55898@debbugs.gnu.org>; Fri, 24 Jun 2022 10:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=8zMlKQZTvUdnzhyKOTAPYfEFYHaTN/TJ7mEWNhnZAdM=; b=dRuzmOkPZh0WnV8mltZKPtdVaYEzCZqiPUehtCPzAXSPqdxGY0yJKcym01wKPpYpFV KSRRDbFiCfLwd+DUmU/dwwq6HzcwZ6rYS8T5NV8AQGDwQa29sRT5VrUJC5ECtOm+y15X bGjXNf8UzF7ys2DZ4t/kDpU3pbGtdvguNzptCmEs+Sm0kLysyINJVt/4Lm7JBxPMaFY1 X7qBEV9UWz1fhSOrCNGdJ530aZkqWAlN+Wv4TQOeh0V/yTXNnvtev29IVah2CSVb4xkQ lHKS8TxtNSslKTzvnubiD+4Au5eDWPA/0us4d/ZqP+VSE4ZQICVz6il6QgynFJYQXiaw XdZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=8zMlKQZTvUdnzhyKOTAPYfEFYHaTN/TJ7mEWNhnZAdM=; b=krVO2puGWUrS2WBmar6basrkQqT7ao00rMYq1ARHH/OyOwoyFRFoDVlUsMce/96meC 9IgZ8umOfh95hdFgQdJXG5dQWuDIIPlf4M/J4hlzw6Uq1zNdg4BNRwZzlVXhdD6QFym/ Di2fJ5r2+/Z2tp/yJt+0NUdBdtMVDpjZ1S+VWQ7X/Jdn0QYcVLqV8uZfhWzMzZfdHsUj ljlzwv1XA/eWzQBIK3Rb43vaVtFESOXsrKV/qMEUtJj6za/PC+nWuBP7Rz6TFQz5BFim ICx3LfccVxVIFyQtQvtn0Je3NrMVewa++DpTes7dTZhcPEDZen/+oX7FfPyLB5B1YNb9 lgSQ== X-Gm-Message-State: AJIora/mMiM9tOLsY+9QtTuA2U+6iWzW2Wb5ZyS0I8wAIZhb5GSkTrnJ 3Wy8BohMG22qHd05UeV01OBMT8ZYsXFeUHuNxnY= X-Google-Smtp-Source: AGRyM1vVIM9d1+G+aSXKZ+BZW26WKDVKB3rrEoo+caqaZMi+YRt4oEGVOm+6cZccaxGjcSCUZ9IAPw== X-Received: by 2002:a05:6214:411b:b0:470:8461:f85 with SMTP id kc27-20020a056214411b00b0047084610f85mr100340qvb.60.1656093129184; Fri, 24 Jun 2022 10:52:09 -0700 (PDT) Received: from hurd (dsl-158-129.b2b2c.ca. [66.158.158.129]) by smtp.gmail.com with ESMTPSA id u13-20020a05620a0c4d00b006a71398f06fsm2399773qki.32.2022.06.24.10.52.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jun 2022 10:52:08 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> Date: Fri, 24 Jun 2022 13:52:07 -0400 In-Reply-To: <87bkuvdoe4.fsf@gmail.com> (Maxim Cournoyer's message of "Tue, 14 Jun 2022 15:40:51 -0400") Message-ID: <87v8sqx83c.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) retitle 55898 jami service fails to start following reconfigure thanks Hello, Maxim Cournoyer writes: > Hello Maxime, > > Maxime Devos writes: > >> Maxim Cournoyer schreef op za 11-06-2022 om 01:53 [-0400]: >>> I don't get it; how can the service runs fine in the instrumented VMs >>> the system tests use, and fail in my updated machine?=C2=A0 Could it be= a >>> fault in 'guix deploy'? >> >> Maybe the shepherd has the old (gnu build jami-service) module loaded >> and it doesn't know know to reload modules during reconfiguration? The module seems to be simply missing, according to: --8<---------------cut here---------------start------------->8--- $ guix gc -R /gnu/store/sq7krjjpwbkr3z573flbnvkml1574mn5-system | grep jami /gnu/store/vkgamffkm92l3xdzid42k4lcz6aqfj7i-ffmpeg-jami-4.4.2 /gnu/store/kk3dzx2xsa135d1i5jsjm8i787gbl56i-pjproject-jami-2.11-0.e1f389d /gnu/store/fyd7rmvzhhqbk1f08c4pl7ahhlfgig40-shepherd-jami.scm /gnu/store/kqiqnza4l0jawrs0mszymj8diaa2j97m-shepherd-file-system--home-jenk= ins-jami.scm /gnu/store/yp9awyfgiym32card9w5mds8id6d6d0l-shepherd-file-system--home-jenk= ins-jami-workspace.scm /gnu/store/xib9gc60a8bbff99cffh2x74gqpszf0i-shepherd-jami-dbus-session.scm /gnu/store/q00v0f7syc1b6phfq4gih8i9irnm862w-dbus-for-jami-1.12.20 /gnu/store/dqfply51lzqc5z697k98avigsv21qm8q-libjami-20211223.2.37be4c3 /gnu/store/5w1zqbwagkhavqs7xjbzb8m7j978dcwj-shepherd-file-system--var-cache= -jami.scm /gnu/store/njrxi4apky4ckb2py9qz0ciz0b92smrd-shepherd-jami.go /gnu/store/kciz8nady3rc5jd9j67bmlzyn622j5md-shepherd-file-system--home-jenk= ins-jami.go /gnu/store/ddxa8yxqh1c3h6iax2x24wj0lfxrx8c6-shepherd-file-system--home-jenk= ins-jami-workspace.go /gnu/store/d54hhmd90h7q4qmnb3q6ngsdp9457r80-shepherd-jami-dbus-session.go /gnu/store/59lizyj4miag5if9ylhk383qr1qbxw1h-shepherd-file-system--var-cache= -jami.go --8<---------------cut here---------------end--------------->8--- After a 'guix system reconfigure' that successfully changed /run/current-system. I was expecting the module should have been pulled in the closure via the encapsulating: --8<---------------cut here---------------start------------->8--- (with-extensions (list guile-packrat ;used by guile-ac-d-bus guile-ac-d-bus ;; Fibers is needed to provide the non-blocking ;; variant of the 'sleep' procedure. guile-fibers) (with-imported-modules (source-module-closure '((gnu build dbus-service) (gnu build jami-service) (gnu build shepherd) (gnu system file-systems))) --8<---------------cut here---------------end--------------->8--- in (gnu services telephony) around line 312. Thoughts? Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: jami service failing following reconfigure Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 24 Jun 2022 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxime Devos Cc: 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.165609369421231 (code B ref 55898); Fri, 24 Jun 2022 18:02:02 +0000 Received: (at 55898) by debbugs.gnu.org; 24 Jun 2022 18:01:34 +0000 Received: from localhost ([127.0.0.1]:43472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4ncc-0005WM-0Y for submit@debbugs.gnu.org; Fri, 24 Jun 2022 14:01:34 -0400 Received: from mail-qv1-f54.google.com ([209.85.219.54]:35513) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4ncZ-0005W5-9Q for 55898@debbugs.gnu.org; Fri, 24 Jun 2022 14:01:33 -0400 Received: by mail-qv1-f54.google.com with SMTP id u14so3017752qvv.2 for <55898@debbugs.gnu.org>; Fri, 24 Jun 2022 11:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=fE1zpGOtasbL9IWV7872T0AabkmNQVg97Lkr0Vg2fn4=; b=WKCu2ubSjxdS21XkLo4CF2Bzs6oA2EAjSirlWzRd7XXcAs0ROGvIZ/lzwF2Iua9GCF ZtxeY25PQx7lHSzDdXSkD2R3bqiaEZ7fz0ZsNtlzPz0eZCgeGh9duu/5yUd8haNaaEKZ dFK9l5b9UM4Noni7bsLo7Y37X5oxyIZYQUrvblQq1topfvDhGJvgo71vn6qTuADU9Nze ovuhPrTSEt7jVrF/jyAXWTfm8oidqietU9fDgF3K+JlW8fx5c4ogwn3iOB9I9WnqZuRn O1e7Lp2GcVA0T1LoHmvrIhLDk7k52eN2AEzQufvn/UivcdSszBYiH3pT0KExc/iHuAFi jGiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=fE1zpGOtasbL9IWV7872T0AabkmNQVg97Lkr0Vg2fn4=; b=NiwkLRA9p2UyDymzNbxFqAZg1fpjKov6sYWVzZRZMPN0reSiG7zVsfGCLwoJewwOl2 NJboFN0teyUorFUXBVCtUpO/FW3fnUKa23r6/hJq/97pWDAIj/w8L587lDfpKwrjQ19k 4IbwKo4x+YOD0eQQG+OIXjtaVPOKZGnGs+NQhZQYzpKgwHkVxERGzR5poWv1ZsG6GDdb Em31saI1SuYzNC0OuHkF81UQSraUsbt3F8kkOAfH/ZAMp5lBfZ80vcfQ+aE6tzazKJmd qJ4u0q+NvkzzZr6nY94X7iDwTqu8p1boYf+T97aqA9ifi45HmmMNCGJjjyEHY//NP4iQ aT/g== X-Gm-Message-State: AJIora++yxy2anHtWZSBh6fagnmkOmrBDxTs/xSNInWqATAskZQ33Rgs HWQmfcBo7Bc/AcTRbXIoJFHcUU/nIINgEp8IUxI= X-Google-Smtp-Source: AGRyM1sFn4vgYpn+it5NXSCZUPyuOFT47IdCb9A9eMCti4HivAFUEbJnQWIEsepQYvmoMNwg542MVw== X-Received: by 2002:ad4:5d49:0:b0:46a:66a2:d73f with SMTP id jk9-20020ad45d49000000b0046a66a2d73fmr37872339qvb.45.1656093685105; Fri, 24 Jun 2022 11:01:25 -0700 (PDT) Received: from hurd (dsl-158-129.b2b2c.ca. [66.158.158.129]) by smtp.gmail.com with ESMTPSA id f10-20020a05620a280a00b006a69d7f390csm2260478qkp.103.2022.06.24.11.01.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jun 2022 11:01:24 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> Date: Fri, 24 Jun 2022 14:01:23 -0400 In-Reply-To: <87bkuvdoe4.fsf@gmail.com> (Maxim Cournoyer's message of "Tue, 14 Jun 2022 15:40:51 -0400") Message-ID: <87r13ex7nw.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Hi again, Maxim Cournoyer writes: > Hello Maxime, > > Maxime Devos writes: > >> Maxim Cournoyer schreef op za 11-06-2022 om 01:53 [-0400]: >>> I don't get it; how can the service runs fine in the instrumented VMs >>> the system tests use, and fail in my updated machine?=C2=A0 Could it be= a >>> fault in 'guix deploy'? >> >> Maybe the shepherd has the old (gnu build jami-service) module loaded >> and it doesn't know know to reload modules during reconfiguration? I verified that in the /gnu/store/fyd7rmvzhhqbk1f08c4pl7ahhlfgig40-shepherd-jami.scm file it was setting up the load path with everything needed, such as --8<---------------cut here---------------start------------->8--- (eval-when (expand load eval) (let ((extensions (quote ("/gnu/store/f6q4237n62lq7n8z3qyh3jx5iinb9myr-guile-packrat-0.1.1"= "/gnu/store/l2f9gmd64w56nnhnlb63hg8f5crfvwln-guile-ac-d-bus-1.0.0-beta.0" = "/gnu/store/is9f6ki7i2f6qk80ivvz7q1vvlibb96l-guile-fibers-1.0.0"))) (prepend (lambda (items lst) (let loop ((items items) (lst lst)) (if (null? items) lst (loop (cdr items) (cons (car items) (delete (car items) lst)))))))) (set! %load-path (prepend (cons "/gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import" (map (lambda (extension) (string-append extension "/share/guile/site/" (effective-version))) extensions)) %load-path)) (set! %load-compiled-path (prepend (cons "/gnu/store/zqgpayc87lfmcmncgzbp5v59hav8ww1c-module-import= -compiled" (map (lambda (extension) (string-append extension "/lib/guile/" (effective-version) "/site-ccache")) extensions)) %load-compiled-path)))) --8<---------------cut here---------------end--------------->8--- The /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import directory contains: --8<---------------cut here---------------start------------->8--- $ find /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/build /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/build/dbus-se= rvice.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/build/file-sy= stems.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/build/jami-se= rvice.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/build/linux-c= ontainer.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/build/shepher= d.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/system /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/system/file-s= ystems.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/gnu/system/uuid.s= cm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/build /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/build/bourni= sh.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/build/syscal= ls.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/build/utils.= scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/colors.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/i18n.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/profiling.scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/diagnostics.= scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/memoization.= scm /gnu/store/7kgdg6dmgncqirj3k07n02hq6kjyf4an-module-import/guix/records.scm --8<---------------cut here---------------end--------------->8--- and the referenced [...]/gnu/build/jami-service.scm file does contain the supposedly missing 'jami-service-available?' procedure. I'm suspecting that given the service makes use of Shepherd 0.9 features, perhaps it fails loading and the error is reported erroneously that way... a reboot would tell but I'm not in a position to do that at this moment (remote machine). Thanks, Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: jami service failing following 'guix deploy' update Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 06 Jul 2022 21:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxime Devos Cc: GNU Debbugs , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.165714353221676 (code B ref 55898); Wed, 06 Jul 2022 21:39:02 +0000 Received: (at 55898) by debbugs.gnu.org; 6 Jul 2022 21:38:52 +0000 Received: from localhost ([127.0.0.1]:55304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9CjQ-0005dP-DX for submit@debbugs.gnu.org; Wed, 06 Jul 2022 17:38:52 -0400 Received: from mail-qk1-f170.google.com ([209.85.222.170]:45728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9Cj0-0005cd-OL; Wed, 06 Jul 2022 17:38:31 -0400 Received: by mail-qk1-f170.google.com with SMTP id p11so12041194qkg.12; Wed, 06 Jul 2022 14:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=LSrjcxRU1f6l55UpvHRtUQI0pCr/pGJmKaDnxoJ+Ofs=; b=mTUw685fmiO4yNqvq9JRcPgVKfiQodIfvq2GbGM28ZpD6ks3v+LkO89ov4JSndf4Cw 4mZsc7Lph4JmbTdgFulOXxMOJAp6HF8ggTN5FXUryTdE8fIrQrbz4JorV7YXl9Vurt4u TIE8lKmJfzhM/EyajkkMuwHG+a01JY7WlblJI+zo56vO54MaysImZyrYASfjoG/1pBoK WO6VREDqgdN9iVU0iMXtWH4WvzLZV7ONUi00tveqHImyu1+fGNsutaYaO6Nl0P4aTols H5gHxksv7rPZqE6g0/gNXK6rI2ugK80RNypF/o62z/+OQdorXfeYFvWsE9r8DlzlKWKN dPFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=LSrjcxRU1f6l55UpvHRtUQI0pCr/pGJmKaDnxoJ+Ofs=; b=I4WG1Jubw7onzhv1N8mJYXH66SdYGIKQRCQsn9FtLrkeM2SGGorv8owk3FhMaJ4N0P AjQ6TfpkNu9pSRZ3/wtua+bzwbOnw5om0bG8dGBIoc0dGXT7UIAEETbbTx5e7CNBsmSe ZCRw+Xk/JyeIwfvKwGC2uhbQSOU8iUAKENVqKnkXgTwYMvsPEXQnEFwH4J3lklvFt03F nkbzSN62ETf7MGvCNbalK5KZFEeZuyZBMRkKDpc+/M/3m1k7/NaOHI17I5jjR6qCoPVq JdeGto5Rq6iSaMEeFjW0X1oCygRJd9ricaVuJiHWnhJL82VdGMADgQhgeSSrTPlEaU0m /yBw== X-Gm-Message-State: AJIora+Si3GMTD1wSWcnQq9PEKE88yTxmyrQTbc/sms9JQV8VqX7xXGu W2rtdtQPGxggDA9LjU6wpNWmVf7Ftl8zqaRt X-Google-Smtp-Source: AGRyM1um74pLtujyxPcHmo+7v37SkfAN95Z+xFkGqSL55Ve2nfR42HJ5I9K8PjngiQoW1O0IEuh+kA== X-Received: by 2002:ae9:f711:0:b0:6af:9d1:8ede with SMTP id s17-20020ae9f711000000b006af09d18edemr29232150qkg.179.1657143495451; Wed, 06 Jul 2022 14:38:15 -0700 (PDT) Received: from hurd (dsl-10-134-148.b2b2c.ca. [72.10.134.148]) by smtp.gmail.com with ESMTPSA id bs11-20020a05620a470b00b006b1eb3a8364sm16959061qkb.5.2022.07.06.14.38.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jul 2022 14:38:14 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> Date: Wed, 06 Jul 2022 17:38:13 -0400 In-Reply-To: <87r13ex7nw.fsf_-_@gmail.com> (Maxim Cournoyer's message of "Fri, 24 Jun 2022 14:01:23 -0400") Message-ID: <87mtdl2a7u.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 (-) retitle 55898 Services depending on new Shepherd features may fail until a reboot thanks Hi, Maxim Cournoyer writes: [...] > I'm suspecting that given the service makes use of Shepherd 0.9 > features, perhaps it fails loading and the error is reported erroneously > that way... a reboot would tell but I'm not in a position to do that at > this moment (remote machine). I confirm that following a reboot, the service runs normally. Perhaps services should allow specifying the minimum required Shepherd version, which Shepherd could ensure is met before attempting to restart a service, printing something like: 'Could not restart service X due to unmet Shepherd version requirement; the service will continue unchanged until the next reboot' or something similar. I've re-titled the bug, as this isn't specific to our jami service. Thanks! Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: jami service failing following 'guix deploy' update Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 06 Jul 2022 22:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxime Devos Cc: GNU Debbugs , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.165714491732411 (code B ref 55898); Wed, 06 Jul 2022 22:02:02 +0000 Received: (at 55898) by debbugs.gnu.org; 6 Jul 2022 22:01:57 +0000 Received: from localhost ([127.0.0.1]:55321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9D5p-0008Qf-B3 for submit@debbugs.gnu.org; Wed, 06 Jul 2022 18:01:57 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:37472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9D5l-0008QK-K3; Wed, 06 Jul 2022 18:01:55 -0400 Received: by mail-qt1-f169.google.com with SMTP id i11so20269297qtr.4; Wed, 06 Jul 2022 15:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=0rvaPlqFPOPduEkxVAoLVsmjaVt4VYO7nub8kv3x5GE=; b=f7+C/Z0AHyGmn129G69jf3BBI8FbX5uvB4BPZ+2XjUSjIxdvmVGA1gV/sikD1RZuSq VzprYtBlqpZ+NF189sIJashXB5L/A8+XQIsS45AY70KouUDVywTS5JzlhFnWVabfn6gY h2rZoAfMl3vVxULG6zenEuPdMweLZ3yjrYVKdvGoOMuPQUdtMxibyNzJltJjzdIvSm8t hhdSYxkXNgk5lvqQ777XEH51mkcpaORr0RgHu7+h11gWf28vF9e4f/+jgZQhjEDHh1xp 2is+EMS06l1mbysyDU4La+5U/T8UF+prxI3tsVYbh06s/7h/C33wHoW1YX8JoYmk3YN+ fHYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=0rvaPlqFPOPduEkxVAoLVsmjaVt4VYO7nub8kv3x5GE=; b=C/yAvPFRWZrkwb/9V3xqPAbUNGckNziNzrtmMGFkH4H7DCSgYWt/Lkf36Rclc+TcFw vxrymx7u4TRKo5P2pSbVLUIEcU9uRP6NZwBZmu7znXIz2ZYRHy7N2I0t8W4WmgEhbRZN ESM9Ky6YYWBZJATOt9B85mlBt/tRdKSCNQePZ5mnt0DzEjwQd22us6BjUkSxmAscV4Cc llhe+KgBXO96OTDrBjCBOTkPWWZdYFkhzBT7fZSMBVL/dCiePZznEcVCg/PaAXorXUbO A51DcSe0VUdSaVR0tgul+esnobyWLj287jlUe6lb3RF9AnwT7sp/zF91b164mDv5/xmu wa6Q== X-Gm-Message-State: AJIora/r4v4oFqsqCOEiQkzLMKSU+PmRg0By8EKcwzjWpf/XOT2H5ION Fs6lsJfdL5k8fxs6rpuu8D5pdfqi0itwP2hr X-Google-Smtp-Source: AGRyM1u624e+H3hdtn/Na12o5Ku2mEliZ6OQ2Bx/ybWyXoE2W7XOvETcImt8ggNBOcdJGHa1I2inQQ== X-Received: by 2002:a05:622a:5cf:b0:31d:4c04:b642 with SMTP id d15-20020a05622a05cf00b0031d4c04b642mr15481037qtb.310.1657144907635; Wed, 06 Jul 2022 15:01:47 -0700 (PDT) Received: from hurd (dsl-10-134-148.b2b2c.ca. [72.10.134.148]) by smtp.gmail.com with ESMTPSA id bp10-20020a05622a1b8a00b0031d4044c464sm10003350qtb.46.2022.07.06.15.01.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jul 2022 15:01:47 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> Date: Wed, 06 Jul 2022 18:01:45 -0400 In-Reply-To: <87mtdl2a7u.fsf_-_@gmail.com> (Maxim Cournoyer's message of "Wed, 06 Jul 2022 17:38:13 -0400") Message-ID: <87ilo9294m.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 (-) Hi again, [...] > Perhaps services should allow specifying the minimum required Shepherd > version, which Shepherd could ensure is met before attempting to restart > a service, printing something like: > > 'Could not restart service X due to unmet Shepherd version requirement; > the service will continue unchanged until the next reboot' > > or something similar. > > I've re-titled the bug, as this isn't specific to our jami service. I've asked in #systemd about what a similar situation would happen in systemd-land, and here's what I've learned: 1. service units aren't reloaded automatically after new versions of them are installed -- this effectively prevent the breakage seen here (the jami service was reloaded and restarting manually it caused it to fail). 2. a savvy user can still opt to force the new service to be reloaded via 'systemctl daemon-reload'. In case the service update depends on new systemd features, systemd would need to be restarted itself, via 'systemctl daemon-reexec'. The later command is interesting, but its documented as a debugging tool [0]: daemon-reexec Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible. [0] https://www.freedesktop.org/software/systemd/man/systemctl.html# systemd folks told me it is not typically run in systemd package upgrade hooks, but perhaps some distribution do this (I don't know). So the situation is not very different in systemd vs shepherd, except that we more aggressively load the new service definitions, potentially leading to breakage. Thoughts? Maxim From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 07 09:16:36 2022 Received: (at control) by debbugs.gnu.org; 7 Jul 2022 13:16:36 +0000 Received: from localhost ([127.0.0.1]:56008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9RMx-0000S3-SB for submit@debbugs.gnu.org; Thu, 07 Jul 2022 09:16:35 -0400 Received: from mail-qt1-f174.google.com ([209.85.160.174]:41582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9RMt-0000Rg-CT for control@debbugs.gnu.org; Thu, 07 Jul 2022 09:16:34 -0400 Received: by mail-qt1-f174.google.com with SMTP id c20so326606qtw.8 for ; Thu, 07 Jul 2022 06:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:from:subject; bh=K8d5JYDSHsjZsP1wo//jgPJdl/2FAqEtCKVJhke/E/4=; b=H7CNoiSW6igy8LevOckaLvChK5mnGIenGibwHEgPG1BHrpkv4h/uWVXtAb9pgy8hsi whqY5+UWxnb6esfs0lX8+gncbKFbgKx17XIz5XG4Z2VayMg1jI8dBceY6mRNR9jNRD43 3EB9kzL0HmaHCW7IfsgEz/PlaKDbVwCSvT0a2mkRqdn7IetOyfzLii0ZOUWTYqhB2fVP tFd44ud2Uq0x34t5JreMgaGBT0LIFwR4r3UivyyZZw+k0c1US8IfOMjGqEiT95fSRe18 pBJ64qEO3w9kUyNQmj4qGNM9KnJvAEq0CNdLZQo0lPK8/B+UM1wFcogtSg2JF8m2GBGi 45iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:to:from:subject; bh=K8d5JYDSHsjZsP1wo//jgPJdl/2FAqEtCKVJhke/E/4=; b=k5OC7/1gwGzMvZ6m90RI4iltr9hhH8682N+lYukbHRDg4hkFxr4wtiyyWXAN6uC/0b 2CqH6cx8vBamFwTePRkbddvkdFzWYW8TYigliwWyxyfMaBGeyUeIwDnHrKBfqJyTiEkV dtSZSryW28azAP/IGF+XhgD8j/vStv/71ioIoqr/TqvzzVaR0GbLvFNndc8I9zmDVphW i7kpGsBuIFLXiVZzaVTSghvZ6Nr/QBbnaBkRJVYQksgXxdXLeUgWLpQPEtwrmG+zTQRV 5XSyrMliVfpeVwJxBDDibYJjyyV/9snlDn9r/FBp8PEDOZ8lIQb/dIRGNl/IFgEnhKOO XelA== X-Gm-Message-State: AJIora/kEoBJF3ESheJLkiCnqC7Qfny30CdsWXC7IwZevkEa8C99OCXJ gINqpi3w+XwC4G0TVVAxxwfkHHYnqonqZQ== X-Google-Smtp-Source: AGRyM1s6XssdgjD7P8e3msH9yD2apV7hz8kzTjJIh8S0OBYOrPxIU3/G0hnbcB7CwOr+lukCfcP+Sw== X-Received: by 2002:a05:6214:d81:b0:45a:e07e:6bcb with SMTP id e1-20020a0562140d8100b0045ae07e6bcbmr40900622qve.29.1657199785569; Thu, 07 Jul 2022 06:16:25 -0700 (PDT) Received: from hurd (dsl-153-127.b2b2c.ca. [66.158.153.127]) by smtp.gmail.com with ESMTPSA id r13-20020ae9d60d000000b006b28277939bsm12189757qkk.71.2022.07.07.06.16.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Jul 2022 06:16:25 -0700 (PDT) Date: Thu, 07 Jul 2022 09:16:23 -0400 Message-Id: <87h73t12s8.fsf@gmail.com> To: control@debbugs.gnu.org From: Maxim Cournoyer Subject: control message for bug #55898 X-Spam-Score: -0.0 (/) 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: -1.0 (-) retitle 55898 Services depending on new Shepherd features may fail until reboot quit From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 20 Jul 2022 21:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Cc: GNU Debbugs , Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.165835199710105 (code B ref 55898); Wed, 20 Jul 2022 21:20:01 +0000 Received: (at 55898) by debbugs.gnu.org; 20 Jul 2022 21:19:57 +0000 Received: from localhost ([127.0.0.1]:36185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEH6r-0002cu-1Q for submit@debbugs.gnu.org; Wed, 20 Jul 2022 17:19:57 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEH6o-0002cd-3m; Wed, 20 Jul 2022 17:19:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38702) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEH6i-0006ON-74; Wed, 20 Jul 2022 17:19:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=nvJ0LMfkwpO95UeZJVfkVRoOKjIvGVfuI9yXOXaAuRw=; b=mIg7/Ic+7NbaxcbEqvGH XwrZ0tffLIwwHTbI0DwJ0XyZplvB/T4Y6DCCQ16/35+/vp7tjTgauWhdeFkCxt815ZLvPCdhk8JsJ M0OB7K/7JIgCUWWJwPo2e9e18xCP20KkPYYw1y0DSr0Dxdy0HCpxW+SHQn+/QPyDJWTBqGkhUlOOe uqX4PUuMrPTpD/KvXJJ+sQcYS6J7KGikHdKiCn2dskRyMT82MvZsCl5w/HkIwt8mPLU1il5wOtedp cswILq01clf9kdwT4BdtpDAYN5hoSNoGIU4tti6oa37m7cmReMN7dNgSfmpEdNgE1Vdwjt38kQxRw 9zbhA/b72PTRgQ==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:56462 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEH6h-0008UN-JZ; Wed, 20 Jul 2022 17:19:48 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> Date: Wed, 20 Jul 2022 23:19:44 +0200 In-Reply-To: <87ilo9294m.fsf@gmail.com> (Maxim Cournoyer's message of "Wed, 06 Jul 2022 18:01:45 -0400") Message-ID: <87a693pjm7.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) 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! Maxim Cournoyer skribis: >> Perhaps services should allow specifying the minimum required Shepherd >> version, which Shepherd could ensure is met before attempting to restart >> a service, printing something like: >> >> 'Could not restart service X due to unmet Shepherd version requirement; >> the service will continue unchanged until the next reboot' >> >> or something similar. Yes. The issue is that we=E2=80=99re more free-style than systemd: we=E2= =80=99re basically loading code live in the running Shepherd. So we have to write that code such that it works with older Shepherd versions. This is why we have things like conditions on (defined? 'make-inetd-constructor) and the likes, with a fallback. >> I've re-titled the bug, as this isn't specific to our jami service. > > I've asked in #systemd about what a similar situation would happen in > systemd-land, and here's what I've learned: > > 1. service units aren't reloaded automatically after new versions of > them are installed -- this effectively prevent the breakage seen here > (the jami service was reloaded and restarting manually it caused it to > fail). > > 2. a savvy user can still opt to force the new service to be reloaded > via 'systemctl daemon-reload'. In case the service update depends on > new systemd features, systemd would need to be restarted itself, via > 'systemctl daemon-reexec'. The later command is interesting, but its > documented as a debugging tool [0]: > > daemon-reexec > > Reexecute the systemd manager. This will serialize the manager > state, reexecute the process and deserialize the state again. This > command is of little use except for debugging and package > upgrades. Sometimes, it might be helpful as a heavy-weight > daemon-reload. While the daemon is being reexecuted, all sockets > systemd listening on behalf of user configuration will stay > accessible. > > [0] https://www.freedesktop.org/software/systemd/man/systemctl.html# > > systemd folks told me it is not typically run in systemd package upgrade > hooks, but perhaps some distribution do this (I don't know). > > So the situation is not very different in systemd vs shepherd, except > that we more aggressively load the new service definitions, potentially > leading to breakage. I think any upgrade, be it =E2=80=98guix system reconfigure=E2=80=99 or =E2= =80=98apt dist-upgrade=E2=80=99, is likely to end up loading new service definitions= =E2=80=94Guix System isn=E2=80=99t more aggressive in that respect. The main difference is that our services are code and that they might depend on specific Shepherd APIs. It=E2=80=99s a much more direct dependen= cy compared to .service files I guess. Thanks, Ludo=E2=80=99. From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 21 Jul 2022 04:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.16583766243512 (code B ref 55898); Thu, 21 Jul 2022 04:11:02 +0000 Received: (at 55898) by debbugs.gnu.org; 21 Jul 2022 04:10:24 +0000 Received: from localhost ([127.0.0.1]:36398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oENW3-0000uZ-OO for submit@debbugs.gnu.org; Thu, 21 Jul 2022 00:10:24 -0400 Received: from mail-qv1-f47.google.com ([209.85.219.47]:39716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oENVz-0000u5-Rb for 55898@debbugs.gnu.org; Thu, 21 Jul 2022 00:10:21 -0400 Received: by mail-qv1-f47.google.com with SMTP id t7so336522qvz.6 for <55898@debbugs.gnu.org>; Wed, 20 Jul 2022 21:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=f55GwCsgcxOLrB/957baVSKJ9BiNH8WWUaGw1xHsWb8=; b=c8Ug0cnUI6LoFq4PkqdHbOVfc+fhcpT/Dt0bMg/HEhw66vAkomfZshueRZwHhqe5JK I4MJfxA9nzaAvBsDC2r9GUEjEQV/NlMMZcJrCcdhZAbfHJ9vGjRVfmvYQxWELUwpcV4H OVk1uiWb7Kjy2i/ndqW86rbAK9aNBJQa5rE3N3WE5v+7jBCfOind7Blge1Y5zldl+aa4 LULZMRCFgy8hvAC7b/R+iU6ALKD/S3Nou6v07gzf6zpbZPRlZoqkQ6nC+uaRL+TRth/i HKMt77ctZ82l0wZN8cBL0naD3fg6i8+8NU06QJ8MjeID+L4EAkKgBdP28fyr01+rOsCR kxPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=f55GwCsgcxOLrB/957baVSKJ9BiNH8WWUaGw1xHsWb8=; b=qSjIGR6znVW+aHjhKQ7hbv4aSscnbz39qz9gJduk995JdX2wQwVaImtG9WKQKfJfEV jfrdpSJPs7GZiVeU+xcrndSAoFiFYGqaYQajVfEGjIODwphHBdKlLEpx2eiRZT9Dl6Mc rxSXwft/ZV6TYRiKbUyksiHud6QsDyHVn7F/tm/+j2bu2c9NxPpMxMS9YNUws0BSrNhC Z5ztaVKV9WUjCPywjc9gdVre98XMnnxmFmoGSz4pO9mv2YClLkOhMmVcg/gRYpJq2Jjp wDNaC7nNtORqjusphMutdp9UTrpQXnjjWTiabKs5SBqdVIYKYUsqBM9/xwngmUL3qIOW DfgA== X-Gm-Message-State: AJIora9W9dm3T6+hCKTQBh3QX7CVh7+oBwa/flqZR3qgXvm/o/b+CvVv 7XvJzCQ7yxHOt5uygGQ1LR8yib5f6eo= X-Google-Smtp-Source: AGRyM1v/qPpt2FNu6DTbseft9JKIaalzkxJXjws1ScBd4wG/d/W/Oyjvb3onqFQspREvxe8NZ6zMNA== X-Received: by 2002:ad4:5dc7:0:b0:473:e8d0:220d with SMTP id m7-20020ad45dc7000000b00473e8d0220dmr10605382qvh.128.1658376614097; Wed, 20 Jul 2022 21:10:14 -0700 (PDT) Received: from hurd (dsl-10-148-92.b2b2c.ca. [72.10.148.92]) by smtp.gmail.com with ESMTPSA id bi7-20020a05620a318700b006b555509398sm608713qkb.136.2022.07.20.21.10.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jul 2022 21:10:13 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> Date: Thu, 21 Jul 2022 00:10:12 -0400 In-Reply-To: <87a693pjm7.fsf_-_@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Wed, 20 Jul 2022 23:19:44 +0200") Message-ID: <87r12fqf6j.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Hi Ludovic, Ludovic Court=C3=A8s writes: > Hi! > > Maxim Cournoyer skribis: > >>> Perhaps services should allow specifying the minimum required Shepherd >>> version, which Shepherd could ensure is met before attempting to restart >>> a service, printing something like: >>> >>> 'Could not restart service X due to unmet Shepherd version requirement; >>> the service will continue unchanged until the next reboot' >>> >>> or something similar. > > Yes. The issue is that we=E2=80=99re more free-style than systemd: we=E2= =80=99re > basically loading code live in the running Shepherd. So we have to > write that code such that it works with older Shepherd versions. > > This is why we have things like conditions on > > (defined? 'make-inetd-constructor) > > and the likes, with a fallback. I saw that used somewhere, but I still think a minimally required Shepherd version field could be of use on services, for the following reasons: 1. Otherwise each services are left implementing ad-hoc solutions. 2. It's more complicated to be compatible with two Shepherd version than simply mentioning the minimum version required, and prevent the service from running until it is satisfied (especially on a system like Guix System where we *know* what is the current version of Shepherd available). Thanks, Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 29 Aug 2022 13:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Cc: Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.16617806021382 (code B ref 55898); Mon, 29 Aug 2022 13:44:01 +0000 Received: (at 55898) by debbugs.gnu.org; 29 Aug 2022 13:43:22 +0000 Received: from localhost ([127.0.0.1]:60436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSf2w-0000MD-1H for submit@debbugs.gnu.org; Mon, 29 Aug 2022 09:43:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSf2u-0000Ly-8o for 55898@debbugs.gnu.org; Mon, 29 Aug 2022 09:43:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42484) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSf2o-0001il-CM; Mon, 29 Aug 2022 09:43:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=602L5BLSNIeZAvWZBbN1I34TaYEioswgjE7/Of+tLis=; b=Eaj1fW4mHbgh/G1nYdAH d45p68XtpS88m0E5/Q1VQWsWxv9rf7NppWEWQXhMoOB/BShf0Z9A+BRqYrGvCQzYgSaj5m9RdiD1Y Y7Pci3iMfj7e7gywjvHlMe0PU5VpCcALufCDXz2wvwPtOJ9pBfc0YBOXlwi2KF5BMcQPUzgDyYdUu ytb5T1Ji45NmEUh5G3gh6/BhX18OlE3ZKz40teoyGGm2XxwT2YjvvM77kxYdjI0uG1mxWRvC8aUgq zRHZLMTpexXVQ2llE4RjewbvQ770SntQ2rngga3Zh40mufCV6idFyysHMuqrBoOTBXwI5j/xx754s 1qcTrdLZfRaihw==; Received: from [193.50.110.104] (port=34990 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSf2n-0001Ut-VS; Mon, 29 Aug 2022 09:43:14 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> Date: Mon, 29 Aug 2022 15:43:11 +0200 In-Reply-To: <87r12fqf6j.fsf@gmail.com> (Maxim Cournoyer's message of "Thu, 21 Jul 2022 00:10:12 -0400") Message-ID: <87y1v75fo0.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) 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, Maxim Cournoyer skribis: > Ludovic Court=C3=A8s writes: [...] >> Yes. The issue is that we=E2=80=99re more free-style than systemd: we= =E2=80=99re >> basically loading code live in the running Shepherd. So we have to >> write that code such that it works with older Shepherd versions. >> >> This is why we have things like conditions on >> >> (defined? 'make-inetd-constructor) >> >> and the likes, with a fallback. > > I saw that used somewhere, but I still think a minimally required > Shepherd version field could be of use on services, for the following > reasons: > > 1. Otherwise each services are left implementing ad-hoc solutions. > > 2. It's more complicated to be compatible with two Shepherd version than > simply mentioning the minimum version required, and prevent the service > from running until it is satisfied (especially on a system like Guix > System where we *know* what is the current version of Shepherd > available). I think it=E2=80=99s a situation similar to =E2=80=9Cfeature tests vs. iden= tity tests=E2=80=9D in build system configuration (checking whether the libc function you want to use is available rather than checking whether =E2=80=98uname=E2=80= =99 returns =E2=80=9CLinux=E2=80=9D), and for the same reason I tend to prefer feature = tests as shown above. I won=E2=80=99t pretend it=E2=80=99s pretty :-), but I don=E2=80=99t see an= improvement feasible in the short term. In the long term, maybe we=E2=80=99d want the service API in the Shepherd t= o be more declarative, more like packages in Guix. But that=E2=80=99s more for = a 2.0 horizon IMO. Perhaps we should close this issue unless it becomes actionable? Thanks, Ludo=E2=80=99. From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 29 Aug 2022 21:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.166180720624545 (code B ref 55898); Mon, 29 Aug 2022 21:07:02 +0000 Received: (at 55898) by debbugs.gnu.org; 29 Aug 2022 21:06:46 +0000 Received: from localhost ([127.0.0.1]:34025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSly1-0006Nn-Rr for submit@debbugs.gnu.org; Mon, 29 Aug 2022 17:06:46 -0400 Received: from mail-qk1-f175.google.com ([209.85.222.175]:46938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSly0-0006Nb-8V for 55898@debbugs.gnu.org; Mon, 29 Aug 2022 17:06:44 -0400 Received: by mail-qk1-f175.google.com with SMTP id a10so3232296qkl.13 for <55898@debbugs.gnu.org>; Mon, 29 Aug 2022 14:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc; bh=1SjmtTIgaw/Ch6CkkyLav3H49b2dd8z4KftQ/s1SE1k=; b=Gkr78BLqDJMv9Uvik09L71fTCcNUoDgO7Lp9JIC9XwZ2wBgdsNgkb+B5bF7HiaTEsr gSfk1dIuorku/g6rEH9eb9je19orgLcuJ+ykKuAiBQI/v2UoX8w4KNcAPuuleDKiJR9A Vgp3HPLlXAsD/fl04tzidmcBAShuzTQ0RWLUD5RyUGHOGyp9QzwhGjeM8PDdlUdzzqAv LAB84rnU4U6hwxsWBwtj09sM8Q4fOeoZUNNLbvnfhvynZpbQGjEBasan+LpEpzYAEChM Lr6/5Xru/8Tq8lu4/1KPzeXJLZsDB7jmIxGIwFKlnoXiGg+20JZdiM2D9Fem1PPCrmdx yTRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc; bh=1SjmtTIgaw/Ch6CkkyLav3H49b2dd8z4KftQ/s1SE1k=; b=hbsloQfaRmuXqxOaai9xMqM4dGUmX8lck44e5a2LDZSn7zsYjOWEGgExon9JdaIXjb JLr5fexn46PPyIQ2hH9R9s2/nHR7wnSkUfjsORBkyojnCpKabwO67XDmBAMp/S/xr3GL +0L5RKa9iSWztDZu1s5V9c7RffRr7857fdFJKK1fLJdhvAC5OxAzx2WsGi8U0+oITq1r 7xmLL+ChdNedjvhzFYZjaZKbmhnRnTc1U1k3s1DUbj+LsKo34I/7X6/qVj3/3bJngpgj 3QYi1ZOeEQc/T96uhkC/aZkvtPSAWgLd0c+MJ3fR64qFjRxDy4XrbXm5fK1uMlknwftu v7YQ== X-Gm-Message-State: ACgBeo2HaRdbUXSfAa4yBLwAaOh4wSbQa8ENkqUi3ZDlGSVU5dg0Xgtx oTu7xxNA9G0vZLQ8qbjKAlHV6wMU/9s= X-Google-Smtp-Source: AA6agR7ajQuyt2nVkOY2ThltQDEqIXK2tnN2/V7UTFNeeeCsTDP/kSU7szqoPoZMRq7s8DVdacG2Ow== X-Received: by 2002:a05:620a:f03:b0:6b6:6513:af63 with SMTP id v3-20020a05620a0f0300b006b66513af63mr9627933qkl.312.1661807198465; Mon, 29 Aug 2022 14:06:38 -0700 (PDT) Received: from hurd ([2607:fad8:4:3::1001]) by smtp.gmail.com with ESMTPSA id u3-20020a37ab03000000b006bc68cfcdf7sm6454017qke.13.2022.08.29.14.06.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Aug 2022 14:06:38 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> Date: Mon, 29 Aug 2022 17:06:36 -0400 In-Reply-To: <87y1v75fo0.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Mon, 29 Aug 2022 15:43:11 +0200") Message-ID: <8735debvz7.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Hi Ludovic, Ludovic Court=C3=A8s writes: > Hi, > > Maxim Cournoyer skribis: > >> Ludovic Court=C3=A8s writes: > > [...] > >>> Yes. The issue is that we=E2=80=99re more free-style than systemd: we= =E2=80=99re >>> basically loading code live in the running Shepherd. So we have to >>> write that code such that it works with older Shepherd versions. >>> >>> This is why we have things like conditions on >>> >>> (defined? 'make-inetd-constructor) >>> >>> and the likes, with a fallback. >> >> I saw that used somewhere, but I still think a minimally required >> Shepherd version field could be of use on services, for the following >> reasons: >> >> 1. Otherwise each services are left implementing ad-hoc solutions. >> >> 2. It's more complicated to be compatible with two Shepherd version than >> simply mentioning the minimum version required, and prevent the service >> from running until it is satisfied (especially on a system like Guix >> System where we *know* what is the current version of Shepherd >> available). > > I think it=E2=80=99s a situation similar to =E2=80=9Cfeature tests vs. id= entity tests=E2=80=9D > in build system configuration (checking whether the libc function you > want to use is available rather than checking whether =E2=80=98uname=E2= =80=99 returns > =E2=80=9CLinux=E2=80=9D), and for the same reason I tend to prefer featur= e tests as > shown above. Agreed, but the context differs wildly: while Autoconf or browsers for example really are facing a diversity of configuration, the version of Shepherd used in Guix System is known and controlled. So the only problems bound to happen are in this context: 1. New Shepherd version introduced in Guix (package upgrade). 2. New Shepherd features used by services. 3. Machine reconfigured using a commit including 1 and 2. The problems are temporary: upon a reboot the running Shepherd version will be the latest, and have all the features needed. Hence my suggestion to use something simple to improve the user experience of a user faced with 3. > I won=E2=80=99t pretend it=E2=80=99s pretty :-), but I don=E2=80=99t see = an improvement feasible > in the short term. > > In the long term, maybe we=E2=80=99d want the service API in the Shepherd= to be > more declarative, more like packages in Guix. But that=E2=80=99s more fo= r a 2.0 > horizon IMO. > > Perhaps we should close this issue unless it becomes actionable? It's a relatively narrow use case and it's relatively rare too, but I'd err on keeping it open until it gets fixed, whether in a definitive fashion or as a more limited one to help users facing 3. above. Thanks, and welcome back! Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 30 Aug 2022 07:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Cc: Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.166184484120605 (code B ref 55898); Tue, 30 Aug 2022 07:34:02 +0000 Received: (at 55898) by debbugs.gnu.org; 30 Aug 2022 07:34:01 +0000 Received: from localhost ([127.0.0.1]:34639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSvl2-0005MH-Qx for submit@debbugs.gnu.org; Tue, 30 Aug 2022 03:34:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSvl0-0005M5-Nz for 55898@debbugs.gnu.org; Tue, 30 Aug 2022 03:33:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50936) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSvks-0003Cp-ID; Tue, 30 Aug 2022 03:33:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=faw4JReprrlyF70WvkHZjiYvtxZjfZfD3AoaiVkRJHU=; b=ejQntbEMiLkEt60n90Jt f01b9ncfp9mDaODjm+TLePYsRatVwUowLcAGvnvH0xc+Rx72K7/so01Pl7ij76Y1NV8NooKt1KsYe bUIv6qsl1xy86wXDMlR6amEB0zV013oVZas4rPdzkIoOW27cV0WJ8tWqOvC9Ti26dE55DC3sPmdfu 45j8ACEY+0Xm9hJSXukw63IfmvYclIyHnQEv1BmFbtPM//X2f+5nTulT+36oTxsp4O6VjNEjZz2S+ +Dl6oFx4cGVN33knWiIdS2yWWA2g2iFeFHc/g7/IDplD3gomRNgnYzejY6Wj/y6ATDUQl3zz93vrS eCpzCM0cFT/qPg==; Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=46126 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSvks-00061g-4U; Tue, 30 Aug 2022 03:33:50 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Tridi 13 Fructidor an 230 de la =?UTF-8?Q?R=C3=A9volution,?= jour de =?UTF-8?Q?l'=C3=89pine-vinette?= 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, 30 Aug 2022 09:33:46 +0200 In-Reply-To: <8735debvz7.fsf@gmail.com> (Maxim Cournoyer's message of "Mon, 29 Aug 2022 17:06:36 -0400") Message-ID: <878rn6423p.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) 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 Maxim, Maxim Cournoyer skribis: > Agreed, but the context differs wildly: while Autoconf or browsers for > example really are facing a diversity of configuration, the version of > Shepherd used in Guix System is known and controlled. So the only > problems bound to happen are in this context: > > 1. New Shepherd version introduced in Guix (package upgrade). > > 2. New Shepherd features used by services. > > 3. Machine reconfigured using a commit including 1 and 2. > > The problems are temporary: upon a reboot the running Shepherd version > will be the latest, and have all the features needed. > > Hence my suggestion to use something simple to improve the user > experience of a user faced with 3. So are you suggesting replacing: (defined? 'make-inetd-constructor) by something like: (version Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 30 Aug 2022 09:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Maxim Cournoyer Cc: 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.166185213932519 (code B ref 55898); Tue, 30 Aug 2022 09:36:02 +0000 Received: (at 55898) by debbugs.gnu.org; 30 Aug 2022 09:35:39 +0000 Received: from localhost ([127.0.0.1]:34769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSxek-0008SR-OI for submit@debbugs.gnu.org; Tue, 30 Aug 2022 05:35:39 -0400 Received: from laurent.telenet-ops.be ([195.130.137.89]:47212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oSxej-0008SH-AL for 55898@debbugs.gnu.org; Tue, 30 Aug 2022 05:35:38 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by laurent.telenet-ops.be with bizsmtp id Dlbb2800120ykKC01lbbEm; Tue, 30 Aug 2022 11:35:35 +0200 Message-ID: Date: Tue, 30 Aug 2022 11:35:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> From: Maxime Devos In-Reply-To: <878rn6423p.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------10IW9VNW0SHa5KZKlfw0OX0X" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1661852135; bh=TDF9+B2k4HVZc8ycWCzIZ41M6ivsKqWWi/QcTSYyA0A=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=OaxjSwTAqRNNsadnylqmVeelA1kbpZwAsjw9z/nJW++5rY4RlJ1SUEFJ+u3FZGMdr NbkDrL/WywmBPx80KHH57cMFpVrCHi2C/8AHM3XppnJZui/crgw6aH0MRZSf7aStSm bi/kjr4A+uahS8if0iG8vmAJVtI9YuhZB/tQpGQObMOWPDjUFJamdomPM1QSO6gzhu Fixk8/Cb0p7fsn9M16/1Salkmx2ZBsX9/a7Gnn7MjQ+XnL7PpAUyrYyWwHuoiReqlh o2e68JnOdY5x0a+Vy04GJqcYqAQsfm68nINKr828nqJ+aMYUG0bSLZoI7ZDTS8DFDX M9FBIvTTPJTOw== 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 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------10IW9VNW0SHa5KZKlfw0OX0X Content-Type: multipart/mixed; boundary="------------M9I71MqxdFT6rrkXG4X3OX1A"; protected-headers="v1" From: Maxime Devos To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= , Maxim Cournoyer Cc: 55898@debbugs.gnu.org Message-ID: Subject: Re: bug#55898: Services depending on new Shepherd features may fail until reboot References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> In-Reply-To: <878rn6423p.fsf@gnu.org> --------------M9I71MqxdFT6rrkXG4X3OX1A Content-Type: multipart/mixed; boundary="------------2OQttkDRwmlrJUWjcVsZBE9i" --------------2OQttkDRwmlrJUWjcVsZBE9i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMzAtMDgtMjAyMiAwOTozMywgTHVkb3ZpYyBDb3VydMOocyB3cm90ZToNCg0KPiBTbyBh cmUgeW91IHN1Z2dlc3RpbmcgcmVwbGFjaW5nOg0KPg0KPiAgICAoZGVmaW5lZD8gJ21ha2Ut aW5ldGQtY29uc3RydWN0b3IpDQo+DQo+IGJ5IHNvbWV0aGluZyBsaWtlOg0KPg0KPiAgICAo dmVyc2lvbjw/IHNoZXBoZXJkLXZlcnNpb24gIjAuOS4wIikNCj4NCj4gb3IgaXMgaXQgc29t ZXRoaW5nIGRpZmZlcmVudCB0aGF0IHlvdSBoYXZlIGluIG1pbmQ/DQo+DQo+IEnigJltIG5v dCBzdXJlIGhvdyB0aGlzIGNvdWxkIGltcHJvdmUgdGhlIHVzZXIgZXhwZXJpZW5jZSwgdW5s ZXNzIGJ5DQo+IOKAnHVzZXLigJ0geW91IG1lYW4gdGhlIHBlcnNvbiB3cml0aW5nIHRoZSBz ZXJ2aWNlPw0KDQooZGVmaW5lZD8gJy4uLikgZG9lcyBub3Qgd29yayBpbiBhbGwgY29udGV4 dHMgLS0gaXQgd29ya3Mgb24gdGhlIA0KdG9wLWxldmVsLCBidXQgbm90IGFsd2F5cyBpbnNp ZGUgYSBwcm9jZWR1cmUsIGFzIGl0IHRlc3RzIGlmIHRoZSB0aGluZyANCmlzIGRlZmluZWQg aW4gKGN1cnJlbnQtbW9kdWxlKSwgYW5kIG5vdCB3aGV0aGVyIGl0IGlzIGRlZmluZWQgaW4g dGhlIA0KbW9kdWxlIHRoYXQgY2FsbHMgKGRlZmluZWQ/ICcuLi4pLg0KDQpQZXJoYXBzIGl0 IHdvcmtzIGZpbmUgaW4gdGhlIHdheSBpdCBpcyB1c2VkIGluIEd1aXggY3VycmVudGx5LCBi dXQgQUZBSUsgDQppdCBpcyBub3QgZ3VhcmFudGVlZCBhbnl3aGVyZS4gQXMgc3VjaCwgSSBj YW5ub3QgcmVjb21tZW5kIGRlZmluZWQ/IA0KaGVyZS4gVGhlIHZlcnNpb248PyBkb2VzIG5v dCBoYXZlIHRoaXMgcHJvYmxlbS4NCg0KQSBoeXBvdGhldGljYWwgZGVmaW5lZC1pbi10aGlz LW1vZHVsZSBtYWNybyB3b3VsZCBiZSBpZGVhbCwgYnV0IHN1Y2ggYSANCnRoaW5nIGRvZXMg bm90IGV4aXN0IHlldC4NCg0KR3JlZXRpbmdzLA0KTWF4aW1lLg0KDQo= --------------2OQttkDRwmlrJUWjcVsZBE9i Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------2OQttkDRwmlrJUWjcVsZBE9i-- --------------M9I71MqxdFT6rrkXG4X3OX1A-- --------------10IW9VNW0SHa5KZKlfw0OX0X Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYw3Z5gUDAAAAAAAKCRBJ4+4iGRcl7nOs AQC8LINDRbXMRPu6ay6AkyMf8DzeWx91XhFJrgZQz4n+tQD+KK+APFqeZnsmQIlRh49zfIWHBY3m hgFPUOXaMq9nZgM= =mY6a -----END PGP SIGNATURE----- --------------10IW9VNW0SHa5KZKlfw0OX0X-- From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 30 Aug 2022 13:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxime Devos Cc: 55898@debbugs.gnu.org, Maxim Cournoyer Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.166186745818787 (code B ref 55898); Tue, 30 Aug 2022 13:51:02 +0000 Received: (at 55898) by debbugs.gnu.org; 30 Aug 2022 13:50:58 +0000 Received: from localhost ([127.0.0.1]:35198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oT1dq-0004sx-AY for submit@debbugs.gnu.org; Tue, 30 Aug 2022 09:50:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:32950) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oT1do-0004sj-97 for 55898@debbugs.gnu.org; Tue, 30 Aug 2022 09:50:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52812) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oT1di-000850-0V; Tue, 30 Aug 2022 09:50:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=KFQeoqDiBT61Boy8EON4lQPXzpLDQdKOdRqVld5fOFA=; b=RU4pSsSnz1P4CoCDoZkM CF/A2+CxMfVW2Kb8d13q3BMJ9KmL4fhLypIIBnJMfjF59DmaagtoBpOQzIZtM0jhOcZ8MH4mu5yrJ kOfRLwvdlErVj5g2U6O1lM1+SVYA9jk1natU58pEvvPKs5zi2mWuHOlFT/y7IXLPS2lMZ3MiX0z8+ cuTdqIGWnpGWyCoZnLnwSSup1NJefqk7fmoKLdPzsqWuPUMrA7XhCDtpb3JDCcwILJlBmnIZW8WQ6 XU+ljohcO+rJYUXTMEM0jLA3Q43Ga21GtcqoOFX2WAQ3GVgK+nhrVwnebuszsxk+rp0fu7aF5yHhb wdxFUO1afqOQDA==; Received: from [193.50.111.124] (port=49814 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oT1dh-0004RY-J3; Tue, 30 Aug 2022 09:50:49 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Tridi 13 Fructidor an 230 de la =?UTF-8?Q?R=C3=A9volution,?= jour de =?UTF-8?Q?l'=C3=89pine-vinette?= 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, 30 Aug 2022 15:50:48 +0200 In-Reply-To: (Maxime Devos's message of "Tue, 30 Aug 2022 11:35:34 +0200") Message-ID: <87fshdyh53.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) 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 (---) Maxime Devos skribis: > On 30-08-2022 09:33, Ludovic Court=C3=A8s wrote: > >> So are you suggesting replacing: >> >> (defined? 'make-inetd-constructor) >> >> by something like: >> >> (version> >> or is it something different that you have in mind? >> >> I=E2=80=99m not sure how this could improve the user experience, unless = by >> =E2=80=9Cuser=E2=80=9D you mean the person writing the service? > > (defined? '...) does not work in all contexts -- it works on the > top-level, but not always inside a procedure, as it tests if the thing > is defined in (current-module), and not whether it is defined in the > module that calls (defined? '...). Right, but that=E2=80=99s a bit of a theoretical concern in my view. Alternatively, one could write: (module-defined? (resolve-interface '(shepherd service)) 'make-inetd-constructor) Thanks, Ludo=E2=80=99. From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 01 Sep 2022 13:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.16620382903122 (code B ref 55898); Thu, 01 Sep 2022 13:19:02 +0000 Received: (at 55898) by debbugs.gnu.org; 1 Sep 2022 13:18:10 +0000 Received: from localhost ([127.0.0.1]:41600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTk5C-0000oI-Hn for submit@debbugs.gnu.org; Thu, 01 Sep 2022 09:18:10 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:41918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTk5A-0000o5-V2 for 55898@debbugs.gnu.org; Thu, 01 Sep 2022 09:18:09 -0400 Received: by mail-qt1-f169.google.com with SMTP id c20so13309730qtw.8 for <55898@debbugs.gnu.org>; Thu, 01 Sep 2022 06:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date; bh=QNlfrXDLpasbpErdg7VwMnVWfdB6mmCftMVzFN+I6YU=; b=oy/cZW1lY1D3anQ6QBBsrOdIEXnEiLcco/6nQ9YtAMkJY/3DFiazkdo8zkYVWxGBup Q4spEEDIdNwDYP51w6ls76TumjrroZAbZwfmy8wIjnWD6QsgSh+rmcu4wO7Y3Szocjcj KeU02hQpgtIw96MRp6oU39EEM6EYTxBPthfa04yaN/vIxd6vpxIke7ARw/L2shTmyn+6 VHKc/oD97rGujgbNcMVnzrNAzqBxrVgIWJPF8jCoUhnsee/W4ypqIkx8enLwSGQaCNsG mI1hwiKd+y+iXx6iaXWlAf6kvq1dNwRGfjfL+t0muAVc64voseh7yRMoxSixcfUaHBc7 PmIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date; bh=QNlfrXDLpasbpErdg7VwMnVWfdB6mmCftMVzFN+I6YU=; b=oVJNs2a0+HgFhPsnnWwrReWUMEGM9QLLlblvAHyZWmOV21yOCMqW2ded3pZDdh1tGN 5WPpNe9pUIHexZoFueKus7RGQGRd8qMQkSIc263hsNw1g1H6jNuzh1JZNXtryjT3QUSp cihMA2GdZ6E9/yXUAZ31S/JIV56BpTPaYlk0Rp3Uj7WaOxP6l/EwDN9jCyVaQ1VFLinw 1CGj+JbFivftjNgZY7rmr532XM0APghAKIo5MwcUVjbhHNmRGoEZxq11Z1apeFtn1Zxg +IxWwSt9RUe4G3tJGudEAq7uFIvOvzezNrckgN4ccUJKqy/Tjf8AUknSPQei2o4PtjE4 F/bA== X-Gm-Message-State: ACgBeo3eTLXG75MEWpjeELh/kZmfq4Hrk8EPrZrWUqpQ/fM4Y1M1OUTZ RF48JHN8Ff7J5o5+ujVatjIxvlhVrtY= X-Google-Smtp-Source: AA6agR5xU2YjemTtrJ6kjiOUWgFwPw9jB8dD3movMAa73S6mwnawxxJ0l0YJsY/hMOiOb0gi/KHl1w== X-Received: by 2002:ac8:5d8f:0:b0:344:a747:abf1 with SMTP id d15-20020ac85d8f000000b00344a747abf1mr23704457qtx.273.1662038283134; Thu, 01 Sep 2022 06:18:03 -0700 (PDT) Received: from hurd (dsl-10-128-104.b2b2c.ca. [72.10.128.104]) by smtp.gmail.com with ESMTPSA id bk42-20020a05620a1a2a00b006aedb35d8a1sm12381507qkb.74.2022.09.01.06.18.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Sep 2022 06:18:02 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> Date: Thu, 01 Sep 2022 09:18:01 -0400 In-Reply-To: <878rn6423p.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Tue, 30 Aug 2022 09:33:46 +0200") Message-ID: <87tu5r8c8m.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Hi, Ludovic Court=C3=A8s writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> Agreed, but the context differs wildly: while Autoconf or browsers for >> example really are facing a diversity of configuration, the version of >> Shepherd used in Guix System is known and controlled. So the only >> problems bound to happen are in this context: >> >> 1. New Shepherd version introduced in Guix (package upgrade). >> >> 2. New Shepherd features used by services. >> >> 3. Machine reconfigured using a commit including 1 and 2. >> >> The problems are temporary: upon a reboot the running Shepherd version >> will be the latest, and have all the features needed. >> >> Hence my suggestion to use something simple to improve the user >> experience of a user faced with 3. > > So are you suggesting replacing: > > (defined? 'make-inetd-constructor) > > by something like: > > (version > or is it something different that you have in mind? I had something different on mind; I was thinking of some added field to our shepherd-service object where the minimal version of Shepherd required could be specified, e.g. "0.9.1". The check could be abstracted in the shepherd-service implementation, avoiding services writers to handle that by themselves in *each* service requiring so. The benefit would be an improved user experience, and cleaner service code. Upon reconfiguring a machine not yet equipped with a new enough Shepherd, Shepherd could print: --8<---------------cut here---------------start------------->8--- The x, y and z services won't be started until the next reboot, as they require a newer Shepherd version. --8<---------------cut here---------------end--------------->8--- Instead of seeing the new services fail to run without (for the end user) without any obvious reason. Does that make sense? Thanks, Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 01 Sep 2022 13:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer , Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.16620388874070 (code B ref 55898); Thu, 01 Sep 2022 13:29:01 +0000 Received: (at 55898) by debbugs.gnu.org; 1 Sep 2022 13:28:07 +0000 Received: from localhost ([127.0.0.1]:41619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTkEp-00013a-4a for submit@debbugs.gnu.org; Thu, 01 Sep 2022 09:28:07 -0400 Received: from andre.telenet-ops.be ([195.130.132.53]:41436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTkEl-00013P-P1 for 55898@debbugs.gnu.org; Thu, 01 Sep 2022 09:28:04 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by andre.telenet-ops.be with bizsmtp id EdU22800320ykKC01dU29z; Thu, 01 Sep 2022 15:28:02 +0200 Message-ID: Date: Thu, 1 Sep 2022 15:28:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> <87tu5r8c8m.fsf@gmail.com> From: Maxime Devos In-Reply-To: <87tu5r8c8m.fsf@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------dQR3OBbGOplxklrs09Yg84p0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1662038882; bh=kCCSzxQ/nKhcMt7zXk9T/m+VvZCwE2z4IC65IV9YUHg=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=J8Xm6mqo5P9NCuzrEvBvOQq6OMm7Z/ctd1DX+OSZfbtsF2eI4nm/VuaH8iJXnA0f3 yK0JxUWGMw4/G716p3xPa9hGOiQXgQtCmkCa4Tvq5+ZC0NVMictabs5Zfq/pFKkwWA uPxCm9XPTCHzKnXnWhO012u0m5vwcGAspYSkelLcL6ajX99g909NyLhN0PUEIcuU7d qIyV9m3Sg12oqtOnio/xQEjLzoVzt6AyMN+aU4Z82kHMWkS2DrQA5VDsy1939V8Iyi LctzZjNrrvs4WhX9EB3oFU7tH7kld98OtYQDweCpw5Hl1t0hPwu6q8zg7Wo4Q4Q953 4aDGTSU+GMyKQ== X-Spam-Score: -0.7 (/) 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.7 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------dQR3OBbGOplxklrs09Yg84p0 Content-Type: multipart/mixed; boundary="------------opDFjEPghKsi97T0Je9L3Wtj"; protected-headers="v1" From: Maxime Devos To: Maxim Cournoyer , =?UTF-8?Q?Ludovic_Court=c3=a8s?= Cc: 55898@debbugs.gnu.org Message-ID: Subject: Re: bug#55898: Services depending on new Shepherd features may fail until reboot References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> <87tu5r8c8m.fsf@gmail.com> In-Reply-To: <87tu5r8c8m.fsf@gmail.com> --------------opDFjEPghKsi97T0Je9L3Wtj Content-Type: multipart/mixed; boundary="------------i0b1Du86fM8qoPnxbrJN1910" --------------i0b1Du86fM8qoPnxbrJN1910 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEtMDktMjAyMiAxNToxOCwgTWF4aW0gQ291cm5veWVyIHdyb3RlOg0KDQo+IEkgaGFk IHNvbWV0aGluZyBkaWZmZXJlbnQgb24gbWluZDsgSSB3YXMgdGhpbmtpbmcgb2Ygc29tZSBh ZGRlZCBmaWVsZCB0bw0KPiBvdXIgc2hlcGhlcmQtc2VydmljZSBvYmplY3Qgd2hlcmUgdGhl IG1pbmltYWwgdmVyc2lvbiBvZiBTaGVwaGVyZA0KPiByZXF1aXJlZCBjb3VsZCBiZSBzcGVj aWZpZWQsIGUuZy4gIjAuOS4xIi4NCj4NCj4gVGhlIGNoZWNrIGNvdWxkIGJlIGFic3RyYWN0 ZWQgaW4gdGhlIHNoZXBoZXJkLXNlcnZpY2UgaW1wbGVtZW50YXRpb24sDQo+IGF2b2lkaW5n IHNlcnZpY2VzIHdyaXRlcnMgdG8gaGFuZGxlIHRoYXQgYnkgdGhlbXNlbHZlcyBpbiplYWNo KiAgc2VydmljZQ0KPiByZXF1aXJpbmcgc28uDQo+DQo+IFRoZSBiZW5lZml0IHdvdWxkIGJl IGFuIGltcHJvdmVkIHVzZXIgZXhwZXJpZW5jZSwgYW5kIGNsZWFuZXIgc2VydmljZQ0KPiBj b2RlLiAgVXBvbiByZWNvbmZpZ3VyaW5nIGEgbWFjaGluZSBub3QgeWV0IGVxdWlwcGVkIHdp dGggYSBuZXcgZW5vdWdoDQo+IFNoZXBoZXJkLCBTaGVwaGVyZCBjb3VsZCBwcmludDoNCj4N Cj4gLS04PC0tLS0tLS0tLS0tLS0tLWN1dCBoZXJlLS0tLS0tLS0tLS0tLS0tc3RhcnQtLS0t LS0tLS0tLS0tPjgtLS0NCj4gVGhlIHgsIHkgYW5kIHogc2VydmljZXMgd29uJ3QgYmUgc3Rh cnRlZCB1bnRpbCB0aGUgbmV4dCByZWJvb3QsIGFzIHRoZXkNCj4gcmVxdWlyZSBhIG5ld2Vy IFNoZXBoZXJkIHZlcnNpb24uDQo+IC0tODwtLS0tLS0tLS0tLS0tLS1jdXQgaGVyZS0tLS0t LS0tLS0tLS0tLWVuZC0tLS0tLS0tLS0tLS0tLT44LS0tDQo+DQo+IEluc3RlYWQgb2Ygc2Vl aW5nIHRoZSBuZXcgc2VydmljZXMgZmFpbCB0byBydW4gd2l0aG91dCAoZm9yIHRoZSBlbmQN Cj4gdXNlcikgd2l0aG91dCBhbnkgb2J2aW91cyByZWFzb24uDQo+DQo+IERvZXMgdGhhdCBt YWtlIHNlbnNlPw0KSSBsaWtlIHRoaXMgc3lzdGVtLCBpdCdzIGRlY2xhcmF0aXZlLCBzaW1w bGUgYW5kIGRvZXNuJ3QgaGF2ZSB0aGUgDQpkZWZpbmVkPy1sb29rcy1pbi0oY3VycmVudC1t b2R1bGUpIHByb2JsZW0uIEl0IGFsc28gYXZvaWRzIGFjY3VtdWxhdGluZyANCmNvbXBhdGli aWxpdHkgZmFsbGJhY2tzIHRoYXQgcHJvYmFibHkgd29uJ3QgYmUgd2VsbC10ZXN0ZWQuDQoN CklmIHNvbWV0aGluZyBsaWtlIChkZWZpbmVkPyAnd2hhdGV2ZXIpIGlzIGRlc2lyZWQgaW5z dGVhZCBvZiB2ZXJzaW9uIA0KY2hlY2tzICh0aG91Z2ggSSBkb24ndCBzZWUgdGhlIHZhbHVl IGhlcmUsIHNlZSBNYXhpbSBleHBsYW5hdGlvbiBvbiANCmRpZmZlcmVudCBjb250ZXh0cyks IGEgc2ltaWxhciBzeXN0ZW0gYmFzZWQgb24gZmVhdHVyZSBjaGVja3MgY291bGQgYmUgDQp1 c2VkIGluc3RlYWQ6DQoNCihyZXF1aXJlLWV4cG9ydHMgOyA8LS0gdGhlIGZpZWxkDQogwqAg JygoKG1vZHVsZSBuYW1lKSB0aGlzIHRoYXQgLi4uKQ0KIMKgwqDCoCBbLi4uXSkpDQoNClRo ZSAoaWYgKGRlZmluZWQ/IC4uLikgcHJlZmVycmVkIGNvbXBhdCkgcGF0dGVybiBjb3VsZCBi ZSBwcmVzZXJ2ZWQgZm9yIA0KdGhlIGNhc2Ugd2hlcmUgYSBwYXRjaCBhdXRob3IgcHV0cyBp biBzb21lIGV4dHJhIGVmZm9ydCB0byBub3QgcmVxdWlyZSANCnJlYm9vdHMgb24gc3lzdGVt cyB3aGVyZSBhbiBvbGQgc2hlcGhlcmQgaXMgcnVubmluZywgYnV0IGEgc2ltcGxlIA0KdmVy c2lvbiBjaGVjayBvciBmZWF0dXJlIGNoZWNrIHdvdWxkIGJlIGFjY2VwdGVkIHRvby4NCg0K R3JlZXRpbmdzLA0KTWF4aW1lLg0K --------------i0b1Du86fM8qoPnxbrJN1910 Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------i0b1Du86fM8qoPnxbrJN1910-- --------------opDFjEPghKsi97T0Je9L3Wtj-- --------------dQR3OBbGOplxklrs09Yg84p0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxCzYQUDAAAAAAAKCRBJ4+4iGRcl7rVA AP9oNcklmxenyKYhb0N2y7KFeuWNwE/4DPyoskxRCQZHOwEAjFHsAq18j4tNOd7uzVre9iGSqmlt zsYtKX1fJpdnHAQ= =T9hq -----END PGP SIGNATURE----- --------------dQR3OBbGOplxklrs09Yg84p0-- From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 01 Sep 2022 13:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Cc: Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.16620403026647 (code B ref 55898); Thu, 01 Sep 2022 13:52:02 +0000 Received: (at 55898) by debbugs.gnu.org; 1 Sep 2022 13:51:42 +0000 Received: from localhost ([127.0.0.1]:41663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTkbd-0001j9-Sd for submit@debbugs.gnu.org; Thu, 01 Sep 2022 09:51:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTkbc-0001iv-2h for 55898@debbugs.gnu.org; Thu, 01 Sep 2022 09:51:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52490) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTkbW-0007zJ-Am; Thu, 01 Sep 2022 09:51:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=D5Zen6tSvJFnNYnNd+ifTYfYMzlgv7Wkhw+9kmriALA=; b=dM9Oumn+zqMEgkdlkVcw Kj4wX20A0po+/E/cHZYPVwQ2JMlht4XnC+2ZGk2xGgd9MY2Zgu88FefzQiXot8lxT1/+q40mkDcYj s+IVtYEVuh2YQJNvdCM2vu1KSP3xhgoxB6AxM0KcodH+iN9wnSwKuNl68ywtRk+Jh876jjBfeKf9/ y1uG6n8wqZ4Z/l2IcaFsOI3HPv0Ml/uUzkAZ8ZhX2bIGEX2XxEr88DLxo6eT0H/ixz7k0hg4NUIbU A/80tDeaWlT2rlX+Zfg8JAbUxt282ufoklzXUpqxoRygh9+i3Fbp25fOrs22HmNGQCjGSwIX1CHDb sFbY0quhQQcV7A==; Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=43860 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTkbV-0004N9-OA; Thu, 01 Sep 2022 09:51:34 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> <87tu5r8c8m.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Quintidi 15 Fructidor an 230 de la =?UTF-8?Q?R=C3=A9volution,?= jour de la Truite 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: Thu, 01 Sep 2022 15:51:31 +0200 In-Reply-To: <87tu5r8c8m.fsf@gmail.com> (Maxim Cournoyer's message of "Thu, 01 Sep 2022 09:18:01 -0400") Message-ID: <87fshb2of0.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) 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 (---) Howdy! Maxim Cournoyer skribis: > I had something different on mind; I was thinking of some added field to > our shepherd-service object where the minimal version of Shepherd > required could be specified, e.g. "0.9.1". > > The check could be abstracted in the shepherd-service implementation, > avoiding services writers to handle that by themselves in *each* service > requiring so. Hmm I see. > The benefit would be an improved user experience, and cleaner service > code. Upon reconfiguring a machine not yet equipped with a new enough > Shepherd, Shepherd could print: > > The x, y and z services won't be started until the next reboot, as they > require a newer Shepherd version. > > Instead of seeing the new services fail to run without (for the end > user) without any obvious reason. Currently, new services don=E2=80=99t fail to run: we arrange so that new services always =E2=80=9Cwork=E2=80=9D, whether they=E2=80=99re talking to = an old shepherd or a new one. The user experience (bugs aside) should be good: services are always reloaded. IIUC, in the model you propose, we=E2=80=99d sacrifice this, by admitting t= hat in some cases we just won=E2=80=99t load services live and instead tell use= rs to reboot; the benefit would be cleaner service code. It=E2=80=99s a tradeoff; the cost/benefit ratio is not obvious to me. Thanks for explaining! Ludo=E2=80=99. From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 01 Sep 2022 19:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.166205980425412 (code B ref 55898); Thu, 01 Sep 2022 19:17:02 +0000 Received: (at 55898) by debbugs.gnu.org; 1 Sep 2022 19:16:44 +0000 Received: from localhost ([127.0.0.1]:44192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTpgB-0006bn-KK for submit@debbugs.gnu.org; Thu, 01 Sep 2022 15:16:43 -0400 Received: from mail-qk1-f175.google.com ([209.85.222.175]:38789) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTpgA-0006bb-75 for 55898@debbugs.gnu.org; Thu, 01 Sep 2022 15:16:42 -0400 Received: by mail-qk1-f175.google.com with SMTP id g21so94061qka.5 for <55898@debbugs.gnu.org>; Thu, 01 Sep 2022 12:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date; bh=UHbhXWAJGIfMLuPN7UrXoa2OBCjmhtgCPhV8lURRhcM=; b=neF7yqywXi1WiHCfW8CIRN8MAr4x6OV7WHVTO9j2C4WVyUz1L64x54k1Ou1AYYtHVN DQ+SnUXGHINXdyruOHfgvuY9LEvlWsiA1OmwiruI4XLyH5S2ikVOUepAl59nhiAAtvCR N6aGJHS3C+xplxQz7RE5H6JyFANy6W8uWXiIF04/Hn0quycA2/4Caw22lJ+TVmsTY1WL QH9m3QFPq6p4ijIQeDBpY/6WKXAdttxM68LB/etSo5cYq+Hwwclqywx85DUppoZQGO3M b4xDE4yGzVt1oZi5D/QvGZUwJ2L4i03TtbLF4NjJW+SkHJoYiwDcZhMIp/ikVo1vIY10 SQVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date; bh=UHbhXWAJGIfMLuPN7UrXoa2OBCjmhtgCPhV8lURRhcM=; b=CZlSFBVSITLwdeTmJHd6KdUJunW3NMpu4v53K9B8oX2XLc1C0UUv5oJd5XqE9VrXQA YBrJrPvI3m6EIHXmRIiWE666Oh8odYn4pGoQuNwI69bCx9RNwM9HEtozDNf+ucc6zCfn EXUfLExcErbCeaJxglSYEnmPWN7yboBy3dVxXdmRQWZQoU9QDBzoEo7IUjCFi55Ocnr9 YLrivThki5p7EXSG1K0bRp37GwJJNtN3to7dGd1P1A2KNMQY/yEQ1u5Y1q+RzyHJFFU1 6nJZcjkHXASBSMUmLkn7E8UCH794cCyCgdlT8uuKnbA9t689hp2Bbn746u2L3MFll7ag YQdA== X-Gm-Message-State: ACgBeo0cSe6UaY0FEIa3RWVBXRrHeiloxujbDdDxFBf2BahUjo+112K9 rQvFgvqXItnZ4rHosoDHviKGCIaJs48= X-Google-Smtp-Source: AA6agR7nDkMsgVlNGysxvSAHsVK5+J/ifxXX8sYRXsEagGZmjn6waEjynV13Wou5jsFAIJNOHRd5og== X-Received: by 2002:a05:620a:2942:b0:6bb:822c:cca0 with SMTP id n2-20020a05620a294200b006bb822ccca0mr20457592qkp.326.1662059796073; Thu, 01 Sep 2022 12:16:36 -0700 (PDT) Received: from hurd (dsl-10-128-104.b2b2c.ca. [72.10.128.104]) by smtp.gmail.com with ESMTPSA id x13-20020a05620a258d00b006b640efe6dasm12529956qko.132.2022.09.01.12.16.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Sep 2022 12:16:35 -0700 (PDT) From: Maxim Cournoyer References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> <87tu5r8c8m.fsf@gmail.com> <87fshb2of0.fsf@gnu.org> Date: Thu, 01 Sep 2022 15:16:33 -0400 In-Reply-To: <87fshb2of0.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Thu, 01 Sep 2022 15:51:31 +0200") Message-ID: <87ilm69a7i.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Hi, Ludovic Court=C3=A8s writes: > Howdy! > > Maxim Cournoyer skribis: > >> I had something different on mind; I was thinking of some added field to >> our shepherd-service object where the minimal version of Shepherd >> required could be specified, e.g. "0.9.1". >> >> The check could be abstracted in the shepherd-service implementation, >> avoiding services writers to handle that by themselves in *each* service >> requiring so. > > Hmm I see. > >> The benefit would be an improved user experience, and cleaner service >> code. Upon reconfiguring a machine not yet equipped with a new enough >> Shepherd, Shepherd could print: >> >> The x, y and z services won't be started until the next reboot, as they >> require a newer Shepherd version. >> >> Instead of seeing the new services fail to run without (for the end >> user) without any obvious reason. > > Currently, new services don=E2=80=99t fail to run: we arrange so that new > services always =E2=80=9Cwork=E2=80=9D, whether they=E2=80=99re talking t= o an old shepherd or a > new one. The user experience (bugs aside) should be good: services are > always reloaded. This depends on how the services are written, and how much care to this edge case their author put into writing it. I know the Jami service type won't run without Shepherd >=3D 0.9.0, and the solution is not obvious (I'm suspecting sleep* from (guix build dbus-service) should use regular sleep when shepherd is < 0.9.0.). > IIUC, in the model you propose, we=E2=80=99d sacrifice this, by admitting= that > in some cases we just won=E2=80=99t load services live and instead tell u= sers to > reboot; the benefit would be cleaner service code. > > It=E2=80=99s a tradeoff; the cost/benefit ratio is not obvious to me. Having a simple way to cleanly mark a service as "requiring Shepherd 0.9.X" would provide good value in my opinion, for when adding backward compatibility is too difficult or not desirable for any reason (such as causing long 'hangs' while busy-waiting for a process to start in older shepherds). Thanks, Maxim From unknown Sat Jun 14 03:52:19 2025 X-Loop: help-debbugs@gnu.org Subject: bug#55898: Services depending on new Shepherd features may fail until reboot Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 02 Sep 2022 09:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55898 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Cc: Maxime Devos , 55898@debbugs.gnu.org Received: via spool by 55898-submit@debbugs.gnu.org id=B55898.166210986512502 (code B ref 55898); Fri, 02 Sep 2022 09:12:01 +0000 Received: (at 55898) by debbugs.gnu.org; 2 Sep 2022 09:11:05 +0000 Received: from localhost ([127.0.0.1]:44852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oU2hd-0003Fa-Co for submit@debbugs.gnu.org; Fri, 02 Sep 2022 05:11:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oU2hb-0003Eb-EO for 55898@debbugs.gnu.org; Fri, 02 Sep 2022 05:11:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56130) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU2hV-0002xy-1n; Fri, 02 Sep 2022 05:10:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=AfnVyyPcWfYmy20QhOw75L7th/ok5LpnyLxQ6qhZ+YI=; b=fH4bYQzcy41bhRtG7n+S t+FB2FqldIMyGes3snnWGLcty2mQOKILD9aTI+wHx/mYLaqiWRHKvu5u+APaPPVyuCk+1coN6YU13 atd4zvJDDpfhbrN2kpGdaCzG4slukBvbmaU++6cWVKtt1kVKmGjHIE+k4vITT9QQva9UyeJQ0f+eS h3lvq+B4QC3RqOd+yLY5QDuEY4DFk82ZjNgriIsnYfRH7V+vNqF9Ch/gXorguguLOxlYcDvxmCguz bSr01LGlHJvzsllNmxKPAU7Y34NWeHGtFuwdhlEh++ZcJx+CKAqzffBTJ/HZm8acBnTz17F/9UcMj 360hLMUXnjnLQg==; Received: from [193.50.110.177] (port=47470 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU2hL-0002Ih-6w; Fri, 02 Sep 2022 05:10:54 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> <87tu5r8c8m.fsf@gmail.com> <87fshb2of0.fsf@gnu.org> <87ilm69a7i.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Sextidi 16 Fructidor an 230 de la =?UTF-8?Q?R=C3=A9volution,?= jour du Citron 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: Fri, 02 Sep 2022 11:10:45 +0200 In-Reply-To: <87ilm69a7i.fsf@gmail.com> (Maxim Cournoyer's message of "Thu, 01 Sep 2022 15:16:33 -0400") Message-ID: <87wnamxht6.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) 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 Maxim, Maxim Cournoyer skribis: >> Currently, new services don=E2=80=99t fail to run: we arrange so that new >> services always =E2=80=9Cwork=E2=80=9D, whether they=E2=80=99re talking = to an old shepherd or a >> new one. The user experience (bugs aside) should be good: services are >> always reloaded. > > This depends on how the services are written, and how much care to this > edge case their author put into writing it. I know the Jami service > type won't run without Shepherd >=3D 0.9.0, and the solution is not > obvious (I'm suspecting sleep* from (guix build dbus-service) should use > regular sleep when shepherd is < 0.9.0.). Ah, that=E2=80=99s an exception then, and this should be avoided IMO. :-) Usually, the Shepherd=E2=80=99s API is backward compatible, so one can norm= ally leave services unchanged. It=E2=80=99s only when you want to take advantag= e of the new features that you have to resort to conditionals. But then more complex services like Jami or childhurd were more likely to hit edge cases with the switch to Fibers. >> IIUC, in the model you propose, we=E2=80=99d sacrifice this, by admittin= g that >> in some cases we just won=E2=80=99t load services live and instead tell = users to >> reboot; the benefit would be cleaner service code. >> >> It=E2=80=99s a tradeoff; the cost/benefit ratio is not obvious to me. > > Having a simple way to cleanly mark a service as "requiring Shepherd > 0.9.X" would provide good value in my opinion, for when adding backward > compatibility is too difficult or not desirable for any reason (such as > causing long 'hangs' while busy-waiting for a process to start in older > shepherds). Right, I agree it=E2=80=99d be useful in those cases. (Though having to busy-wait is not a valid reason IMO: it=E2=80=99s a sign we should provide = the proper abstraction to avoid busy waiting.) I don=E2=80=99t have a clear idea on how to implement it now, but we should= keep that in mind. Thanks, Ludo=E2=80=99.