Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Gene Heskett]

On Monday 18 September 2017 12:39:12 Reco wrote:

>   Hi.
>
> On Mon, Sep 18, 2017 at 08:50:36AM +0200, deloptes wrote:
> > Gene Heskett wrote:
> > > 127.0.0.1 localhost.localdomain localhost
> >
> > Sorry but I did not understand if the problem is there or if the
> > problem is that it is not there?
>
> Long story short, OP has a misbehaving Debian stretch installation
> with the hostname (as in - /proc/sys/kernel/hostname) set to
> 'localhost.localdomain'.
> /etc/hosts lacks such entry.
> /etc/resolv.conf points to an absent DNS.
>
> The result is - every execution of sudo has an added 30-second
> execution time 'bonus'.
>
> > I guess this is put there at time of installation. I'll check few
> > virtual machines later to see how it was written.
>
> If the user chooses conventional hostname (even 'debian') during the
> installation - sure, they should put a record in /etc/hosts. Unsure
> about stretch, but they did so since etch.
>
> The question is - since 'localhost.localdomain' is special, what
> happens if such hostname is chosen during the installation?
>
> > IMO if you have working resolver it shouldn't matter much.
>
> Please read this thread's subject one more time. Last three words
> especially.
>
> Reco

The OP, if he has a router, should point resolv.conf  at it for the dns 
entry. The router will fwd the request to his ISP's dns servers. This 
will NOT resolve local names, so a hosts file with those translations is 
a good idea.

resolv.conf in that event, should have the nameservers address, and the 
search order "hosts dns", something like this:
nameserver 192.168.XX.1
search  hostdns
domain  coyote.den

where the XX is the block his local network is in in the 192.168.xx.nn 
space. And if network mangler is installed, it should be stopped.

In either event, as long as the machine stays where it is, I'd become 
root and issue:
chattr +i resolv.conf just so N-M can't tear up a perfectly functioning 
network connection.

But thats just me. I like things that Just Work(TM).

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Mon 18 Sep 2017 at 22:50:07 +0200, deloptes wrote:

> Brian wrote:
> 
> > True, we know the OP has a problem with with sudo. What we do not know
> > is the hostname he chose during the installation, although it looks like
> > it was "localhost"
> 
> He admitted he entered localhost when prompted at installation time.

Guilty, as charged, then. :) That's me. not reading carefully enough.

-- 
Brian.

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Mon 18 Sep 2017 at 23:47:18 +0300, Reco wrote:

> On Mon, Sep 18, 2017 at 07:48:53PM +0100, Brian wrote:
> > On Mon 18 Sep 2017 at 20:13:44 +0200, deloptes wrote:
> > 
> > > Reco wrote:
> > > 
> > > > The question is - since 'localhost.localdomain' is special, what happens
> > > > if such hostname is chosen during the installation?
> > > 
> > > well, now we all know what happens :)
> > 
> > True, we know the OP has a problem with with sudo.
> 
> That's what lie on surface. Any software that implements
> uname/gethostbyname sequence would exhibit similar behavior.
> 
> 
> > What we do not know
> > is the hostname he chose during the installation, although it looks like
> > it was "localhost" from the second line of
> > 
> >   127.0.0.1   localhost 
> > 
> >   127.0.1.1   localhost
> 
> I agree.
> 
> > The installer recommends a single word for the hostname. The "single"
> > aspect is the result of a number of years of experience and bug reports.
> 
> And let's not forget RFC 952 (obsoleted by RFC 1123), which states:
> 
> A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24
> characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),
> and period (.).  Note that periods are only allowed when they serve to
> delimit components of "domain style names".
> 
> RFC 1123 lifts some restrictions:
> 
> One aspect of host name syntax is hereby changed: the restriction on the
> first character is relaxed to allow either a letter or a digit.  Host
> software MUST support this more liberal syntax.
> 
> Host software MUST handle host names of up to 63 characters and SHOULD
> handle host names of up to 255 characters.
> 
> But does not says anything about dots, so restrictions of RFC 952 still
> apply.
> 
> > Although "localhost.localdomain" is not an invalid hostname
> 
> I agree as long as 'invalid' is defined as 'kernel does not accept it'.
> For instance, one can set nodename as 'localhost.local' and watch avahi
> explode. Or, say, '_localhost', if one intends to wreak havoc in local
> DNS's SRV records.
> The kernel is surprisingly liberal at these things.
> 
> > the OP does not appear to have used it. (We have not been given the
> > contents of his /etc/hostname explicitly).
> 
> True. We also did not see the contents of sysctl.conf (and those *other*
> files that can store kernel tunables), custom init.d scripts and custom
> systemd units if there were any.
> 
> To make things more confusing, 'localhost.localdomain' could be a
> 'transient' hostname, not a 'static' one (aka /etc/hostname).
> 
> It's one of those things I prefer to debug with auditd on. Too many
> possibilities otherwise.
> 
> > What was the problem with his resolv.conf? Have I missed that?
> 
> OP used an unspecified VPN client which put an additional entry into
> /etc/resolv.conf on start, but failed to clean it up on stop.

Much clearer now. Your attention to explaining in detail is appreciated.

-- 
Brian.

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Mon 18 Sep 2017 at 17:47:18 -0300, x9p wrote:

> > True, we know the OP has a problem with with sudo. What we do not know
> > is the hostname he chose during the installation, although it looks like
> > it was "localhost" from the second line of
> >
> >   127.0.0.1   localhost
> >   127.0.1.1   localhost
> 
> root@localhost:~# cat /etc/hostname
> localhost
> 
> > The installer recommends a single word for the hostname. The "single"
> > aspect is the result of a number of years of experience and bug reports.
> > Although "localhost.localdomain" is not an invalid hostname the OP does
> > not appear to have used it. (We have not been given the contents of his
> > /etc/hostname explicitly).
> 
> I agree choosing "localhost" is wrong per-RFC. But I have been doing it
> for years and stuff never broke. stretch+sudo 1.8.19p1-2.1 is a first. Bad
> luck of me.
> 
> > What was the problem with his resolv.conf? Have I missed that?
> 
> Hardcoded company nameserver in /etc/resolv.conf that only works when VPN
> is up. VPN was down and problem appeared.

Thank you for expanding on this. You did mention before the nameserver
you were using, but I missed the significance.

-- 
Brian.

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[deloptes]

Brian wrote:

> True, we know the OP has a problem with with sudo. What we do not know
> is the hostname he chose during the installation, although it looks like
> it was "localhost"

He admitted he entered localhost when prompted at installation time.

regards

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Reco]

Hi.

On Mon, Sep 18, 2017 at 07:48:53PM +0100, Brian wrote:
> On Mon 18 Sep 2017 at 20:13:44 +0200, deloptes wrote:
> 
> > Reco wrote:
> > 
> > > The question is - since 'localhost.localdomain' is special, what happens
> > > if such hostname is chosen during the installation?
> > 
> > well, now we all know what happens :)
> 
> True, we know the OP has a problem with with sudo.

That's what lie on surface. Any software that implements
uname/gethostbyname sequence would exhibit similar behavior.


> What we do not know
> is the hostname he chose during the installation, although it looks like
> it was "localhost" from the second line of
> 
>   127.0.0.1   localhost   
>   
>   127.0.1.1   localhost

I agree.


> The installer recommends a single word for the hostname. The "single"
> aspect is the result of a number of years of experience and bug reports.

And let's not forget RFC 952 (obsoleted by RFC 1123), which states:

A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24
characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),
and period (.).  Note that periods are only allowed when they serve to
delimit components of "domain style names".


RFC 1123 lifts some restrictions:

One aspect of host name syntax is hereby changed: the restriction on the
first character is relaxed to allow either a letter or a digit.  Host
software MUST support this more liberal syntax.

Host software MUST handle host names of up to 63 characters and SHOULD
handle host names of up to 255 characters.


But does not says anything about dots, so restrictions of RFC 952 still
apply.


> Although "localhost.localdomain" is not an invalid hostname

I agree as long as 'invalid' is defined as 'kernel does not accept it'.
For instance, one can set nodename as 'localhost.local' and watch avahi
explode. Or, say, '_localhost', if one intends to wreak havoc in local
DNS's SRV records.
The kernel is surprisingly liberal at these things.


> the OP does not appear to have used it. (We have not been given the
> contents of his /etc/hostname explicitly).

True. We also did not see the contents of sysctl.conf (and those *other*
files that can store kernel tunables), custom init.d scripts and custom
systemd units if there were any.

To make things more confusing, 'localhost.localdomain' could be a
'transient' hostname, not a 'static' one (aka /etc/hostname).

It's one of those things I prefer to debug with auditd on. Too many
possibilities otherwise.


> What was the problem with his resolv.conf? Have I missed that?

OP used an unspecified VPN client which put an additional entry into
/etc/resolv.conf on start, but failed to clean it up on stop.

Reco

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

> True, we know the OP has a problem with with sudo. What we do not know
> is the hostname he chose during the installation, although it looks like
> it was "localhost" from the second line of
>
>   127.0.0.1   localhost
>   127.0.1.1   localhost
>

root@localhost:~# cat /etc/hostname
localhost

> The installer recommends a single word for the hostname. The "single"
> aspect is the result of a number of years of experience and bug reports.
> Although "localhost.localdomain" is not an invalid hostname the OP does
> not appear to have used it. (We have not been given the contents of his
> /etc/hostname explicitly).
>

I agree choosing "localhost" is wrong per-RFC. But I have been doing it
for years and stuff never broke. stretch+sudo 1.8.19p1-2.1 is a first. Bad
luck of me.

> What was the problem with his resolv.conf? Have I missed that?
>

Hardcoded company nameserver in /etc/resolv.conf that only works when VPN
is up. VPN was down and problem appeared.

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Mon 18 Sep 2017 at 15:41:48 -0300, x9p wrote:

> 
> >>
> >> I believe topic is closed with this.
> >
> > For the benefit of other users: what does your /etc/hosts look like now?
> >
> > --
> > Brian.
> >
> >
> 
> root@localhost:~# cat /proc/sys/kernel/hostname
> localhost.localdomain
> root@localhost:~# grep localhost /etc/hosts
> 127.0.0.1   localhost localhost.localdomain
> 127.0.1.1   localhost
> ::1 localhost ip6-localhost ip6-loopback

It is difficult to argue against success in solving a problem but I
wouldn't have 127.0.1.1 as localhost. Does 'cat /etc/hostname' also
give "localhost"?

-- 
Brian.

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Mon 18 Sep 2017 at 20:13:44 +0200, deloptes wrote:

> Reco wrote:
> 
> > The question is - since 'localhost.localdomain' is special, what happens
> > if such hostname is chosen during the installation?
> 
> well, now we all know what happens :)

True, we know the OP has a problem with with sudo. What we do not know
is the hostname he chose during the installation, although it looks like
it was "localhost" from the second line of

  127.0.0.1   localhost 

  127.0.1.1   localhost

The installer recommends a single word for the hostname. The "single"
aspect is the result of a number of years of experience and bug reports.
Although "localhost.localdomain" is not an invalid hostname the OP does
not appear to have used it. (We have not been given the contents of his
/etc/hostname explicitly).

What was the problem with his resolv.conf? Have I missed that?

-- 
Brian.

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

>>
>> I believe topic is closed with this.
>
> For the benefit of other users: what does your /etc/hosts look like now?
>
> --
> Brian.
>
>

root@localhost:~# cat /proc/sys/kernel/hostname
localhost.localdomain
root@localhost:~# grep localhost /etc/hosts
127.0.0.1   localhost localhost.localdomain
127.0.1.1   localhost
::1 localhost ip6-localhost ip6-loopback
root@localhost:~#

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[deloptes]

Reco wrote:

> The question is - since 'localhost.localdomain' is special, what happens
> if such hostname is chosen during the installation?

well, now we all know what happens :)

regards

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Reco]

Hi.

On Mon, Sep 18, 2017 at 08:50:36AM +0200, deloptes wrote:
> Gene Heskett wrote:
> 
> > 127.0.0.1 localhost.localdomain localhost
> 
> Sorry but I did not understand if the problem is there or if the problem is
> that it is not there?

Long story short, OP has a misbehaving Debian stretch installation with
the hostname (as in - /proc/sys/kernel/hostname) set to
'localhost.localdomain'.
/etc/hosts lacks such entry.
/etc/resolv.conf points to an absent DNS.

The result is - every execution of sudo has an added 30-second execution
time 'bonus'.
 

> I guess this is put there at time of installation. I'll check few virtual
> machines later to see how it was written.

If the user chooses conventional hostname (even 'debian') during the
installation - sure, they should put a record in /etc/hosts. Unsure
about stretch, but they did so since etch.

The question is - since 'localhost.localdomain' is special, what happens
if such hostname is chosen during the installation?


> IMO if you have working resolver it shouldn't matter much.

Please read this thread's subject one more time. Last three words
especially.

Reco

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Mon 18 Sep 2017 at 12:28:16 -0300, x9p wrote:

> Thanks for the memo. Seems the solution is to not call machine localhost,
> if insist in doing so, be sure it contains a "localhost.localdomain" line
> in /etc/hosts.
> 
> I believe topic is closed with this.

For the benefit of other users: what does your /etc/hosts look like now?

-- 
Brian.

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

>>
>> My chosen machine name was "localhost", problem partially lies here.
>
> Yeah, man.
>
> My uncle Harry had a similar problem when it occurred to him that--for
> reasons of simplicity and because of a failing memory--he might christen
> two recently-purchased kittens with identical names. Whenever he called
> one of them there would be a considerable delay (each of them assuming
> he was calling the other).
>
> Of course cats never come when you call them anyway (which is a clue
> the story may be apocryphal).
>
> BTW, did you get the memo?
>
> http://www.ietf.org/rfc/rfc1912.txt
>
>

>From rfc1912:

-
  Translating 127.0.0.1 into "localhost.dom.ain" can cause some
  software to connect back to the loopback interface when it didn't
  want to because "localhost" is not equal to "localhost.dom.ain".
-

Thanks for the memo. Seems the solution is to not call machine localhost,
if insist in doing so, be sure it contains a "localhost.localdomain" line
in /etc/hosts.

I believe topic is closed with this.

Thanks

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Curt]

On 2017-09-18, Greg Wooledge  wrote:
> On Mon, Sep 18, 2017 at 11:38:05AM +, Curt wrote:
>> On 2017-09-18, x9p  wrote:
>> > My chosen machine name was "localhost", problem partially lies here.
>> 
>> Yeah, man. 
>> 
>> My uncle Harry had a similar problem when it occurred to him that--for
>> reasons of simplicity and because of a failing memory--he might christen
>> two recently-purchased kittens with identical names. Whenever he called
>> one of them there would be a considerable delay (each of them assuming
>> he was calling the other).
>> 
>> Of course cats never come when you call them anyway (which is a clue
>> the story may be apocryphal). 
>
> The story makes more sense in this context if your uncle names his
> kitten "Me".

You're right. 

Your skit reminds me a little of "Who's on first?"

> Uncle Harry: "Have you seen Me?"
> Aunt Berta: "You're standing right there."
> Harry: "Not me.  Me."
> Berta; "Have you been drinking the rubbing alcohol again?"
>



-- 
"Time flies like an arrow. Fruit flies like a banana." Groucho

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Greg Wooledge]

On Mon, Sep 18, 2017 at 11:38:05AM +, Curt wrote:
> On 2017-09-18, x9p  wrote:
> > My chosen machine name was "localhost", problem partially lies here.
> 
> Yeah, man. 
> 
> My uncle Harry had a similar problem when it occurred to him that--for
> reasons of simplicity and because of a failing memory--he might christen
> two recently-purchased kittens with identical names. Whenever he called
> one of them there would be a considerable delay (each of them assuming
> he was calling the other).
> 
> Of course cats never come when you call them anyway (which is a clue
> the story may be apocryphal). 

The story makes more sense in this context if your uncle names his
kitten "Me".

Uncle Harry: "Have you seen Me?"
Aunt Berta: "You're standing right there."
Harry: "Not me.  Me."
Berta; "Have you been drinking the rubbing alcohol again?"

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Mon 18 Sep 2017 at 06:32:55 -0300, x9p wrote:

(Please watch your attributioms; it confuses matters. x9p did not write
this).

> > This is the default from the last stretch install
> >
> > $ cat /etc/hosts
> > 127.0.0.1       localhost
> > 127.0.1.1       fujitsu.mydomain    fujitsu
> >
> > so if mydomain or localdomain is not working it will delay.
> >
> > 127.0.1.1   fujitsu fujitsu.mydomain
> >
> > will not delay because fujitsu is the name of the machine.
> >
> > in my case mydomain was added at installation time, because cable was
> > plugged in and the computer (fujitsu) got its IP via the dhcp server on
> > the
> > local network.
> >
> > IMO you should look deeper in your use case and see why you get invalid
> > setup. The problem might be somewhere else.
> >
> > regards
> 
> My chosen machine name was "localhost", problem partially lies here.

The hosts manual says each host should have a line like

  IP_address canonical_hostname [aliases...]

By implication the catonical_hostname should be for one IP_address. You
have (had?)

  root@localhost:~# grep localhost /etc/hosts
  127.0.0.1   localhost
  127.0.1.1   localhost

The first line is ok; the canonical_hostname localhost has the address
127.0.0.1. The second line is not ok.

The file /etc/hostname has the system hostname; it should not be
"localhost". If it was "stretch" then the second line should be

  127.0.1.1   stretch

(This becomes a little more complicated if a mail server is one of the
services being run on the machine).

-- 
Brian.

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Curt]

On 2017-09-18, x9p  wrote:
>>
>> IMO you should look deeper in your use case and see why you get invalid
>> setup. The problem might be somewhere else.
>>
>> regards
>>
>>
>
> My chosen machine name was "localhost", problem partially lies here.

Yeah, man. 

My uncle Harry had a similar problem when it occurred to him that--for
reasons of simplicity and because of a failing memory--he might christen
two recently-purchased kittens with identical names. Whenever he called
one of them there would be a considerable delay (each of them assuming
he was calling the other).

Of course cats never come when you call them anyway (which is a clue
the story may be apocryphal). 

BTW, did you get the memo?

http://www.ietf.org/rfc/rfc1912.txt


> x9p
>
>
>


-- 
"Time flies like an arrow. Fruit flies like a banana." Groucho

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

>
> This is the default from the last stretch install
>
> $ cat /etc/hosts
> 127.0.0.1       localhost
> 127.0.1.1       fujitsu.mydomain    fujitsu
>
> so if mydomain or localdomain is not working it will delay.
>
> 127.0.1.1   fujitsu fujitsu.mydomain
>
> will not delay because fujitsu is the name of the machine.
>
> in my case mydomain was added at installation time, because cable was
> plugged in and the computer (fujitsu) got its IP via the dhcp server on
> the
> local network.
>
> IMO you should look deeper in your use case and see why you get invalid
> setup. The problem might be somewhere else.
>
> regards
>
>

My chosen machine name was "localhost", problem partially lies here.

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[deloptes]

x9p wrote:

> If system hostname should ALWAYS be resolvable, whether there is network
> or no, the change in /etc/hosts
> from (default in stretch):
> 127.0.0.1       localhost
> to (my system):
> 127.0.0.1       localhost localhost.localdomain
> 
> is justifiable as it breaks (not literally break, just adds lot of delay)
> to sudo in a non-networked environment.

This is the default from the last stretch install

$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       fujitsu.mydomain    fujitsu

so if mydomain or localdomain is not working it will delay.

127.0.1.1   fujitsu fujitsu.mydomain

will not delay because fujitsu is the name of the machine.

in my case mydomain was added at installation time, because cable was
plugged in and the computer (fujitsu) got its IP via the dhcp server on the
local network.

IMO you should look deeper in your use case and see why you get invalid
setup. The problem might be somewhere else.

regards

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[deloptes]

Gene Heskett wrote:

> 127.0.0.1 localhost.localdomain localhost

Sorry but I did not understand if the problem is there or if the problem is
that it is not there?

I guess this is put there at time of installation. I'll check few virtual
machines later to see how it was written.

IMO if you have working resolver it shouldn't matter much.

regards

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

> The last time I recollect this "someone" sticking his head above the
parapet was in the thread beginning at
>  https://lists.debian.org/debian-devel/2013/07/msg00809.html

>From the above URL:

From: Christoph Anton Mitterer 
Date: Tue, 30 Jul 2013 22:43:44 +0200

-
- The system hostname (and domainname if any) should ALWAYS be
resolvable, whether a network is up or not, regardless of which.
(Assuming that lo is always up, if not, many things break anyway.)

- "localhost" when added like this to /etc/hosts is basically like a TLD.
"localhost" is one of the reserved names, unlike ip6-localhost and friends
and unlike .localdomain.
...
...
...
Further, but this isn't the case anymore anyway,... we should not
generate localhost.localdomain.
...
...
...
-

If system hostname should ALWAYS be resolvable, whether there is network
or no, the change in /etc/hosts
from (default in stretch):
127.0.0.1   localhost
to (my system):
127.0.0.1   localhost localhost.localdomain

is justifiable as it breaks (not literally break, just adds lot of delay)
to sudo in a non-networked environment.

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Sun 17 Sep 2017 at 18:43:18 -0400, Gene Heskett wrote:

> On Sunday 17 September 2017 16:39:25 x9p wrote:
> 
> > > Since the /etc/hosts file can also contain aliases, the ideaL way
> > > would seem to be to make use of that. Example:
> > > 192.168.x.z   localhost.localdomain   localhost
> >
> > You are right, this solves the problem of the DNS lookup / X seconds
> > delay to run sudo even with a buggy DNS server:
> >
> > root@localhost:~# head -1 /etc/hosts
> > 127.0.0.1   localhost localhost.localdomain
> >
> In this case it should make only microseconds difference, but the first 
> name given s/b the FQDN, the 2nd and other space separated strings on 
> the same line would be the alias's.  In the above case, that would 
> interchange the pair of strings. But I doubt if the time difference 
> could be measured w/o some fancy machine assistance.
> 
> > Should be on debian by default in my opinion.
> 
> I agree, but I don't have permission to even blow the whistle on this 
> train called linux. :) Basically someone decides its more secure, 
> without considering the amount of time that 1000 others like you will 
> expend restoring what is to you, normal near instant operation.  Maybe 
> it is a good idea, but the person who made that change is too busy 
> hiding from the hordes to even consider sticking up his keyboard and 
> justifying the change, including what we have to change to keep 
> everything running.

The last time I recollect this "someone" sticking his head above
the parapet was in the thread beginning at

 https://lists.debian.org/debian-devel/2013/07/msg00809.html

The hordes retreated in the face of strong technical (non-security
related) argument.

-- 
Brian.

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Gene Heskett]

On Sunday 17 September 2017 18:58:30 deloptes wrote:

> Gene Heskett wrote:
> > On Sunday 17 September 2017 16:54:27 deloptes wrote:
> >> x9p wrote:
> >> > Should be on debian by default in my opinion.
> >>
> >> ... and truly it is
> >
> > Not on the 3 other wheezy's nor on the one jessie machine I can
> > inspect in a couple minutes here.
> >
> > Cheers, Gene Heskett
>
> No idea, on any debian I installed local host maps to 127.0.0.1
>
> This is the default from the last stretch install
>
> $ cat /etc/hosts
> 127.0.0.1   localhost

The above is precisely my point, there is NOT a 

127.0.0.1 localhost.localdomain localhost 

entry in anyones /etc/hosts file unless THEY PUT IT THERE.

So while I seem to have fixed the OP's problem, the fix is now masking 
the real problem (and I haven't a clue what the heck that actually is)

 
> 127.0.1.1   fujitsu.mydomainfujitsu
>
> # The following lines are desirable for IPv6 capable hosts
>
> ::1 localhost ip6-localhost ip6-loopback
>
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
>
> Interesting to know why.
>
> If it is about localhost.localdomain  no idea where localdomain is
> coming from. Perhaps if you install in a local network without domain,
> or if you do not enter any.
>
> The line in stretch
>
> 127.0.1.1   fujitsu.mydomainfujitsu
>
> is new to me, but computer works with local dhcp/dns, so why bother
>
> regards


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[deloptes]

Gene Heskett wrote:

> On Sunday 17 September 2017 16:54:27 deloptes wrote:
> 
>> x9p wrote:
>> > Should be on debian by default in my opinion.
>>
>> ... and truly it is
> 
> Not on the 3 other wheezy's nor on the one jessie machine I can inspect
> in a couple minutes here.
> 
> Cheers, Gene Heskett

No idea, on any debian I installed local host maps to 127.0.0.1

This is the default from the last stretch install

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   fujitsu.mydomainfujitsu

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Interesting to know why.

If it is about localhost.localdomain  no idea where localdomain is
coming from. Perhaps if you install in a local network without domain, or
if you do not enter any.

The line in stretch

127.0.1.1   fujitsu.mydomainfujitsu

is new to me, but computer works with local dhcp/dns, so why bother

regards

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Gene Heskett]

On Sunday 17 September 2017 16:54:27 deloptes wrote:

> x9p wrote:
> > Should be on debian by default in my opinion.
>
> ... and truly it is

Not on the 3 other wheezy's nor on the one jessie machine I can inspect 
in a couple minutes here.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Gene Heskett]

On Sunday 17 September 2017 16:39:25 x9p wrote:

> > Since the /etc/hosts file can also contain aliases, the ideaL way
> > would seem to be to make use of that. Example:
> > 192.168.x.z localhost.localdomain   localhost
>
> You are right, this solves the problem of the DNS lookup / X seconds
> delay to run sudo even with a buggy DNS server:
>
> root@localhost:~# head -1 /etc/hosts
> 127.0.0.1   localhost localhost.localdomain
>
In this case it should make only microseconds difference, but the first 
name given s/b the FQDN, the 2nd and other space separated strings on 
the same line would be the alias's.  In the above case, that would 
interchange the pair of strings. But I doubt if the time difference 
could be measured w/o some fancy machine assistance.

> Should be on debian by default in my opinion.

I agree, but I don't have permission to even blow the whistle on this 
train called linux. :) Basically someone decides its more secure, 
without considering the amount of time that 1000 others like you will 
expend restoring what is to you, normal near instant operation.  Maybe 
it is a good idea, but the person who made that change is too busy 
hiding from the hordes to even consider sticking up his keyboard and 
justifying the change, including what we have to change to keep 
everything running.
> x9p


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Brian]

On Sun 17 Sep 2017 at 22:54:27 +0200, deloptes wrote:

> x9p wrote:
> 
> > Should be on debian by default in my opinion.
> 
> ... and truly it is

Really? Not on any install I have done and not according to the netcfg
source package:

  * Don't make 'localhost.localdomain' the canonical hostname of 127.0.0.1. 

See Oct 2005 debian-devel discussion with Subject: localhost.localdomain,

  * Per Olofsson

- Map 127.0.0.1 to localhost in /etc/hosts, make the hostname   

  an alias instead.

-- 
Brian. 

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[deloptes]

x9p wrote:

> Should be on debian by default in my opinion.

... and truly it is

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

> Since the /etc/hosts file can also contain aliases, the ideaL way would
> seem to be to make use of that. Example:
> 192.168.x.z   localhost.localdomain   localhost
>

You are right, this solves the problem of the DNS lookup / X seconds delay
to run sudo even with a buggy DNS server:

root@localhost:~# head -1 /etc/hosts
127.0.0.1   localhost localhost.localdomain

Should be on debian by default in my opinion.

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Gene Heskett]

On Friday 15 September 2017 19:17:30 x9p wrote:

> > Thanks, now I see it.
> >
> > Your /etc/hosts says:
> >
> > 127.0.0.1   localhost
> > 127.0.1.1   localhost
> >
> > ::1 localhost ip6-localhost ip6-loopback
> >
> > Note the absence of localhost.localdomain.
> >
> >
> > Your hostname is "localhost.localdomain", as strace helpfully shows
> > us:
> >
> > uname({sysname="Linux", nodename="localhost.localdomain", ...})
>
> strangely i do not remember calling it localhost with domain
> localdomain, just localhost.
>
> > I won't say that specifying fqdn as nodename is wrong per se, but in
> > your case you don't have a record for your hostname in /etc/hosts.
> >
> > This *could* be the case that's nss-myhostname is designed for but
> > … it's the last in your nsswitch.conf so it cannot come into play.
> >
> > Therefore libc resolver you're using does exactly the same way it's
> > supposed to - search for localhost.localdomain in /etc/hosts first,
> > query DNS next.
> >
> >
> > Quick and dirty way to fix this is to add a record for
> > 'localhost.localdomain' in your /etc/hosts.
>
> Will do it, thanks
>
> > Correct, but painful way (I won't even try to predict what you could
> > break in your setup) to fix this is to ensure that your hostname is
> > 'localhost' verbatim.
>
> I still think correct way is sudo not try to access network functions
> in a setup where it does not need to - waste of time, code, and opens
> it to more bugs.
>
> Thanks for the analysis Reco.
>
> x9p

Since the /etc/hosts file can also contain aliases, the ideaL way would 
seem to be to make use of that. Example:
192.168.x.z localhost.localdomain   localhost

where x.z are the triplets (without the zero leading fill of course) 
corresponding to the class d of your local network.

Then you shouldn't have any dns problems if your resolv.conf is correct.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
++

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

> Thanks, now I see it.
>
> Your /etc/hosts says:
>
> 127.0.0.1   localhost
> 127.0.1.1   localhost
> ::1 localhost ip6-localhost ip6-loopback
>
> Note the absence of localhost.localdomain.
>
>
> Your hostname is "localhost.localdomain", as strace helpfully shows us:
>
> uname({sysname="Linux", nodename="localhost.localdomain", ...})
>

strangely i do not remember calling it localhost with domain localdomain,
just localhost.

>
> I won't say that specifying fqdn as nodename is wrong per se, but in
> your case you don't have a record for your hostname in /etc/hosts.
>
> This *could* be the case that's nss-myhostname is designed for but …
> it's the last in your nsswitch.conf so it cannot come into play.
>
> Therefore libc resolver you're using does exactly the same way it's
> supposed to - search for localhost.localdomain in /etc/hosts first,
> query DNS next.
>
>
> Quick and dirty way to fix this is to add a record for
> 'localhost.localdomain' in your /etc/hosts.
>

Will do it, thanks

> Correct, but painful way (I won't even try to predict what you could
> break in your setup) to fix this is to ensure that your hostname is
> 'localhost' verbatim.
>

I still think correct way is sudo not try to access network functions in a
setup where it does not need to - waste of time, code, and opens it to
more bugs.

Thanks for the analysis Reco.

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Reco]

On Fri, Sep 15, 2017 at 06:32:17PM -0300, x9p wrote:
> 
> > Your snippet of strace output on pastebin is lacking the beginning.
> > What I'm currently interested in are:
> >
> > 1) Libraries and configuration files that sudo is opening (hence the
> > 'open' syscall). Thinking about it, make it 'open,stat'.
> >
> > 2) What kind of network sockets (short of kinda obvious UDP) sudo is
> > opening (hence the 'connect' syscall).
> >
> 
> Sorry for that, pasted the full output here.
> https://pastebin.com/0bV7JC1z
> 
> > Feel free to edit out all unnecessary details of course.
> 
> No need.

Thanks, now I see it.

Your /etc/hosts says:

127.0.0.1   localhost
127.0.1.1   localhost
::1 localhost ip6-localhost ip6-loopback

Note the absence of localhost.localdomain.


Your hostname is "localhost.localdomain", as strace helpfully shows us:

uname({sysname="Linux", nodename="localhost.localdomain", ...})


I won't say that specifying fqdn as nodename is wrong per se, but in
your case you don't have a record for your hostname in /etc/hosts.

This *could* be the case that's nss-myhostname is designed for but …
it's the last in your nsswitch.conf so it cannot come into play.

Therefore libc resolver you're using does exactly the same way it's
supposed to - search for localhost.localdomain in /etc/hosts first,
query DNS next.


Quick and dirty way to fix this is to add a record for
'localhost.localdomain' in your /etc/hosts.

Correct, but painful way (I won't even try to predict what you could
break in your setup) to fix this is to ensure that your hostname is
'localhost' verbatim.

Reco

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

> You should have a localhost entry in /etc/hosts. If you have
> configured your /etc/sudoers to specify "localhost.localdomain",
> then you should also have a localhost.localdomain entry in
> /etc/hosts, or your should change the sudoers config to just
> reference "localhost".
>

No changes were made to the /etc/sudoers except this:

myuser ALL=(ALL) NOPASSWD:ALL

I did not touched any Host_List. Debian by default do not come with
localhost on /etc/sudoers.

sudo binary does come with the "localhost" string in it.

root@localhost:~# strings /usr/bin/sudo | egrep localhost
localhost

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

> Your snippet of strace output on pastebin is lacking the beginning.
> What I'm currently interested in are:
>
> 1) Libraries and configuration files that sudo is opening (hence the
> 'open' syscall). Thinking about it, make it 'open,stat'.
>
> 2) What kind of network sockets (short of kinda obvious UDP) sudo is
> opening (hence the 'connect' syscall).
>

Sorry for that, pasted the full output here.
https://pastebin.com/0bV7JC1z

> Feel free to edit out all unnecessary details of course.

No need.

>
> PS Replying to debian-user@lists.debian.org is sufficient. There's no
> need to CC me, I'm subscribed to the list.
>

Sorry for that. I just hit "reply all", fixing.

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Reco]

On Fri, Sep 15, 2017 at 06:06:02PM -0300, x9p wrote:
> 
> > sudo(8) says:
> >
> >  sudo supports a plugin architecture for security policies and
> > input/output logging.  Third parties can develop and distribute their
> > own policy and I/O logging plugins to work seamlessly with the sudo
> > front end.  The default security policy is sudoers, which is configured
> > via the file /etc/sudoers, or via LDAP.
> >
> > And LDAP means TCP, and TCP usually mean DNS requests.
> >
> > So it's unusual (sudo does not exhibit such behavior here), but
> > possible.
> >
> 
> Agree there are situations where sudo does TCP. Disagree with that
> occurring in my simplistic setup. sudo should not hang for X seconds if my
> DNS servers are incorrect.
> 
> > A stray nameserver in resolv.conf, which can happen if resolvconf is
> > used carelessly. Even more weird things are always possible with
> > NetworkManager.
> 
> Am too old, I like /etc/resolv.conf being just a file. Am avoiding to turn
> this into a systemd talk.

Was not my intention. All those things can happen if one's using
sysvinit.


> >> > Specifically I'm interested with:
> >> >
> >> > grep hosts /etc/nsswitch.conf
> >> >
> >> > grep localhost /etc/hosts
> >> >
> >> > Reco
> >> >
> >>
> >> Did not touched these, are the default from stretch:
> >>
> >> root@localhost:~# grep hosts /etc/nsswitch.conf
> >> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
> >> root@localhost:~# grep localhost /etc/hosts
> >> 127.0.0.1   localhost
> >> 127.0.1.1   localhost
> >> ::1 localhost ip6-localhost ip6-loopback
> >
> > Curious. Can you reproduce the behaviour if sudo is run as root?
> > I propose to simplify things a bit (needs to be run as root):
> >
> 
> strace was already run as root (did "sudo su" as root to prove the point),
> otherwise strace would fail with "effective uid is not 0".

Your snippet of strace output on pastebin is lacking the beginning.
What I'm currently interested in are:

1) Libraries and configuration files that sudo is opening (hence the
'open' syscall). Thinking about it, make it 'open,stat'.

2) What kind of network sockets (short of kinda obvious UDP) sudo is
opening (hence the 'connect' syscall).

Feel free to edit out all unnecessary details of course.


PS Replying to debian-user@lists.debian.org is sufficient. There's no
need to CC me, I'm subscribed to the list.

Reco

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Dan Ritter]

On Fri, Sep 15, 2017 at 12:46:09PM -0300, x9p wrote:
> 
> I was getting > 30sec to complete "sudo su" on a host. This host had
> invalid entries in resolv.conf and I realized sudo was doing 5 seconds
> lookup on each entry searching for "localhost.localdomain"
> 
> sudo is 1.8.19p1 @ stretch.
> 
> Believe no DNS lookups should be made... even for localhost

You should have a localhost entry in /etc/hosts. If you have
configured your /etc/sudoers to specify "localhost.localdomain",
then you should also have a localhost.localdomain entry in
/etc/hosts, or your should change the sudoers config to just 
reference "localhost".

-dsr-

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

> sudo(8) says:
>
>  sudo supports a plugin architecture for security policies and
> input/output logging.  Third parties can develop and distribute their
> own policy and I/O logging plugins to work seamlessly with the sudo
> front end.  The default security policy is sudoers, which is configured
> via the file /etc/sudoers, or via LDAP.
>
> And LDAP means TCP, and TCP usually mean DNS requests.
>
> So it's unusual (sudo does not exhibit such behavior here), but
> possible.
>

Agree there are situations where sudo does TCP. Disagree with that
occurring in my simplistic setup. sudo should not hang for X seconds if my
DNS servers are incorrect.

> A stray nameserver in resolv.conf, which can happen if resolvconf is
> used carelessly. Even more weird things are always possible with
> NetworkManager.

Am too old, I like /etc/resolv.conf being just a file. Am avoiding to turn
this into a systemd talk.

>> resolv.conf is not a symlink to systemd, just a plain file. I explicitly
>> removed the symlink and created a normal file.
>
> And of course one can never disregard a misconfigured VPN script.
>
>
>
>> > Specifically I'm interested with:
>> >
>> > grep hosts /etc/nsswitch.conf
>> >
>> > grep localhost /etc/hosts
>> >
>> > Reco
>> >
>>
>> Did not touched these, are the default from stretch:
>>
>> root@localhost:~# grep hosts /etc/nsswitch.conf
>> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
>> root@localhost:~# grep localhost /etc/hosts
>> 127.0.0.1   localhost
>> 127.0.1.1   localhost
>> ::1 localhost ip6-localhost ip6-loopback
>
> Curious. Can you reproduce the behaviour if sudo is run as root?
> I propose to simplify things a bit (needs to be run as root):
>

strace was already run as root (did "sudo su" as root to prove the point),
otherwise strace would fail with "effective uid is not 0".

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Reco]

On Fri, Sep 15, 2017 at 04:28:31PM -0300, x9p wrote:
> 
> > Hi.
> 
> Hi.
> 
> >
> > While DNS lookups for localhost are unusual any reasonable configured
> > DNS should have no trouble resolving it. Especially since there are OSes
> > that try to resolve *everything* by default via including localhost (AIX
> > comes to mind).
> >
> 
> Understand, but disagree with sudo doing DNS lookups. Will fill a bug with
> them.

sudo(8) says:

 sudo supports a plugin architecture for security policies and
input/output logging.  Third parties can develop and distribute their
own policy and I/O logging plugins to work seamlessly with the sudo
front end.  The default security policy is sudoers, which is configured
via the file /etc/sudoers, or via LDAP.

And LDAP means TCP, and TCP usually mean DNS requests.

So it's unusual (sudo does not exhibit such behavior here), but
possible.


> > While you mentioned misconfigured resolv.conf I believe your problem
> > lies somewhat deeper than this.
> 
> Actually it is deeper. I did not pay that much attention to the strace I
> did before.
> 
> https://pastebin.com/j0rw5Kgn
> 
> 10.1.2.9 is the DNS of the company I work for, turned out I had not
> connected to the VPN yet by the time i issued the sudo command.

A stray nameserver in resolv.conf, which can happen if resolvconf is
used carelessly. Even more weird things are always possible with
NetworkManager.

> resolv.conf is not a symlink to systemd, just a plain file. I explicitly
> removed the symlink and created a normal file.

And of course one can never disregard a misconfigured VPN script.



> > Specifically I'm interested with:
> >
> > grep hosts /etc/nsswitch.conf
> >
> > grep localhost /etc/hosts
> >
> > Reco
> >
> 
> Did not touched these, are the default from stretch:
> 
> root@localhost:~# grep hosts /etc/nsswitch.conf
> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
> root@localhost:~# grep localhost /etc/hosts
> 127.0.0.1   localhost
> 127.0.1.1   localhost
> ::1 localhost ip6-localhost ip6-loopback

Curious. Can you reproduce the behaviour if sudo is run as root?
I propose to simplify things a bit (needs to be run as root):

strace -o /tmp/sudo -econnect,open sudo -i

Reco

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

> Hi.

Hi.

>
> While DNS lookups for localhost are unusual any reasonable configured
> DNS should have no trouble resolving it. Especially since there are OSes
> that try to resolve *everything* by default via including localhost (AIX
> comes to mind).
>

Understand, but disagree with sudo doing DNS lookups. Will fill a bug with
them.

> While you mentioned misconfigured resolv.conf I believe your problem
> lies somewhat deeper than this.

Actually it is deeper. I did not pay that much attention to the strace I
did before.

https://pastebin.com/j0rw5Kgn

10.1.2.9 is the DNS of the company I work for, turned out I had not
connected to the VPN yet by the time i issued the sudo command.

---

connect(6, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.1.2.9")}, 16) = 0^M
poll([{fd=6, events=POLLOUT}], 1, 0)= 1 ([{fd=6, revents=POLLOUT}])^M
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2^M
poll([{fd=6, events=POLLIN}], 1, 5000)  = 0 (Timeout)^M

---

resolv.conf is not a symlink to systemd, just a plain file. I explicitly
removed the symlink and created a normal file.

> Specifically I'm interested with:
>
> grep hosts /etc/nsswitch.conf
>
> grep localhost /etc/hosts
>
> Reco
>

Did not touched these, are the default from stretch:

root@localhost:~# grep hosts /etc/nsswitch.conf
hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
root@localhost:~# grep localhost /etc/hosts
127.0.0.1   localhost
127.0.1.1   localhost
::1 localhost ip6-localhost ip6-loopback

x9p

Re: sudo slow on DNS lookup, with invalid resolv.conf entries

[Reco]

Hi.

On Fri, Sep 15, 2017 at 12:46:09PM -0300, x9p wrote:
> 
> I was getting > 30sec to complete "sudo su" on a host. This host had
> invalid entries in resolv.conf and I realized sudo was doing 5 seconds
> lookup on each entry searching for "localhost.localdomain"
> 
> sudo is 1.8.19p1 @ stretch.
> 
> Believe no DNS lookups should be made... even for localhost

While DNS lookups for localhost are unusual any reasonable configured
DNS should have no trouble resolving it. Especially since there are OSes
that try to resolve *everything* by default via including localhost (AIX
comes to mind).

While you mentioned misconfigured resolv.conf I believe your problem
lies somewhat deeper than this.

Specifically I'm interested with:

grep hosts /etc/nsswitch.conf

grep localhost /etc/hosts

Reco

sudo slow on DNS lookup, with invalid resolv.conf entries

[x9p]

I was getting > 30sec to complete "sudo su" on a host. This host had
invalid entries in resolv.conf and I realized sudo was doing 5 seconds
lookup on each entry searching for "localhost.localdomain"

sudo is 1.8.19p1 @ stretch.

Believe no DNS lookups should be made... even for localhost


sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\313\265\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=51}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\371\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=51}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\313\265\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=51}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\371\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=51}], 2, MSG_NOSIGNAL) = 2