From unknown Tue Aug 19 11:04:07 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#47253 <47253@debbugs.gnu.org> To: bug#47253 <47253@debbugs.gnu.org> Subject: Status: network-manager shepherd services does not wait to be online Reply-To: bug#47253 <47253@debbugs.gnu.org> Date: Tue, 19 Aug 2025 18:04:07 +0000 retitle 47253 network-manager shepherd services does not wait to be online reassign 47253 guix submitter 47253 raid5atemyhomework severity 47253 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 18 23:38:30 2021 Received: (at submit) by debbugs.gnu.org; 19 Mar 2021 03:38:30 +0000 Received: from localhost ([127.0.0.1]:48415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lN5y1-0006qf-Rj for submit@debbugs.gnu.org; Thu, 18 Mar 2021 23:38:30 -0400 Received: from lists.gnu.org ([209.51.188.17]:44454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lN5y0-0006qX-4N for submit@debbugs.gnu.org; Thu, 18 Mar 2021 23:38:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35560) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lN5xy-0001bc-6q for bug-guix@gnu.org; Thu, 18 Mar 2021 23:38:27 -0400 Received: from mail-40132.protonmail.ch ([185.70.40.132]:37989) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lN5xv-0007OT-Fd for bug-guix@gnu.org; Thu, 18 Mar 2021 23:38:25 -0400 Date: Fri, 19 Mar 2021 03:38:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1616125100; bh=bInF8QjigW6r/QI4gHGo0f2y6wdnWprDXgifF4EoGI4=; h=Date:To:From:Reply-To:Subject:From; b=N/ySH2IMsxynW5Xpp/5noQTpcRA5DJ0nST971AqmRBUZZnpmDfbGKmuuWilD3wYWU pF0zk6kAo2XPAvVaQctgdOiGKy/IyElZFvFbZyq5SpjgzLfYfFF0E25+yov6OUeQUT J3H144SjJDGMszIf+JY4fqRkwNf7hNfsMAMXVVOg= To: "bug-guix@gnu.org" From: raid5atemyhomework Subject: network-manager shepherd services does not wait to be online Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Received-SPF: pass client-ip=185.70.40.132; envelope-from=raid5atemyhomework@protonmail.com; helo=mail-40132.protonmail.ch X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: submit 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: , Reply-To: raid5atemyhomework Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) I have a small number of daemons that need access to the network at startup= . I have configured their Shepherd services to require `networking`. However, to my puzzlement, I consistently find that they are unable to acce= ss the network at startup. One daemon dies (and gets respawned so often th= at it sometimes gets disabled by Shepherd), the other daemon just keeps run= ning without having set up the server that I need it to expose. Thus, in many cases whenever I reboot I have to manually `herd enable` and = `herd restart` the first daemon and `herd restart` the second. This is fai= rly bad since I want to be able to leave this server alone and have it surv= ive power interruptions etc. Checking on other systems, I stumbled on this file on SystemD-based systems= : ```systemd [Unit] Description=3DNetwork Manager Wait Online Documentation=3Dman:nm-online(1) Requires=3DNetworkManager.service After=3DNetworkManager.service Before=3Dnetwork-online.target [Service] Type=3Doneshot ExecStart=3D/usr/bin/nm-online -s -q --timeout=3D30 RemainAfterExit=3Dyes [Install] WantedBy=3Dnetwork-online.target ``` Searching the Guix source code, I can't find any `nm-online` command. So I= think that, when using the `network-manager` service type, the `networking= ` provision is considered started even though networking isn't actually onl= ine yet. I would like to propose this change: ```diff --- a/gnu/services/networking.scm +++ b/gnu/services/networking.scm @@ -1106,17 +1106,22 @@ and @command{wicd-curses} user interfaces." (documentation "Run the NetworkManager.") (provision '(networking)) (requirement '(user-processes dbus-system wpa-supplicant loo= pback)) - (start #~(make-forkexec-constructor - (list (string-append #$network-manager - "/sbin/NetworkManager") - (string-append "--config=3D" #$conf) - "--no-daemon") - #:environment-variables - (list (string-append "NM_VPN_PLUGIN_DIR=3D" #$vpn - "/lib/NetworkManager/VPN") - ;; Override non-existent default users - "NM_OPENVPN_USER=3D" - "NM_OPENVPN_GROUP=3D"))) + (start #~(let ((constructor (make-forkexec-constructor + (list (string-append #$netwo= rk-manager + "/sbin/= NetworkManager") + (string-append "--conf= ig=3D" #$conf) + "--no-daemon") + #:environment-variables + (list (string-append "NM_VPN= _PLUGIN_DIR=3D" #$vpn + "/lib/N= etworkManager/VPN") + ;; Override non-existe= nt default users + "NM_OPENVPN_USER=3D" + "NM_OPENVPN_GROUP=3D")= ))) + (lambda args + (let ((pid (apply constructor args))) + (invoke/quiet (string-append #$network-manage= r "/bin/nm-online") + "-s" "-q" "--timeout=3D30") + pid)))) (stop #~(make-kill-destructor)))))))) (define network-manager-service-type ``` Of course, the big problem is that Shepherd is single-threadded and `nm-onl= ine` will block all other bootup. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 19 08:09:28 2021 Received: (at 47253) by debbugs.gnu.org; 19 Mar 2021 12:09:28 +0000 Received: from localhost ([127.0.0.1]:48987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNDwW-0005TA-Dm for submit@debbugs.gnu.org; Fri, 19 Mar 2021 08:09:28 -0400 Received: from world.peace.net ([64.112.178.59]:57732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNDwT-0005St-RC for 47253@debbugs.gnu.org; Fri, 19 Mar 2021 08:09:27 -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 1lNDwM-0003KU-0H; Fri, 19 Mar 2021 08:09:18 -0400 From: Mark H Weaver To: raid5atemyhomework , 47253@debbugs.gnu.org Subject: Re: bug#47253: network-manager shepherd services does not wait to be online In-Reply-To: References: Date: Fri, 19 Mar 2021 08:07:44 -0400 Message-ID: <87r1kbmjmc.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47253 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, raid5atemyhomework via Bug reports for GNU Guix writes: > I have a small number of daemons that need access to the network at > startup. I have configured their Shepherd services to require > `networking`. > > However, to my puzzlement, I consistently find that they are unable to > access the network at startup. One daemon dies (and gets respawned so > often that it sometimes gets disabled by Shepherd), the other daemon > just keeps running without having set up the server that I need it to > expose. > > Thus, in many cases whenever I reboot I have to manually `herd enable` > and `herd restart` the first daemon and `herd restart` the second. > This is fairly bad since I want to be able to leave this server alone > and have it survive power interruptions etc. [...] > I would like to propose this change: > > ```diff > --- a/gnu/services/networking.scm > +++ b/gnu/services/networking.scm > @@ -1106,17 +1106,22 @@ and @command{wicd-curses} user interfaces." > (documentation "Run the NetworkManager.") > (provision '(networking)) > (requirement '(user-processes dbus-system wpa-supplicant loopback)) > - (start #~(make-forkexec-constructor > - (list (string-append #$network-manager > - "/sbin/NetworkManager") > - (string-append "--config=" #$conf) > - "--no-daemon") > - #:environment-variables > - (list (string-append "NM_VPN_PLUGIN_DIR=" #$vpn > - "/lib/NetworkManager/VPN") > - ;; Override non-existent default users > - "NM_OPENVPN_USER=" > - "NM_OPENVPN_GROUP="))) > + (start #~(let ((constructor (make-forkexec-constructor > + (list (string-append #$network-manager > + "/sbin/NetworkManager") > + (string-append "--config=" #$conf) > + "--no-daemon") > + #:environment-variables > + (list (string-append "NM_VPN_PLUGIN_DIR=" #$vpn > + "/lib/NetworkManager/VPN") > + ;; Override non-existent default users > + "NM_OPENVPN_USER=" > + "NM_OPENVPN_GROUP=")))) > + (lambda args > + (let ((pid (apply constructor args))) > + (invoke/quiet (string-append #$network-manager "/bin/nm-online") > + "-s" "-q" "--timeout=30") > + pid)))) > (stop #~(make-kill-destructor)))))))) > > (define network-manager-service-type > ``` > > > 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? Mark From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 19 12:03:53 2021 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= To: Mark H Weaver From: raid5atemyhomework Subject: Re: bug#47253: network-manager shepherd services does not wait to be online 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-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47253 Cc: "47253@debbugs.gnu.org" <47253@debbugs.gnu.org> 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: , Reply-To: raid5atemyhomework Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 20 04:08:55 2021 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 To: raid5atemyhomework Subject: Re: bug#47253: network-manager shepherd services does not wait to be online 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-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47253 Cc: "47253@debbugs.gnu.org" <47253@debbugs.gnu.org> 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, 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 20 06:15:46 2021 Received: (at 47253) by debbugs.gnu.org; 20 Mar 2021 10:15:46 +0000 Received: from localhost ([127.0.0.1]:51559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNYe1-0005ZT-Tf for submit@debbugs.gnu.org; Sat, 20 Mar 2021 06:15:46 -0400 Received: from mail-40132.protonmail.ch ([185.70.40.132]:29408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lNYdx-0005ZA-HY for 47253@debbugs.gnu.org; Sat, 20 Mar 2021 06:15:44 -0400 Date: Sat, 20 Mar 2021 10:15:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1616235334; bh=IPVdyXvStwEprm6ON3QdN8WiursFHENEbiUuPD5m35k=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=S090d8hf9EBQcw1pSpZgBe+IZkNdPe+zT/ANsvVoesFvkWABKUFJCxQ+Ag9bbj/A1 rvqaE9V7ERUxmIpXHfkU4xO6zVC28o47t93TyCvnWB7naPnPFLpDguXSpLYn9Qwo7H Qe6zQM2+CfX/3ykkpntCUKi4aWX2bQhnN4IGpo48= To: Mark H Weaver From: raid5atemyhomework Subject: Re: bug#47253: network-manager shepherd services does not wait to be online Message-ID: In-Reply-To: <87h7l6l03c.fsf@netris.org> References: <87r1kbmjmc.fsf@netris.org> <87h7l6l03c.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47253 Cc: "47253@debbugs.gnu.org" <47253@debbugs.gnu.org> 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: , Reply-To: raid5atemyhomework Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hello MArk, > [] I'll note, however, that merely waiting up to 30 seconds (orwhatever t= imeout 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? The sysad has to go look at what is wrong and fix it, then restart services= manually as needed. Presumably the sysad is competent enough to care for = the hardware so this doesn't occur (too often). What this avoids is if everything in the hardware setup (cables, NIC, route= r, hub, router config, etc.) is 100% fine but a reboot of the system for an= y reason causes services starting at boot to fail to start properly. Compe= tent sysads will put alarm bells if an important daemon is not running. Bu= t if such alarm bells keep getting set off during a server restart, it gets= annoying and makes the sysad pay less attention to alarm bells that *are* = important enough for them to check the hardware setup. So the common 30-second timeout used in SystemD is a fairly good compromise= anyway. Probably your alarm bells checks things hourly or so, and exiting= after 30 seconds allows other services (e.g. a direct X server on the serv= er, perhaps?) to start as well so a sysad can sit at the console and work t= he issue directly. It's not perfect, but it's good enough for most things. > 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. Indeed, and the Guix substituter for example is fairly brittle against inte= rnet connectivity problems, not just at the local networking level, but fro= m issues from the local network connection all the way to ci.guix.gnu.org. Thanks raid5atemyhomework From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 23 11:27:13 2021 Received: (at 47253) by debbugs.gnu.org; 23 Jul 2021 15:27:13 +0000 Received: from localhost ([127.0.0.1]:44328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6x4z-0004H5-NV for submit@debbugs.gnu.org; Fri, 23 Jul 2021 11:27:13 -0400 Received: from mail-40140.protonmail.ch ([185.70.40.140]:44817) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6x4x-0004Gr-F0 for 47253@debbugs.gnu.org; Fri, 23 Jul 2021 11:27:12 -0400 Date: Fri, 23 Jul 2021 15:27:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1627054025; bh=akx1pgLLjUEt9koVIZ/vTSPkw71vih2dXgb6S23ku0c=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=Zi1WEQ4QGBE4bIs1e/ie5SrHsGE0F576L7b9g0uFZvYu6ZscoK9pfyfO6srH6NMxV +4AA0LFyqHNY0QIKyvNwBDwDfjHTQ9HpKQg57rh8g7h/xVWzYPpaNESJ1qkQAMnBZc IhuiUV4g1S9+Rapxo0JwQMA1c2OV8XuAWxKLhu/o= To: "47253@debbugs.gnu.org" <47253@debbugs.gnu.org> From: raid5atemyhomework Subject: Re: bug#47253: network-manager shepherd services does not wait to be online Message-ID: <-7ecsGr8nG6wxU0N5Mlc6p9uS8imKF8ikIq3HQvrP9IUYDMggsFlAO9ZZuPwSVU5MVsefN4wFhw4nV47gjKzpE2bK6STGo_biKT22KUoXfw=@protonmail.com> In-Reply-To: References: <87r1kbmjmc.fsf@netris.org> <87h7l6l03c.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47253 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: , Reply-To: raid5atemyhomework Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Is there any chance any thought will be given over to this, or am I stuck t= rying to work around a single-threaded "does the job, but not well" Shepher= d? I'm beginning to wonder if just using SystemD would work better, especially= since it's so popular nearly every daemon package includes support for it = anyway. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 24 08:00:33 2021 Received: (at submit) by debbugs.gnu.org; 24 Jul 2021 12:00:33 +0000 Received: from localhost ([127.0.0.1]:45327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m7GKW-0005Of-Nv for submit@debbugs.gnu.org; Sat, 24 Jul 2021 08:00:33 -0400 Received: from lists.gnu.org ([209.51.188.17]:55802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m7GKU-0005OW-9F for submit@debbugs.gnu.org; Sat, 24 Jul 2021 08:00:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7GKT-0005RN-W4 for bug-guix@gnu.org; Sat, 24 Jul 2021 08:00:30 -0400 Received: from knopi.disroot.org ([178.21.23.139]:48168) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7GKR-0007Y6-0O for bug-guix@gnu.org; Sat, 24 Jul 2021 08:00:29 -0400 Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 6D7224C13; Sat, 24 Jul 2021 14:00:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with UTF8SMTP id f5oAGeObqdps; Sat, 24 Jul 2021 14:00:22 +0200 (CEST) References: <87r1kbmjmc.fsf@netris.org> <87h7l6l03c.fsf@netris.org> <-7ecsGr8nG6wxU0N5Mlc6p9uS8imKF8ikIq3HQvrP9IUYDMggsFlAO9ZZuPwSVU5MVsefN4wFhw4nV47gjKzpE2bK6STGo_biKT22KUoXfw=@protonmail.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1627128021; bh=xjK3uwkv3E+uchvkyzSUTBx4gSfbp1oAlZlzP5Oi4no=; h=References:From:To:Cc:Subject:In-reply-to:Date; b=gA7+9ZzlwvwZd5b8tbEGBPqVLdXoNFK5ZRXRabafZOSn1jMaQr9zL31v9oAsJzi1c xGbccRAuLBjMqveXwiR1FP1B6Uqm6DRztP3rGOXiU+bPVN5iZByPFymXYamLiaiakM 9gtu1F3NWBTCi8p6KQ5h7Cjnd2EP3ncLE7OlUTJYTYnMwG09GRpHch/2aup54Hd2ri nI1lhABpVRT37gEuLpJqscwml1l2kp/OO+FnHj895X11zrjcD7m38NWuKP4lofu4o+ /PYZP4MyNxIjOR8AAiuRHxwobiTDbso8Etz6SvFuRD5G4GSy/au4AY9k/JKHc6KQ5W p1kDzxdojcT3A== From: Bone Baboon To: raid5atemyhomework Subject: Re: bug#47253: network-manager shepherd services does not wait to be online In-reply-to: <-7ecsGr8nG6wxU0N5Mlc6p9uS8imKF8ikIq3HQvrP9IUYDMggsFlAO9ZZuPwSVU5MVsefN4wFhw4nV47gjKzpE2bK6STGo_biKT22KUoXfw=@protonmail.com> Date: Sat, 24 Jul 2021 07:56:08 -0400 Message-ID: <877dhgsz6v.fsf@disroot.org> Mime-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=178.21.23.139; envelope-from=bone.baboon@disroot.org; helo=knopi.disroot.org 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: "47253@debbugs.gnu.org" <47253@debbugs.gnu.org>, bug-guix@gnu.org 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.4 (--) raid5atemyhomework via Bug reports for GNU Guix writes: > Is there any chance any thought will be given over to this, or am I stuck trying to work around a single-threaded "does the job, but not well" Shepherd? > > I'm beginning to wonder if just using SystemD would work better, especially since it's so popular nearly every daemon package includes support for it anyway. There appears to be previous email threads on the guix-devel mailing list that you may find interesting. Just search for systemd and there are several results. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 10 18:34:40 2023 Received: (at control) by debbugs.gnu.org; 10 Mar 2023 23:34:40 +0000 Received: from localhost ([127.0.0.1]:56133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pamG0-0005az-2y for submit@debbugs.gnu.org; Fri, 10 Mar 2023 18:34:40 -0500 Received: from smtpmciv4.myservices.hosting ([185.26.107.240]:44694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pamFy-0005an-Du for control@debbugs.gnu.org; Fri, 10 Mar 2023 18:34:38 -0500 Received: from mail1.netim.hosting (unknown [185.26.106.173]) by smtpmciv4.myservices.hosting (Postfix) with ESMTP id 100EE2076B for ; Sat, 11 Mar 2023 00:34:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id 87AA38009A for ; Sat, 11 Mar 2023 00:28:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail1.netim.hosting Received: from mail1.netim.hosting ([127.0.0.1]) by localhost (mail1-2.netim.hosting [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pgjjcpZ9KrjB for ; Sat, 11 Mar 2023 00:28:26 +0100 (CET) Received: from [192.168.1.239] (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id 42A0980098 for ; Sat, 11 Mar 2023 00:28:26 +0100 (CET) Message-ID: Date: Fri, 10 Mar 2023 23:28:25 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 X-Mozilla-News-Host: news://news.yhetil.org:119 Content-Language: en-US To: control From: Bruno Victal Subject: control-msg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 (-) close 47253 close 60300 quit --- Fixed with commit d04955972e42bd85ba6137625e09e9e31de52f72. From unknown Tue Aug 19 11:04:07 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 08 Apr 2023 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator