Aw: Re: Re: Include `::1 localhost` in /etc/hosts

2022-04-30 Thread Trey Sis
How would we move forward on changing this?

 

Cheers,

Trey


 

Gesendet: Donnerstag, 21. April 2022 um 12:01 Uhr
Von: "Trey Sis" 
An: ubuntu-devel-discuss@lists.ubuntu.com
Betreff: Re: Re: Include `::1 localhost` in /etc/hosts

Mostly it is a consistency issue. It seems like all major OS use the convention to have "localhost" resolve to "::1" as well as "127.0.0.1". Even Ubuntu's base Debian uses this convention. Also Arch, Gentoo, OpenWrt, macOS, and Windows.
 
This way, it is causing issues if people use software on Ubuntu that was crafted for not-Ubuntu, and vice versa. It will also cause masking problems. And thus, it complicates the move towards IPv6. I do understand it might also break some stuff in some cases, but we also can't keep everything forever, especially if the rest of the world has already decided which way to go.
 
Specific problems most prominently arose probably when NodeJS started to stop reordering DNS replies with preference for IPv4 and now let the OS decide again over DNS sorting order (according to address source and destination selection). This was especially visible when running the automated tests. Wild usage of "localhost" and "127.0.0.1" just decided by gut feeling made this change an uncessarily big effort.
 
I do agree though that introducing such a change in 22.10 is probably the better option and a good way to iron out issues until making it into the next LTS release.
 
Looking forward to your comments.
 
Cheers,
Trey

 

Gesendet: Donnerstag, 21. April 2022 um 05:14 Uhr
Von: "Richard Laager" 
An: ubuntu-devel-discuss@lists.ubuntu.com
Betreff: Re: Include `::1 localhost` in /etc/hosts
On 4/20/22 15:48, Treysis wrote:
> Not having localhost to resolve to ::1 is getting problematic.

Why? Can you elaborate on the issue(s) you're seeing?

I've always assumed the trade-off is as follows:

A) localhost resolves to ::1 (with or without 127.0.0.1 too)
Pro: Things can use IPv6 instead of IPv4 locally.
Pro: It becomes easier to have IPv6-only systems.
Con: If a daemon doesn't listen on ::1, but does on 127.0.0.1,
this change potentially breaks it. If the client(s) use
IPv4 only, then as long as localhost points to both, it
won't break. But if the client prefers IPv6, then it will
break. If the client uses Happy Eyeballs, it will work,
probably with slightly increased initial latency.

B) localhost resolves to only 127.0.0.1
Pro: Daemons that listen only on 127.0.0.1 (because they're old)
or only do so by default (because their default config is old
or the user's config is old) still work.
Con: IPv6 doesn't get exercised as much.
Con: It's harder to have an IPv6-only system.

All that said, at work, my systems have an /etc/hosts that is templated
from Ansible, and my template for Debian and Ubuntu is based on Debian
which points localhost to both 127.0.0.1 and ::1. I've not had any
problems with that.

It's way too late to change this for 22.04, but changing it for 22.10
might be ideal. That would give the maximal time to shake out bugs
before the next LTS.

--
Richard

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss




-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: I disabled lto, but it comes back in via -config --libs

2022-04-30 Thread Andreas Hasenack
Hi,


On Fri, Apr 29, 2022 at 10:50 PM Steve Langasek
 wrote:

> I think your main question has been addressed.  But I want to ask, why is it a
> problem to have part of this code with LTO enabled?  Generally we disable
> LTO only when it is causing build failures.  Was that the case here?

I don't think it's related to *part* of the build using LTO, and the
rest not. That was just an observation I made when I saw that
krb5-config --libs was also exporting lto flags, and I filed [4] for
it.

What prompted disabling lto is that mariadb was crashing[1] when it
couldn't initialize the io_uring queue due to a low RLIMIT_MEMLOCK
value we have by default. That baffled upstream, as the code should be
treating that exception[5], but instead we get an abort. They
investigated[2]  and suspected lto was to blame. I tried a build
without lto, and it worked.

Two things out of this, at least:
- why wasn't the exception caught when lto was enabled? gcc bug,
mariadb bug, or something else?
- should we bump our RLIMIT_MEMLOCK value from 64kbytes to something
higher? There is an upstream commit[3] in systemd to bump it to 8Mb. I
added a systemd task to the bug[1] about this

1. https://launchpad.net/bugs/1970634
2. https://jira.mariadb.org/browse/MDEV-25633
3. https://github.com/systemd/systemd/commit/852b62507b2
4. https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1970979
5. 
https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/comments/7

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel