GNU bug report logs - #66306
Too many services depend on ‘networking’

Previous Next

Package: guix;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Mon, 2 Oct 2023 12:26:02 UTC

Severity: normal

To reply to this bug, email your comments to 66306 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#66306; Package guix. (Mon, 02 Oct 2023 12:26:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ludovic Courtès <ludo <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Mon, 02 Oct 2023 12:26:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: Too many services depend on ‘networking’
Date: Mon, 02 Oct 2023 14:24:49 +0200
I believe too many services depend on ‘networking’ for no good reason.
There’s a good discussion of the problem at:

  https://systemd.io/NETWORK_ONLINE/

For example, bitlbee, ntpd, hurd-vm, and avahi-daemon all depend on
‘networking’.

Is it always justified?  For example, avahi-daemon unconditionally
listens on 0.0.0.0 and [::], so there’s no need to depend on
‘networking’.

--8<---------------cut here---------------start------------->8---
$ sudo netstat -tupla |grep avahi
udp        0      0 0.0.0.0:mdns            0.0.0.0:*                           650/avahi-daemon: r 
udp6       0      0 [::]:mdns               [::]:*                              650/avahi-daemon: r 
--8<---------------cut here---------------end--------------->8---

In other cases, such as bitlbee, it’s not as obvious because users can
specify different addresses to listen to, and those might depend on
‘networking’ to set up the corresponding interfaces.

Thoughts?  Should we do an audit of these?

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#66306; Package guix. (Thu, 05 Oct 2023 07:14:02 GMT) Full text and rfc822 format available.

Message #8 received at 66306 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 66306 <at> debbugs.gnu.org
Subject: Re: bug#66306: Too many services depend on ‘networking’
Date: Thu, 5 Oct 2023 10:12:39 +0300
[Message part 1 (text/plain, inline)]
On Mon, Oct 02, 2023 at 02:24:49PM +0200, Ludovic Courtès wrote:
> I believe too many services depend on ‘networking’ for no good reason.
> There’s a good discussion of the problem at:
> 
>   https://systemd.io/NETWORK_ONLINE/

This exactly! How much 'network' counts as 'good enough' to start the
next services?

> For example, bitlbee, ntpd, hurd-vm, and avahi-daemon all depend on
> ‘networking’.
> 
> Is it always justified?  For example, avahi-daemon unconditionally
> listens on 0.0.0.0 and [::], so there’s no need to depend on
> ‘networking’.
> 
> --8<---------------cut here---------------start------------->8---
> $ sudo netstat -tupla |grep avahi
> udp        0      0 0.0.0.0:mdns            0.0.0.0:*                           650/avahi-daemon: r 
> udp6       0      0 [::]:mdns               [::]:*                              650/avahi-daemon: r 
> --8<---------------cut here---------------end--------------->8---
> 
> In other cases, such as bitlbee, it’s not as obvious because users can
> specify different addresses to listen to, and those might depend on
> ‘networking’ to set up the corresponding interfaces.
> 
> Thoughts?  Should we do an audit of these?

Probably should do an audit. For bitlbee, I guess the question is how
does it respond to changes in networking? If it comes up when only
loopback is up will it need to be restarted once an actual network shows
up?

For ntpd, I've had trouble with openntpd coming up while only loopback
was active and then I'd have to restart it for it to get the initial big
jump when starting.


-- 
Efraim Flashner   <efraim <at> flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 212 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.