Bug #6389
Vidalia fails to show up on some hardware
0%
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 ‘
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.