Por que o gnome-session trava minha sessão do TightVNC e como posso consertá-la? [fechadas]

3

Estou executando o Ubuntu 9.10 x64, com o estoque tightvncserver (1.3.9).

Quando inicio o tightvncserver, posso me conectar ao cliente tightvnc do windows e obter a área de trabalho vazia com um único terminal. Quando eu tento iniciar o gnome-session ele cai rapidamente.

As últimas linhas no log tightvncserver são:

01/09/10 10:53:18 Got connection from client 192.168.1.31
01/09/10 10:53:18 Using protocol version 3.8
01/09/10 10:53:18 Enabling TightVNC protocol extensions
01/09/10 10:53:20 Full-control authentication passed by 192.168.1.31
01/09/10 10:53:20 Pixel format for client 192.168.1.31:
01/09/10 10:53:20   32 bpp, depth 24, little endian
01/09/10 10:53:20   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
01/09/10 10:53:20   no translation needed
01/09/10 10:53:20 Using tight encoding for client 192.168.1.31
01/09/10 10:53:20 rfbProcessClientNormalMessage: ignoring unknown encoding 8
01/09/10 10:53:20 Enabling X-style cursor updates for client 192.168.1.31
01/09/10 10:53:20 Enabling cursor position updates for client 192.168.1.31
01/09/10 10:53:20 Using image quality level 6 for client 192.168.1.31
01/09/10 10:53:20 Enabling LastRect protocol extension for client 192.168.1.31
01/09/10 10:53:20 rfbProcessClientNormalMessage: ignoring unknown encoding -223
xterm:  fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":3.0"

A saída do gnome-session (obtida da saída gnome-session | tee) é:

GNOME_KEYRING_SOCKET=/tmp/keyring-mUVFSj/socket
SSH_AUTH_SOCK=/tmp/keyring-mUVFSj/socket.ssh
GNOME_KEYRING_PID=2783
** (<unknown>:2779): DEBUG: Client registered with session manager: /org/gnome/SessionManager/Client2
Checking for Xgl: not present.
xset q doesn't reveal the location of the log file. Using fallback /var/log/Xorg.0.log
Detected PCI ID for VGA:
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: not present.
aborting and using fallback: /usr/bin/metacity

Eu verifiquei o /var/log/Xorg.0.log, mas isso não contém nada pertinente à sessão do vnc.

Atualmente, estou usando o tightvncserver com sucesso em outros sistemas 9.10. O sistema que exibe o problema não difere de meus outros sistemas de trabalho de qualquer forma que pareça significativo para mim.

O que eu gostaria de saber é:

  1. O que devo fazer para descobrir mais informações sobre o que está falhando
  2. O que está causando o acidente
  3. Como posso corrigir isso?
por adante 01.09.2010 / 03:08

2 respostas

2

Para responder especificamente ao diagnóstico do seu problema, o primeiro passo seria ativar o relatório de falhas do apport no sistema e tente reproduzir a falha. Uma vez que você tenha causado o travamento do TightVNC novamente, se for o tipo de travamento a ser travado, um relatório de falha deve ter aparecido em / var / crash. Você deve ser capaz de apontar o bug do Ubuntu no arquivo de relatório de falha para que ele envie um relatório de bug para o launchpad.

Dito isso, passei por vários servidores vnc, procurando usar um da maneira que você descreve, como uma sessão separada, em vez de duplicar uma área de trabalho em execução. Pelo que me lembro, tightvncserver caiu muito em mim, e com base nos erros de launchpad para o pacote , parece que algumas outras pessoas veem a mesma coisa.

Acabei usando o vnc4server ,quefuncionoumuitobemparamimemvárioslançamentos.Ditoisso,nomaverick,estousendomordidopelo bug 655886 ao usar um gnome sessão, por isso não é perfeito.

    
por Steve Beattie 09.11.2010 / 06:33
1

Eu tive muitos problemas ao usar o tightvnc quando os efeitos da área de trabalho estão habilitados (por exemplo, compiz). Tente desabilitar o compiz e veja se isso resolve seu problema. Você pode desativá-lo via Sistema - > Preferências - > Aparência e, em seguida, selecionando a guia Efeitos visuais (selecione "Nenhum").

Se isso não te ajudar, você provavelmente terá que executar o gnome-session usando a ferramenta strace. Isto irá mostrar todas as chamadas do sistema que o gnome-session está rodando e esperançosamente dará uma indicação de qual delas está causando problemas.

    
por Jason 01.09.2010 / 03:58

Tags