"su" - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable

[Sven Uhlig]

Hello,

this is my first message to this list.

I noticed a little problem on my system after I installed the package
"virt-manager" and its dependencies on my system. One of the
dependencies is "dbus".

The problem is that "su" takes 25 seconds before it succeeds.

Using strace I think I identified the problem:
> connect(4, {sa_family=AF_FILE,
path="/var/run/dbus/system_bus_socket"}, 33) = 0
> ...
> poll([{fd=4, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.028989>

The reasons seems to be my setup of the system.
Debian runs in a VirtualBox environment, headless and w/o X server.
I use ssh to connect to the system. (putty)
I use X forwarding to run X applications on the system.
The variable $DISPLAY gets set to 10.0.2.2:0 after ssh auth.
I only run the X server if it is required for running a X application.

I can skip the timeout if I do either of these two things:
Solution 1) run X server on 10.0.2.2 (Xming)
Solution 2) unset $DISPLAY

Is there something I can change in any of the configurations of "dbus"
or "su" to skip the timeout? Maybe don't use "dbus" for "su" at all?

System information:
> $ uname -a
> Linux baldur 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux
> $ dbus-daemon --version
> D-Bus Message Bus Daemon 1.6.8

Best regards
Sven.


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5143A009...@web.de

[Bob Proulx]

Sven Uhlig wrote:
> this is my first message to this list.

Welcome.

> I noticed a little problem on my system after I installed the package
> "virt-manager" and its dependencies on my system. One of the
> dependencies is "dbus".

Ugh. "dbus". I feel your pain. Too many applications have egregious
dependencies upon dbus. (For example I disagree that emacs needs dbus
to operate. But there it is.)

> The problem is that "su" takes 25 seconds before it succeeds.

That sounds like a DNS timeout. Although you have reported that it is
only when used with $DISPLAY set I still would want to double check
that the system's hostname is set up correctly. If you do a dns
lookup of your systems hostname does it respond?

Look in /etc/hosts and look for (at least) these lines:

127.0.0.1 localhost
127.0.1.1 foo.example.com foo

Replace foo.example.com with your actual hostname. That should be
there. If that is not there then it is likely the source of dns
lookup timeout problems. Because PAM often logs the hostname to the
system log and does other such DNS lookups.

> Using strace I think I identified the problem:
> > connect(4, {sa_family=AF_FILE,
> path="/var/run/dbus/system_bus_socket"}, 33) = 0
> > ...
> > poll([{fd=4, events=POLLIN}], 1, 25000) = 0 (Timeout) <25.028989>
>
> The reasons seems to be my setup of the system.
> Debian runs in a VirtualBox environment, headless and w/o X server.

That sounds normal to me. I would even go so far as to say
mainstream. I would not call headless without X server unusual at
all. And that it is VirtualBox shouldn't make any difference at all.
Most of us use ssh to connect. And the X forwarding or not as we desire.
All of that is very normal.

> I can skip the timeout if I do either of these two things:
> Solution 1) run X server on 10.0.2.2 (Xming)
> Solution 2) unset $DISPLAY

If you dns lookup 10.0.2.2 does it resolve? Quickly or after a longer
timeout?

Hopefully someone else will have a better suggestion.

Bob

[Sven Uhlig]

On 16.03.2013 05:45, Bob Proulx wrote:
>> The problem is that "su" takes 25 seconds before it succeeds.
>

> That sounds like a DNS timeout. If you do a dns lookup of your

> systems hostname does it respond?

# nslookup localhost
Name: localhost
Address: 127.0.0.1

# nslookup 127.0.0.1
1.0.0.127.in-addr.arpa name = localhost.

# nslookup baldur
** server can't find baldur: NXDOMAIN

# nslookup baldur.asgard
** server can't find baldur.asgard: NXDOMAIN

# ping baldur
PING baldur.asgard (127.0.1.1) 56(84) bytes of data.

> Look in /etc/hosts and look for (at least) these lines:

# grep 127. /etc/hosts
127.0.0.1 localhost
127.0.1.1 baldur.asgard baldur

> Because PAM often logs the hostname to the system log and does
> other such DNS lookups.

Can I disable reverse DNS lookup?

>> Using strace I think I identified the problem:
>>> connect(4, {sa_family=AF_FILE,
>> path="/var/run/dbus/system_bus_socket"}, 33) = 0
>>> ... poll([{fd=4, events=POLLIN}], 1, 25000) = 0 (Timeout)
>>> <25.028989>
>>

>> I can skip the timeout if I do either of these two things:
>> Solution 1) run X server on 10.0.2.2 (Xming) Solution 2) unset
>> $DISPLAY
>
> If you dns lookup 10.0.2.2 does it resolve? Quickly or after a
> longer timeout?

# nslookup 10.0.2.2
** server can't find 2.2.0.10.in-addr.arpa.: NXDOMAIN

# ping 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.

# ping wotan
ping: unknown host wotan

C's getnameinfo() returns: "Name or service not known"


But as it is a private IP, why should there be a DNS? Wouldnt everyone
have the same problem if they dont set up their own BIND or hosts file?

I have added the remote hostname to /etc:
# grep wotan /etc/hosts
10.0.2.2 wotan.asgard wotan

Of course I only get the following changes:
# ping wotan
PING wotan.asgard (10.0.2.2) 56(84) bytes of data.

C's getnameinfo() returns: wotan.asgard


Though no change in the behaviour of "su", still a 25 seconds timeout
before it succeeds.

In the output of strace I can see that /something/ happens with
libnss, so DNS lookup. But unfortunately I am unable to tell what it
is. But there seems not to be any timeout related to DNS.

Any use of posting a full strace log? I dont think so.

> Hopefully someone else will have a better suggestion.

Thank you anyways. Getting any response is always good, instead of
being ignored completely :)

Sven.


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/514422E...@web.de

[Clive Standbridge]

> The reasons seems to be my setup of the system.
> Debian runs in a VirtualBox environment, headless and w/o X server.
> I use ssh to connect to the system. (putty)
> I use X forwarding to run X applications on the system.
> The variable $DISPLAY gets set to 10.0.2.2:0 after ssh auth.

Sven,

I'm pretty sure that the value of DISPLAY means you are using a
traditional X connection, and not actually using the X forwarding over
ssh. ssh would set DISPLAY to "localhost:10" or similar.

Setting up ssh forwarding correctly could avoid your problem because
it will set DISPLAY only when it's valid.

You will need to remove any setting of DISPLAY from your shell's
startup files. Assuming you use bash, that would include
/etc/profile
/etc/bash.bashrc
~/.profile
~/.bash_profile
~/.bash_login
~/.bashrc
and anything sourced by those files.

Make sure your /etc/ssh/sshd_config contains a line:
X11Forwarding yes
If it's missing, add it then restart the ssh server.

Then connect from Putty without X forwarding. DISPLAY should not be
set on the Debian machine.

Then connect from Putty with X forwarding. DISPLAY should be
"localhost:10" or similar.

I hope this helps.

--
Cheers,
Clive

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20130317015...@rimmer.localdomain

[Bob Proulx]

Sven Uhlig wrote:
> Bob Proulx wrote:
> >> The problem is that "su" takes 25 seconds before it succeeds.
> >
> > That sounds like a DNS timeout. If you do a dns lookup of your
> > systems hostname does it respond?
>
> # nslookup localhost
> Name: localhost
> Address: 127.0.0.1
>
> # nslookup 127.0.0.1
> 1.0.0.127.in-addr.arpa name = localhost.

Good.

> # nslookup baldur
> ** server can't find baldur: NXDOMAIN
>
> # nslookup baldur.asgard
> ** server can't find baldur.asgard: NXDOMAIN

Unfortunately nslookup only looks at DNS. It is a DNS tool and does
not follow /etc/nsswitch.conf for looking at other locations such as
the /etc/hosts file. It is the reason I use the libc tool 'getent' to
use the libc lookup routine and do whatever is configured.

getent baldur.asgard

> # ping baldur
> PING baldur.asgard (127.0.1.1) 56(84) bytes of data.

See that ping does do the lookup and does find the address okay. But
although I know that many people use ping for a lookup tool that is
really only a side effect of the primary purpose of ping.

> > Look in /etc/hosts and look for (at least) these lines:
>
> # grep 127. /etc/hosts
> 127.0.0.1 localhost
> 127.0.1.1 baldur.asgard baldur

Looks good.

> > Because PAM often logs the hostname to the system log and does
> > other such DNS lookups.
>
> Can I disable reverse DNS lookup?

The data you provided, that ping showed the lookup okay, says that
this isn't the problem. The problem must be something else. Which at
least is good to know by itself. But it means you need to keep looking.

> >> I can skip the timeout if I do either of these two things:
> >> Solution 1) run X server on 10.0.2.2 (Xming) Solution 2) unset
> >> $DISPLAY
> >
> > If you dns lookup 10.0.2.2 does it resolve? Quickly or after a
> > longer timeout?
>
> # nslookup 10.0.2.2
> ** server can't find 2.2.0.10.in-addr.arpa.: NXDOMAIN
>

> # ping wotan
> ping: unknown host wotan

At this point I would suggest that you try an experiment and add an
entry for 10.0.2.2 in your /etc/hosts file. Does that cause this to
speed up? But I see that you are ahead of me and did that experiment
already and it did not speed things up.

> But as it is a private IP, why should there be a DNS? Wouldnt everyone
> have the same problem if they dont set up their own BIND or hosts file?

Yes. But most people don't use ssh and terminals these days and those
that do know to have their dns set up correctly.

This is actually a common problem with 'sudo' unless "!fqdn" is
specified in the options. When dns is broken then sudo takes a very
long time when "fqdn" is specified. Therefore I always turn that
off. That long delay in sudo with dns broken is why I suspected a
problem with your 'su' delay and was thinking it might be similar.

> I have added the remote hostname to /etc:
> # grep wotan /etc/hosts
> 10.0.2.2 wotan.asgard wotan
>
> Of course I only get the following changes:
> # ping wotan
> PING wotan.asgard (10.0.2.2) 56(84) bytes of data.
>

> Though no change in the behaviour of "su", still a 25 seconds timeout
> before it succeeds.

It was a good experiment. I wish it had solved the problem.

> In the output of strace I can see that /something/ happens with
> libnss, so DNS lookup. But unfortunately I am unable to tell what it
> is. But there seems not to be any timeout related to DNS.

Another brainstorm idea. Do you have libnss-mdns installed? As an
experiment try removing it. I doubt you are using it. You can always
install it again.

apt-get purge libnss-mdns

I will cross my fingers and hope for good luck.

> Any use of posting a full strace log? I dont think so.

Doubtful. Unless someone in the know about dbus asks for it. You
have isolated it to a dbus problem.

> > Hopefully someone else will have a better suggestion.
>
> Thank you anyways. Getting any response is always good, instead of
> being ignored completely :)

I wish I could be more help. Hopefully someone knowledgeable about
dbus will have help with a solution for it.

Bob

[Sven Uhlig]

On 17.03.2013 03:12, Bob Proulx wrote:
> Sven Uhlig wrote:
>> Bob Proulx wrote:
>>>> The problem is that "su" takes 25 seconds before it
>>>> succeeds.
>>>
>>> That sounds like a DNS timeout. If you do a dns lookup of your
>>> systems hostname does it respond?
>>

>> # nslookup baldur ** server can't find baldur: NXDOMAIN
>>
>> # nslookup baldur.asgard ** server can't find baldur.asgard:
>> NXDOMAIN
>
> Unfortunately nslookup only looks at DNS. It is a DNS tool and
> does not follow /etc/nsswitch.conf for looking at other locations
> such as the /etc/hosts file. It is the reason I use the libc tool
> 'getent' to use the libc lookup routine and do whatever is
> configured.
>
> getent baldur.asgard
>

That is why I used C's getnameinfo().

How should getent work?

# getent baldur.asgard
Unknown database: baldur.asgard

# getent -V
getent (Debian EGLIBC 2.13-38) 2.13

Nevermind, my problem is solved, see mail by Clive Standbridge. :)

>> # ping baldur PING baldur.asgard (127.0.1.1) 56(84) bytes of
>> data.
>
> See that ping does do the lookup and does find the address okay.
> But although I know that many people use ping for a lookup tool
> that is really only a side effect of the primary purpose of ping.

I know but it is very convenient.

> That long delay in sudo with dns broken is why I suspected a
> problem with your 'su' delay and was thinking it might be similar.

It is a network thing. $DISPLAY was set to 10.0.2.2:0 where it should
have been localhost:10.0

>> In the output of strace I can see that /something/ happens with
>> libnss, so DNS lookup.
>

> Another brainstorm idea. Do you have libnss-mdns installed? As
> an experiment try removing it. I doubt you are using it. You can
> always install it again.

# apt-get purge libnss-mdns
Package 'libnss-mdns' is not installed, so not removed

> I wish I could be more help. Hopefully someone knowledgeable
> about dbus will have help with a solution for it.

Well, no help regarding dbus. But regarding X11Forwarding.

Thank you for your input!

Sven.


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/514598AB...@web.de

[Sven Uhlig]

On 17.03.2013 02:53, Clive Standbridge wrote:
>> The reasons seems to be my setup of the system.
>> Debian runs in a VirtualBox environment, headless and w/o X server.
>> I use ssh to connect to the system. (putty)
>> I use X forwarding to run X applications on the system.
>> The variable $DISPLAY gets set to 10.0.2.2:0 after ssh auth.
>

> I'm pretty sure that the value of DISPLAY means you are using a
> traditional X connection, and not actually using the X forwarding over
> ssh. ssh would set DISPLAY to "localhost:10" or similar.

That is so true!
I have no idea why I have overlooked that fact.

> You will need to remove any setting of DISPLAY from your shell's
> startup files.

Done.

I guess at some point I wanted to be smart and expected that using a
direct connection was quicker than X11Forwarding.

mea culpa

> Make sure your /etc/ssh/sshd_config contains a line:
> X11Forwarding yes

$ grep X11 /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10

> Then connect from Putty without X forwarding. DISPLAY should not be
> set on the Debian machine.

$ echo $DISPLAY|wc --words

0

> Then connect from Putty with X forwarding. DISPLAY should be
> "localhost:10" or similar.

$ echo $DISPLAY
localhost:10.0

> I hope this helps.

It actually does. Even if I keep X forwarding enabled and $DISPLAY set,
su is a lot faster now, good enough for me - problem solved.

Thank you very much for your help! :)

I think the reason why it is faster is that $DISPLAY is localhost with
dbus running. There is no Timeout in strace but only seemingly
successfull calls to the FD of the dbus socket.

Also if I do "/etc/init.d/dbus stop" su is even faster (read instant.)
And interestingly virt-manager still works without dbus. (virt-manager
is the package that also installed dbus)

Sven.

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/5145988D...@web.de

[Bob Proulx]

Sven Uhlig wrote:
> Bob Proulx wrote:
> > getent baldur.asgard
>
> That is why I used C's getnameinfo().
>
> How should getent work?
>
> # getent baldur.asgard
> Unknown database: baldur.asgard

Sorry. That was a bad example on my part. The first parameter is the
map name and the second is the key to look up in it.

getent hosts baldur.asgard

Other uses are for looking up passwd, group, aliases, and so forth.
Here are some additional examples of usage.

$ getent aliases root
root: b...@proulx.com

$ getent passwd rwp
rwp:x:1000:1000:Bob Proulx:/home/bob:/bin/bash

$ getent group staff
staff:x:50:rwp

$ getent hosts www.example.com
2001:500:88:200::10 www.example.com

IPv6. I guess I should have specified one of these:

$ getent ahosts www.example.com
192.0.43.10 STREAM www.example.com
192.0.43.10 DGRAM
192.0.43.10 RAW
2001:500:88:200::10 STREAM
2001:500:88:200::10 DGRAM
2001:500:88:200::10 RAW

$ getent ahostsv4 www.example.com
192.0.43.10 STREAM 43-10.any.icann.org
192.0.43.10 DGRAM
192.0.43.10 RAW

$ getent ahostsv6 www.example.com
2001:500:88:200::10 STREAM www.example.com
2001:500:88:200::10 DGRAM
2001:500:88:200::10 RAW

For just normal use I prefer the bind9-host command version of host
for the most friendly lookup format.

$ host www.example.com
www.example.com has address 192.0.43.10
www.example.com has IPv6 address 2001:500:88:200::10

$ host -t a www.example.com
www.example.com has address 192.0.43.10

> Nevermind, my problem is solved, see mail by Clive Standbridge. :)

Yay!

Bob