From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:c151::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id CckoJnHNVGDTRAAA0tVLHw (envelope-from ) for ; Fri, 19 Mar 2021 16:12:33 +0000 Received: from aspmx2.migadu.com ([2001:41d0:2:c151::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id QBdfIXHNVGBrBAAAbx9fmQ (envelope-from ) for ; Fri, 19 Mar 2021 16:12:33 +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 aspmx2.migadu.com (Postfix) with ESMTPS id AF4D51D3A6 for ; Fri, 19 Mar 2021 17:12:32 +0100 (CET) Received: from localhost ([::1]:43178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNHji-0002aZ-7r for larch@yhetil.org; Fri, 19 Mar 2021 12:12:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45136) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNHbW-0005Fk-SE for bug-guix@gnu.org; Fri, 19 Mar 2021 12:04:06 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:39302) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lNHbV-0004tO-S4 for bug-guix@gnu.org; Fri, 19 Mar 2021 12:04:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lNHbV-0005u3-Lj for bug-guix@gnu.org; Fri, 19 Mar 2021 12:04:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47253: network-manager shepherd services does not wait to be online Resent-From: raid5atemyhomework Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 19 Mar 2021 16:04: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: Mark H Weaver Cc: "47253@debbugs.gnu.org" <47253@debbugs.gnu.org> Received: via spool by 47253-submit@debbugs.gnu.org id=B47253.161616983322676 (code B ref 47253); Fri, 19 Mar 2021 16:04:01 +0000 Received: (at 47253) by debbugs.gnu.org; 19 Mar 2021 16:03:53 +0000 Received: from localhost ([127.0.0.1]:50848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNHbN-0005tg-Cs for submit@debbugs.gnu.org; Fri, 19 Mar 2021 12:03:53 -0400 Received: from mail-40138.protonmail.ch ([185.70.40.138]:38461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNHbH-0005tO-TI for 47253@debbugs.gnu.org; Fri, 19 Mar 2021 12:03:52 -0400 Date: Fri, 19 Mar 2021 16:03:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1616169821; bh=+aih+7TFWBoI3jzgiWDrh9G+fPdTjoTg9GZwlzSUXNo=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=rWOLYcnSx25Sb8u0XN7f79Oc1pl7rcrLl8ikDcMTCtMmcSiyqLHL/A/LYYShWgWvB blQdnZUuTppgU3vp8p1NRBJ1A7YFMF31utk3GUulQkJS1wVsqvI7xEIt4IhkG0pNFL bWbRdap7hDEHTz9raoCGPQh/4GMJeejKYtGGpox8= Message-ID: In-Reply-To: <87r1kbmjmc.fsf@netris.org> References: <87r1kbmjmc.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" Reply-to: raid5atemyhomework X-ACL-Warn: , raid5atemyhomework From: raid5atemyhomework via Bug reports for GNU Guix X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1616170353; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: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:dkim-signature; bh=+aih+7TFWBoI3jzgiWDrh9G+fPdTjoTg9GZwlzSUXNo=; b=kUGJwC8Q2DkRQsVmeiIFe++SDgW+C+utQH3+0Pc3mDYtT+u5TKla2k6bRgz6eEGNZFbpno Qh5EJawcXgwx+TYZeOdpU9lBBVY2P8dn+qgE9ZvMDNhmuUNu4z+IBLHkYGkv9jNHAJYtQq wmZa41CCDfspkizb/lyHC8dp7g4enNYlZOwToW4XqnKIfIXEvdfJJiEdYUg6OOik1crIqa 8Ws6PJIWmfB2UULzUcas3IwUx1lc8BQb2bfTHwGaIv3JubU2wcX0tl2VGpjZUr1CakyXu4 mhP7G0AmvEopAAKQKQnTSTQVqj0XZ6GdvDRWBIAxrMXDbz4RlyqRUfagQDuCOA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1616170353; a=rsa-sha256; cv=none; b=U3f4zk5nLWr6j8De6Ahq+zs22tLhPeAmxGjAsvwbgkme7IBDrt4irx1QJ7R2unK3sjkk6J epCktnVP59c/9cz+8Qb5qKhrOmh/KvOqO+BE6Dernqno7bDDSQOZbaoiWwX3lawmiKoupe 7juWSIUrv4U+y2LbVhVGGWPWoJfDBz0uXuo12Ei14f85ka8dJv5soAJmdRJH0EfNs7m9bn BG8PgxPZ34lxh8n95XoKqQdHlOnYnq2VEcoUvknDpTKLT1vpWaAHHqi4bP9wRqrsEFKwQn vJ5ayfT+4zB4Bi1VLb4K5DTPq9nujzx6GZXCURy7VKmTvCje21G0Ew+HpF6lFA== ARC-Authentication-Results: i=1; aspmx2.migadu.com; dkim=fail ("headers rsa verify failed") header.d=protonmail.com header.s=protonmail header.b=rWOLYcnS; spf=pass (aspmx2.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.91 Authentication-Results: aspmx2.migadu.com; dkim=fail ("headers rsa verify failed") header.d=protonmail.com header.s=protonmail header.b=rWOLYcnS; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx2.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: AF4D51D3A6 X-Spam-Score: -2.91 X-Migadu-Scanner: scn0.migadu.com X-TUID: BQ4Qv/3jewUW Hello Mark, > > Of course, the big problem is that Shepherd is single-threadded and > > `nm-online` will block all other bootup. > > That's not good. For the sake of users who are not always connected to > the internet, I'd strongly prefer for the Guix boot process of a desktop > system to not be blocked for 30 seconds when there's no active > internet connection. > > 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? > > What do you think? Ideally the `init` system should be multithreaded, such that anything that = isn't dependent on `networking` does not get delayed but gets started as so= on as its dependencies complete. In particular, `transmission-daemon-service-type` creates a Shepherd servic= e that is dependent on `networking`, but is in fact the second daemon I men= tioned, which fails to properly bind to the command 9091 port, requiring th= e daemon to be restarted each time. So if we use a separate `network-onlin= e` shepherd provision, `transmission-daemon-service-type` also needs to be = modified (on my system I have a separate provision similar to your `network= -online` idea and I wrote my own shepherd service for `transmission-daemon`= just to add this requirement). With a separate `network-online` shepherd provision we would also need to a= udit all the other network-requiring daemons to see if similar problems exi= st. As well, `networking` is provided by multiple possible services, so if we a= dd a separate `network-online` we also need to modify the other options. * `network-manager-service-type`. * `dhcp-client-service-type`. * `wicd-service-type`. * `connman-service-type`. For that matter, we probably need to review the above other options, as the= y might just start up the networking service without actually ensuring that= the networking service has actually completed. I use `network-manager-ser= vice-type` as part of `%desktop-services` but if this issue isn't properly = handled by Guix for NetworkManager then it probably isn't properly handled = for the above other options --- in all likelihood the network interfaces ar= e not available just after the networking shepherd services are started. In addition --- do we always have a `network-online` shepherd service, or n= ot? * Each of the `network-manager-service-type`, `dhcp-client-service-type`, `= wicd-service-type`, `connman-service-type` instantiate both a `networking` = and `network-online` shepherd provision. * Then other network-requiring services can always assume that `network-o= nline` exists. * However, not-always-online users would always find that `shepherd` comp= letion is delayed. * This manifests as `herd` commands not responding until the wait-to-be= -online timeout ends. * We have separate `network-manager-online-service-type`, `dhcp-client-onli= ne-service-type`, `wicd-online-service-type`, and `connman-online-service-t= ype` that provides the `network-online` shepherd provision to the correspon= ding `networking` backend. * Thus, not-always-online users would omit the `*-online-*` service type = in order not to suffer the wait. * However, the user has to know to add the *corresponding* service type a= s well if they have to use a daemon like `transmission-daemon`. * Do we add `network-manager-online-service-type` to `%desktop-services`? * I think we should, as most `%desktop-services`-using users will be mo= stly online anyway, and they are the ones most likely to want to start othe= r network-using services as well. * We somehow implement polymorphic service types so that services like `tra= nsmission-daemon` have a `(service-extension i-need-network-online-service-= type (const #f))`, which only instantiates `network-online` provision, appr= opriately for the network backend, if at least one service requires it. * Probably a lot more code and design and nerd wars about the best possib= le design and delays and ... What do *you* think? Note as well that in the SystemD case, typically, `NetworkManager-wait-onli= ne.service` is always enabled, and when I boot up my system on SystemD-base= d OSs even without any network available I don't experience any network-goi= ng-up delays during boot (at least in the last few years, I do remember cir= ca oughts Ubuntu having that problem). In addition, `nm-online -s` has this: > -s | --wait-for-startup > Wait for NetworkManager startup to complete, rather than waitin= g for network connectivity specifically. Startup is considered complete onc= e NetworkManager has activated (or > attempted to activate) every auto-activate connection which is = available given the current network state. (This is generally only useful a= t boot time; after startup has > completed, nm-online -s will just return immediately, regardles= s of the current network state.) My interpretation of the above is that `-s` means that NetworkManager has *= tried* to activate, not necessarily that there is an actual network connect= ion, but I am not an expert on NetworkManager. Thanks raid5atemyhomework