Cannot connect to X server :0.0 as superuser

Question

I'm quite new to Android development. My understanding is that you can create several versions of the same image with different sizes and put them into the folders drawable-ldpi, drawable-mdpi, drawable-hdpi.

It seems obvious to me that you can handle this problem "the lazy way" by just resizing one image depending on the device's pixel density. For this I programmatically find out what density the device has, like ldpi. The implementation itself is not the problem. I'm just afraid of any drawbacks (that prevent me later from running the app on different devices).

So, are there any (major) drawbacks of scaling images automatically ?

In which of the three folders do I put the image so that the compiler can find it?

Solution 1

An X program needs two pieces of information in order to connect to an X display.

• It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.

• It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.

See Open a window on a remote X display (why "Cannot open display")? for more details.

In your case, DISPLAY is set but programs evidently cannot find the cookie file. Check the value of XAUTHORITY in your session and under su.

If XAUTHORITY is not set in your session and su sets the HOME environment variable to root's home directory, then you need to set XAUTHORITY to /home/msz/.Xauthority where /home/msz is your home directory.

If su removes XAUTHORITY from the environment, either put it back, or configure su not to do this.

If your home directory is on some filesystems like NFS, root may not be able to read it directly. In that case, you can copy the .Xauthority file to a different location on a non-NFS filesystem:

XAUTHORITY_COPY=$(umask 077; mktemp)
cat "${XAUTHORITY:-~/.Xauthority}" "$XAUTHORITY_COPY"
XAUTHORITY="$XAUTHORITY_COPY" su
rm "$XAUTHORITY_COPY"
unset XAUTHORITY_COPY

Solution 2

You are running xhost as root !

run xhost as the normal user xhost + , then become root then try again.

btw as others have pointed out xhost + permits any user from any host

Comments

[41754]

This is a classic. You may do export $(dbus-launch) or use xhost [+] to be able to launch programs using X and your superuser account.

[R. Sharma]

Did both , see the edit above

[41754]

It may be $ xhost to see the current access and $ xhost + to enable access from any host. You often do this from a virtual terminal you know for sure that can spawn programs using X.

[Bananguin]

@galegosimpatico: why would launching a dbus server solve this issue?

[Bananguin]

When you are not superuser, what does echo $DISPLAY show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for example ps faux)

[41754]

@Bananguin The dbus relaunch from a terminal works around X connection problems in some versions of Debian. But it's true that this users' prompt hints the use of a non Debian family GNU/Linux distribution (maybe Fedora?).

[R. Sharma]

@Bananguin: i am getting :0.0, when i give echo $DISPLAY

[R. Sharma]

@Bananguin: but i could not understand second part of your question.

[kmacdonald]

IIRC, xhost should be run from inside the X server as the user who is running the X session. Is that root as well?

[Jenny D]

Using xhost + is the equivalent of "opening a huge security hole big enough for anyone to drive a bus through".

[Gilles 'SO- stop being evil']

@galegosimpatico No, neither of these will help. (xhost + might on some setups, but if it does, you don't want to use it: it means “allow anybody to do anything with my account”.)

[41754]

Oh yeah, running xhost + exposes root and user login passwords as long as samba passwords. And God kills 314 kittens too.

[RolandK]

Thanks. I didn't expect image quality to drop when shrinking. I also didn't know that you can have a generic drawable folder besides the density-specific ones.

[Gilles 'SO- stop being evil']

Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +!

[X Tian]

Understand, that's a good point. Thanks for your advice.

[Can Geliş]

I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~

[pbhj]

XAUTHORITY for me was set as a file that no longer existed: