From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4K0nMa6tVWALQQAA0tVLHw (envelope-from ) for ; Sat, 20 Mar 2021 08:09:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id SKUNLa6tVWDxGgAA1q6Kng (envelope-from ) for ; Sat, 20 Mar 2021 08:09:18 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 13E5F161C8 for ; Sat, 20 Mar 2021 09:09:18 +0100 (CET) Received: from localhost ([::1]:48798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNWfd-0003Ku-61 for larch@yhetil.org; Sat, 20 Mar 2021 04:09:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNWfP-0003Ki-9E for bug-guix@gnu.org; Sat, 20 Mar 2021 04:09:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:39911) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lNWfO-0005WA-1a for bug-guix@gnu.org; Sat, 20 Mar 2021 04:09:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lNWfN-0000QO-TD for bug-guix@gnu.org; Sat, 20 Mar 2021 04:09:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47253: network-manager shepherd services does not wait to be online Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 20 Mar 2021 08:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47253 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: raid5atemyhomework Received: via spool by 47253-submit@debbugs.gnu.org id=B47253.16162277351618 (code B ref 47253); Sat, 20 Mar 2021 08:09:01 +0000 Received: (at 47253) by debbugs.gnu.org; 20 Mar 2021 08:08:55 +0000 Received: from localhost ([127.0.0.1]:51457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNWfG-0000Q1-S2 for submit@debbugs.gnu.org; Sat, 20 Mar 2021 04:08:55 -0400 Received: from world.peace.net ([64.112.178.59]:59980) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNWfD-0000Po-2B for 47253@debbugs.gnu.org; Sat, 20 Mar 2021 04:08:53 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lNWf6-0001Md-S0; Sat, 20 Mar 2021 04:08:44 -0400 From: Mark H Weaver In-Reply-To: References: <87r1kbmjmc.fsf@netris.org> Date: Sat, 20 Mar 2021 04:07:08 -0400 Message-ID: <87h7l6l03c.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "47253@debbugs.gnu.org" <47253@debbugs.gnu.org> Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1616227758; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post; bh=NE9aW+sLSGu4qTJupqC9xfBKWit9+EZ7a2MuNrqwJNk=; b=J2HFKGNDz5Y0CZQZ/0viXLDQsp4bcNUqYKqB1ddXQEWYGIY4d84KzbTSTuanz1wADMy4F5 HJ2LHXutL6SOMyKk/y0NFUUFz32Pb26WXO5cmH2DCHE3vK0Qsf7bKMu7dhX+lXsams5Xgw kb42qTxo3nuiWH6s7dI2KohXe06y3y1IOlNAhrt16G6WJbMwgc7wBm93BAz4D9croQj3fl ahU5u9VdmpO+iMJ59Z+w21wFxCpT6XHoJb6Z9nvsJK4C+IqAyMUiuuKgxmZjGFMBXPduhE N+U6/F8ZT/tloUwPrQK56nrem+9COjl3MZxA1uOAoa6lEG1c660wJux1zJ7wwg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1616227758; a=rsa-sha256; cv=none; b=h8WxI1xoSoO8BlHt6HmHflyXmNc+R5tBFQ1aB+77ftex9maoMKhmPJvRU2sUdpmKAzUR+m Q1StY4t4RLtNzOi4lXaFsbPBHyliiTTldeqtbUXpzEtDSnnohEYT5+LlGwH7szicEofgA3 1uyH4UDsmO0yKTH+oLpFAhgnSxDcY5vOX7ytLKZ5xnL250nJMxnCXS1KuvMryut6R6iNyH C0+P8JNlRTrOVvgpsosXkMKNpwCB7jQ+UdrN9LOnn4WG548OABE9/PnG9U1pforrLm1A06 /NE0CnA3w/hORJ0JsoyDT7o9leP/oK7j1PEYPfKCSGFnJIubJhAE+0+xx+3VYA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -2.41 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 13E5F161C8 X-Spam-Score: -2.41 X-Migadu-Scanner: scn0.migadu.com X-TUID: IkA61+9PhVuu Hi, Earlier, I wrote: >> How about leaving "networking" as it is now, and instead adding a new >> service called "network-online" or similar, that requires "networking" >> and then waits until a network connection is established? I withdraw my proposal for a separate "network-online" service. It was a half-baked idea made in haste. Now that I've looked, I see that almost every service in Guix that requires 'networking' should arguably[*] wait until the network comes up before starting up. Moreover, now that I think about it, I'm not sure what the use case would be for requiring 'networking', if not to wait for the network to come up. My immediate concern here is to avoid blocking the startup of a typical Guix desktop or laptop system for 30 seconds if there's no network connection, and more generally to keep Guix working well for users like myself who are not "always online". I haven't yet looked into the details, but at first glance, I'm inclined to agree with you that the right place to fix this is in Shepherd. Somehow, it ought to be possible to delay the startup of services that require 'networking', without delaying anything else. Mark [*] I'll note, however, that merely waiting up to 30 seconds (or whatever timeout you choose) is not, in itself, a robust solution. What happens if the network is down for more than 30 seconds? What if it goes down after 'nm-online' checks, but before the dependent service has finished starting? Also, if a service fails to handle lack of network when it starts, it makes me wonder whether it properly handles a prolonged network failure while its running. It seems to me that the only fully satisfactory solution is for each service to robustly handle network failures at any time, although I acknowledge that workarounds are needed in the meantime.