¿Cómo verificar si el servidor X se está ejecutando?

¿Hay alguna forma de averiguar si el usuario de la sesión actual está ejecutando un servidor X (en Linux)?¿Cómo verificar si el servidor X se está ejecutando?

Me'v comenzó con cosas como:

ps -e | grep X

pero esto no funciona siempre

y una cosa más trataba está comprobando la variable de $DISPLAY

¿Hay alguna otra formas de verificar esto?

EDIT: Algunas personas sugirieron usar las variables $ DISPLAY, pero ¿qué pasa si el usuario juguetea con esta variable? ¿Qué pasa si él trata de hacer algo y cambia esta variable y luego cuando la reviso, ya no refleja un estado preciso del sistema? ¿No hay una forma específica de hacer esto que siempre devolverá una respuesta correcta?

He descubierto que se puede hacer mediante programación de este modo:

#include <X11/Xlib.h> 
int main() 
    { exit(XOpenDisplay(NULL) ? 0 : 1); } 

$ gcc -o xprobe xprobe.c -L/usr/X11R6/lib -lX11

pero estoy buscando una manera de guión.

Fuente

2009-03-12 Roman M

por qué no "ps -e | grep X "¿siempre funciona? – stephendl

¿Y por qué no funciona $ DISPLAY? –

@stephendl: Encontré que en algunas situaciones X se está ejecutando pero el usuario está conectado a través de un terminal sin X @matthew: ¿Qué pasa si el usuario juega con esta variable y ya no refleja el estado real del sistema? –

utilizo

pidof X && echo "yup X server is running"

pgrep y $ DISPLAY otras opciones.

Otras consideraciones:

Su y no se establecerán $ DISPLAY. Las cosas que cambian el entorno del programa en ejecución pueden hacer que esto no funcione.

No recomiendo ps -e | grep X ya que este buscará procX, que no es el servidor X.

Fuente

2009-03-12 01:23:55

¿No es esto lo mismo que ps? e | grep X? AFAIK pidof solo un alias para killall5 y no siempre está definido en todos los sistemas –

Ver mi respuesta actualizada. –

De hombre pidof: "pidof es en realidad el mismo programa que killall5; el programa se comporta de acuerdo con el nombre con el que se llama. " pidof se comporta de manera diferente que killall5. Si utiliza un viejo sistema unix antiguo, puede no estar allí. –

$ DISPLAY es la forma estándar. Así es como los usuarios se comunican con los programas sobre qué servidor X usar, si lo hay.

Fuente

2009-03-12 01:38:21 Ken

pero ¿y si el usuario juega con esta variable? ¿Qué pasa si él trata de hacer algo y cambia esta variable y luego, cuando la miro, ya no refleja un estado preciso del sistema. ¿No hay una forma concreta de –

Si configuro $ DISPLAY, es porque quiero que su programa vaya a una pantalla diferente. ¿Cuál es exactamente su caso de uso en el que desea adivinar la configuración explícita del usuario? ¿Evita usar $ HOME en caso de que el usuario "juguetea" con eso, también, ¿dónde termina? – Ken

no quiero adivinar, solo a prueba de balas. El caso de uso es para un instalador de controladores, uno de los requisitos previos es tener x funcionando. Y no evitaría usar $ HOME, pero compruebo que apunta primero a un directorio existente, por si acaso ^^ –

Un truco que utilizo para saber si se está ejecutando X es:

127.0.0.1 telnet 6000

Si se conecta, tiene un servidor X en funcionamiento y su aceptación de las conexiones TCP entrantes (no suelen ser el valor por defecto estos días) ....

Fuente

2009-03-12 01:48:35 dicroce

Supongo que en la actualidad, los sistemas conscientes de la seguridad no tendrían el comando 'telnet' disponible. – boardrider

 
# netstat -lp|grep -i x 
tcp  0  0 *:x11     *:*      LISTEN  2937/X   
tcp6  0  0 [::]:x11    [::]:*     LISTEN  2937/X   
Active UNIX domain sockets (only servers) 
unix 2  [ ACC ]  STREAM  LISTENING  8940  2937/X    @/tmp/.X11-unix/X0 
unix 2  [ ACC ]  STREAM  LISTENING  8941  2937/X    /tmp/.X11-unix/X0 
#

2) nmap

 
# nmap localhost|grep -i x 
6000/tcp open X11 
#

Fuente

2009-03-12 08:53:45

A menudo necesito ejecutar un comando X en un servidor que ejecuta muchos servidores X, por lo que las respuestas basadas en ps no funcionan. Naturalmente, $DISPLAY tiene que ser configurado apropiadamente. Para comprobar que esto es válido, utilice xset q en algún fragmento como:

if ! xset q &>/dev/null; then 
    echo "No X server at \$DISPLAY [$DISPLAY]" >&2 
    exit 1 
fi

Fuente

2012-08-15 07:52:41 bobbogo

Creo que esto es "mejor" que usar 'xprop' y' xdpyinfo' ya que 'xset' produce menos salida para'/dev/null' para comer. El OP debería aceptar esta respuesta. – jamadagni

plazo xdpyinfo y ver si devuelve un cero

Fuente

2013-06-14 15:23:37 shuckc

xprop -root &> /dev/null

...es mi verdadero intento & para probar una situación de "X-able". Y, está casi garantizado que estará en cualquier sistema que ejecute X, por supuesto, el comando falla si no se encuentra de todos modos, por lo que incluso si no existe, puede suponer que tampoco hay X. (Es por eso que uso &> en lugar de>)

Fuente

2014-10-27 15:56:44 osirisgothra

Re '&>' para usar en scripts de shell que se ejecutan bajo 'dash' que no admite' &> ', se puede usar'>/dev/null 2> & 1'. – jamadagni

En cygwin, una forma típica de instalar X es instalar el paquete 'xinit'. Entonces, 'xprop' no se instala automáticamente ya que no es una dependencia. –

Escribí el programa xdpyprobe que está destinado a este fin. A diferencia de xset, xdpyinfo y otras herramientas generales, no realiza ninguna acción adicional (solo comprueba el servidor X y sale) y es posible que no produzca ningún resultado (si se especifica la opción "-q").

Fuente

2016-04-03 05:12:52

Este es un script PHP para verificar.

$xsession = `pidof X`; 
if (!$xsession) { 
    echo "There is no active X session, aborting..\n"; 
    exit; 
}

Comando similar se puede utilizar también en el script de shell. como el comando pidof.

Fuente

2016-10-17 10:21:05 user3607430

En primer lugar es necesario asegurarse de paquetes X11 fundamentales están instalados correctamente en su servidor:

rpm -qa | grep xorg-x11-xauth

Si no, entonces, la amabilidad de instalar todos los paquetes:

sudo yum install xorg-x11-xauth xterm

Asegúrese de que el servidor OpenSSH está configurado para reenviar conexiones x11:

edit file : vim /etc/ssh/sshd_config 

X11Forwarding yes

NOTA: Si esa línea es p retrocedido por un comentario (#) o se establece en no, actualice el archivo para que coincida con el anterior y reinicie el daemon del servidor ssh (tenga cuidado aquí; si cometió un error, puede bloquearlo)

sudo /etc/init.d/sshd restart

Ahora, configurar la aplicación SSH para reenviar las solicitudes de X11:

ssh -Y [email protected]_server.your_domain.com

Fuente

2017-01-25 08:22:05

if [[ $DISPLAY ]]; then 
    … 
fi

Fuente

2017-10-16 20:03:06

¿Cómo verificar si el servidor X se está ejecutando?

Respuesta

Cuestiones relacionadas