Mint 12: synaptic package manager error

Question

Yesterday I had the same issue, I solved it by running

sudo synaptic

But today I don't know what's happening, if I run gksu synaptic or gksudo synaptic they don't do anything.

If I go to root and execute these commands or execute sudo synaptic, I see:

sudo synaptic
No protocol specified

(synaptic:32377): Gtk-WARNING **: cannot open display: :0.0

EDIT: @Nunoxic

I'm working on my local computer. When I do sudo apt-get update some stuff will be updated and some some stuff will not be updated

E: Some index files failed to download. They have been ignored, or old ones used instead.

I ran sudo apt-get update 2 days ago. when i do echo $DISPLAY the output is :0

@Gilles

the output of echo $XAUTHORITY is nothing at all:)

the output of sudo env | sort is

COLORTERM=gnome-terminal
DISPLAY=:0.0
HOME=/root
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_COLLATE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LOGNAME=root
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
SHELL=/bin/bash
SUDO_COMMAND=/usr/bin/env
SUDO_GID=0
SUDO_UID=0
SUDO_USER=root
TERM=xterm
USERNAME=root
USER=root

the output of sudo xterm is

No protocol specified
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s

EDIT

the output of XAUTHORITY=~/.Xauthority; sudo xterm is

No protocol specified
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s

the output of sudo -s9999 strace xterm is

sudo: invalid option -- '9'
usage: sudo -h | -K | -k | -L | -V
usage: sudo -v [-AknS] [-g groupname|#gid] [-p prompt] [-u user name|#uid]
usage: sudo -l[l] [-AknS] [-g groupname|#gid] [-p prompt] [-U user name] [-u
            user name|#uid] [-g groupname|#gid] [command]
usage: sudo [-AbEHknPS] [-C fd] [-g groupname|#gid] [-p prompt] [-u user
            name|#uid] [-g groupname|#gid] [VAR=value] [-i|-s] [<command>]
usage: sudo -e [-AknS] [-C fd] [-g groupname|#gid] [-p prompt] [-u user
            name|#uid] file ...

Answer 1

One possible explanation is that due to some recent change the location of the X cookie file has changed from ~/.Xauthority to some location indicated by $XAUTHORITY. The X cookie file contains a password that X applications must provide when connected to the X server. (See the first part of this answer for more background.)

Make sure that the XAUTHORITY variable is not erased by sudo. Run visudo to add this line to the sudoers file:

Defaults env_keep += XAUTHORITY

A related possibility is that if you don't have XAUTHORITY in your environment, the X cookie is stored in ~/.Xauthority. If the HOME environment variable is not preserved by sudo, then the X applications running under sudo will look in ~root/.Xauthority which doesn't have the right cookie. There are three easy ways to solve this, from most convenient to less convenient:

• Turn off the env_reset option in sudoers (when you can run arbitrary commands as the target user, there is no real security benefit to env_reset), and don't turn on set_home. This way, ~/.Xauthority under sudo still refers to the calling user's home directory.
• Tell sudo to preserve the XAUTHORITY variable as above, and set XAUTHORITY in your X session startup file, even if it's the default value.

• Set XAUTHORITY using the home directory of the calling user inside the sudo session, e.g. by running

  sudo env XAUTHORITY=${XAUTHORITY:-~/.Xauthority} xterm