Too many services depend on ‘networking’

  • Open
  • quality assurance status badge
Details
2 participants
  • Efraim Flashner
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 2 Oct 2023 14:24
(address . bug-guix@gnu.org)
87cyxxjjou.fsf@inria.fr
I believe too many services depend on ‘networking’ for no good reason.
There’s a good discussion of the problem at:


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’.

Toggle snippet (5 lines)
$ 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

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’.
E
E
Efraim Flashner wrote on 5 Oct 2023 09:12
Re: bug#66306: Too many services depend on ‘networking’
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 66306@debbugs.gnu.org)
ZR5h58e0Hx2Jh-Tj@3900XT
On Mon, Oct 02, 2023 at 02:24:49PM +0200, Ludovic Courtès wrote:
Toggle quote (5 lines)
> 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?

Toggle quote (19 lines)
> 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@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
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmUeYeQACgkQQarn3Mo9
g1HYtA/+Lz0JDe8QYSmujf2y+m0lioue+czXOlm1Xt4mTIwD1eAI4JxzB6SkUOKr
1tiCBv48mYEev+0BXUoGnT2letDA44FGKjqSFDGWgYhoKSG0rgmZarD/zx3rExbH
+Es++Fh0wgPV147oJHH9bGu3uqMN6zwTJu/5YuDoXU5TQwVLyimGP1YTLUsh93KW
CRqW40U5bo8fezMT7jl47PmQlCSrip9UWH6si5Xblsra6Bl1s2917z6pTlbPRXIV
eLNVsh7fAfKoGHNSbjI9yzkA4BAyVHgyUJQx1hJplmdCw/tN2P8kc2DUGllObZ4b
IP/5K4cDE4uPT9ayfNZkNZlOozDIEnXbPE4lXtQO8GB3QqLUqKsnq59xLvldl6w4
+zr+nJdSAK2JDzqmgE8/KmufCX04UGozd4+FGPZWD7ZWvqQhJpLfV8H+HuiOlfmb
j5uFziNjXYKvAv2lxsc7PqqNfECkvGuIuQ61xvHUqKGT8XjcoOOaR1JyCvQUbgNO
snIiv87XSkKfvQgLQ49ojsD0jpz0vtCqJu0D1ptyBboDxTgXsfbauGeDDTfvScAw
cjg8qe3sZzxDLUliYlB61UjtXlNkg0Gd8nQzFvjJpNmHoJSIZ/z/BqbmKvcC+ilf
be/YYXmrq5PgXxDsF9gdnAbeE/8Yl19KpamAp//TZDZTETX0iv0=
=QpE3
-----END PGP SIGNATURE-----


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 66306@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 66306
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch