Bug #6389

Vidalia fails to show up on some hardware

Added by alant 2013-10-29 06:19:02 . Updated 2013-12-11 08:13:48 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Start date:
2013-10-29
Due date:
% Done:

0%

Feature Branch:
bugfix/vidalia_fails_to_start
Type of work:
Code
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

An user reported that Vidalia fails to show up when they boot Tails
0.21 on USB.

I was able to reproduce this issue while booting 0.21 from an USB stick
created by the Tails Installer on some hardware. I have a combination
of {USB stick, computer} that allows me to reproduce the bug every time.

This is the output of restart-vidalia run with `set -x` when the issue
appears:

+ ARGS=
+ grep -qw bridge /proc/cmdline
+ . /etc/live/config.d/username.conf
+ LIVE_USERNAME=amnesia
+ . /etc/default/locale
+ LANG=fr_FR.UTF-8
+ killall vidalia
+ pgrep -u amnesia nm-applet
+ export LANG
+ export DISPLAY=:0.0
+ echo /var/run/gdm3/auth-for-amnesia-G9HRGm/database
+ export XAUTHORITY=/var/run/gdm3/auth-for-amnesia-G9HRGm/database
+ sudo -u amnesia xhost +SI:localuser:vidalia
+ pgrep -u vidalia vidalia
+ sudo -u vidalia lckdo /var/lock/vidalia vidalia -DISPLAY=:0.0 -loglevel debug
+ sleep 5
+ pgrep -u vidalia vidalia
+ sudo -u amnesia xhost -SI:localuser:vidalia
No protocol specified
vidalia: cannot connect to X server :0.0

My conclusion: there is a race condition between vidalia trying to
connect to X and the removal of xhost access to X. In some cases, xhost
is denied access to the vidalia user before vidalia actually tried to
connect to X.

The following quick and dirty patch on restart-vidalia fixes the issue
for me:

 sudo -u ${LIVE_USERNAME} xhost +SI:localuser:vidalia
 sudo -u vidalia lckdo /var/lock/vidalia vidalia -DISPLAY=${DISPLAY}
 ${ARGS} & until pgrep -u vidalia vidalia >/dev/null ; do
    sleep 5
 done
+sleep 5
 sudo -u ${LIVE_USERNAME} xhost -SI:localuser:vidalia

Subtasks


History

#1 Updated by intrigeri 2013-10-29 08:03:42

  • Priority changed from Normal to Elevated

Raising priority as this is a regression.

#2 Updated by sajolida 2013-11-03 02:17:03

One line command to apply this patch. It requires to set an administration password:

sudo sed -ir '/done$/N;s/done\nsudo/done\nsleep 5\nsudo/' usr/local/sbin/restart-vidalia

Then disconnect and reconnect from the network to restart Vidalia.

#3 Updated by alant 2013-11-08 14:17:26

  • Assignee set to alant

The intelligent way to solve this issue would be to wait for vidalia to connect to X.

However, `xlsclients` returns ‘’ for Vidalia unless one click on its icon. I found no way to display the client pid.

The following python script does the trick:

import os
import Xlib
import Xlib.display

display_name = os.environ['DISPLAY']
display = Xlib.display.Display(display_name)
root_win = display.screen().root

pids = set()
for win in root_win.query_tree().children:
    wm_pid_prop = win.get_property(display.intern_atom("_NET_WM_PID", True), Xlib.Xatom.CARDINAL, 0, 1024)
    if wm_pid_prop:
        pids.add(wm_pid_prop.value[0])

pids = list(pids)
pids.sort()
for pid in pids:
    print("%i" % pid)

#4 Updated by mercedes508 2013-11-09 10:11:53

When using a Tails from a DVD, there’s a workaround.

At boot menu, press ‘tab’.
Delete commands ‘splash quiet’ and add ‘toram’. Press Enter.

#5 Updated by intrigeri 2013-11-09 11:43:03

> Delete commands ‘splash quiet’

FTR, this part is useless.

#6 Updated by mercedes508 2013-11-15 09:37:45

An easier workaround (tested in a VM and on bare metal from USB) is to disconnect (either WiFi or Ethernet), wait for NetworkManager to notice that connection has been lost, and then reconnect. Vidalia should then start properly.

#7 Updated by alant 2013-11-22 03:54:06

  • Assignee deleted (alant)
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/vidalia_fails_to_start

As discussed on tails-dev (cf https://mailman.boum.org/pipermail/tails-dev/2013-November/004180.html) let’s start with an easier fix: close xauth after vidalia exits.

#8 Updated by intrigeri 2013-11-22 04:30:41

  • Assignee set to intrigeri

#9 Updated by intrigeri 2013-11-22 04:31:38

> Assignee deleted (alant)
> QA Check set to Ready for QA

Please reassign to the current RM, or to someone who volunteered to do
reviews during this cycle, when proposing something for merging.
Thanks in advance :)

#10 Updated by intrigeri 2013-11-22 12:51:06

  • Status changed from Confirmed to Fix committed
  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

Pending for 0.22.

#11 Updated by intrigeri 2013-12-11 08:13:49

  • Status changed from Fix committed to Resolved

Fixed in 0.22.