Revivir un servidor X11 atascado mientras se mantienen las aplicaciones GUI ejecutándose


2

He estado ejecutando un servidor X durante varios días. Hoy, debido a algún error transitorio, está colgado. La multitud de aplicaciones X (editores de texto, navegador web, aplicaciones de gráficos, etc.) todavía se están ejecutando y probablemente estén bien. El servidor X parece haber salido mal.

Puedo iniciar un nuevo servidor x en otra terminal virtual: ctrl-alt-F1, ctrl-alt-F2, etc. El muerto original está en ctrl-alt-F1, e informaría DISPLAY =: 0 si pudiera hacer algo . Empecé unos nuevos en ctrl-alt-F2 donde DISPLAY =: 1 y ctrl-alt-F3 donde DISPLAY =: 2.

Hasta este evento de hoy, no sabía que Linux podía ejecutar más de un servidor X a la vez, y tenerlos asociados con vterms como este. Antes, siempre era F7 el que tenía el servidor X, o F5 hace muchos años. Estoy usando Arch Linux, instalado recientemente hace aproximadamente un mes. No me mantengo al día con las novedades de X11 o Linux.

PREGUNTA: el servidor F1 original muestra solo una pantalla negra con un cursor. El cursor se mueve. Pero las aplicaciones, que aparecen en "ps aux" y dan otras señales de vida además de su GUI, estoy seguro de que todavía se están ejecutando.

PREGUNTA: ¿hay alguna forma de darle una patada al servidor F1 X11, para despertarlo, despegarlo, reiniciarlo y hacer que vuelva a funcionar? Sin perder los procesos GUI existentes, por supuesto.

Si no, la siguiente pregunta es cómo mover un proceso en ejecución, como GIMP, Kwrite, etc., para que no aparezca en el servidor DISPLAY =: 0 X para que esté completamente presente y funcional en el servidor: 2. Pero esa es una pregunta separada, y se ha preguntado en otra parte. Sin embargo, antes de intentar simular eso, me gustaría ver si puedo revivir el servidor X original.

Respuestas:


3

Si su servidor X está atascado, no hay mucho que pueda hacer. Su única apuesta es eliminar las aplicaciones con la esperanza de que la que se congeló (como un juego 3D atrapado en un bucle infinito que acapara el servidor) libera los recursos y comienza a funcionar nuevamente. También puede ser el administrador de composición si usa uno para poder matarlo y reiniciarlo y ver si ayuda (la mayoría de los DE modernos lo hacen, y si usa Gnome, matar el shell matará toda su sesión). Sin embargo, es más probable que el servidor sea irrecuperable a menos que desee profundizar en él con gdb (no estaría preguntando aquí si pudiera).

Pasando a la siguiente pregunta, estoy bastante seguro de que tampoco es posible mover aplicaciones de un servidor X a otro:

  • Las aplicaciones GUI generalmente tienen más que solo la conexión al servidor X. Pueden tener varios otros recursos adjuntos, incluidos algunos vinculados a la tarjeta gráfica. Por ejemplo: contextos OpenGL. Está intentando mover una aplicación desde dos servidores locales, pero X11 es en realidad un protocolo de red. El servidor X de destino también podría estar en el lado opuesto del mundo con hardware diferente y todo.

  • La mayoría de las aplicaciones no planean perder la conexión con el servidor X. Todavía tengo que encontrar alguna aplicación que incluso maneje una conexión perdida con el servidor: la mayoría de las aplicaciones simplemente se bloquean.

  • Mover una aplicación de un servidor X a otro rompería muchas suposiciones que las aplicaciones hacen al inicio, particularmente sobre lo que tienen disponible (versiones OpenGL, versión X, extensiones). Manejar todos esos casos extremos simplemente no vale la pena.

  • No se espera que Xorg se bloquee, de la misma manera que las aplicaciones no esperan que el núcleo muera o se rompa.

De hecho, hay formas de mover ventanas de un servidor X a otro, pero implica usar un proxy X11 como Xdmx . Es el único que pude encontrar, no actualizado desde 2004 y tiene algunos problemas. No contaría con eso para un trabajo real.

Simplemente matar a Xorg y reiniciar es probablemente su mejor solución. ¡Solo recuerda guardar tu trabajo con frecuencia!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.