Skip to main content
systemctl --user show-environment
Source Link
mviereck
  • 2.6k
  • 1
  • 21
  • 18

Not a full answer, but may help a bitOn distributions with init system systemd the output of

systemctl --user show-environment 

shows DISPLAY and XAUTHORITY. This is at least true for my debian 9 system with systemd and gdm3 as display manager.

Pitfall: After running startx xterm -- :2 vt2 on tty2 systemctl gave me DISPLAY and XAUTHORITY from the new display; my main display :0 was no longer observably this way.


Other approaches:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.
  • It may be a remote session without local Xorg at all.

Normally Xorg commands also contain the display number. Unfortunately, mine does not:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

-displayfd 3 somehow points to DISPLAY. If looking as root at /proc/$(pidof Xorg)/fd/3 I find

 lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437] 

Though, I don't know how to look for socket 21437. I am sure it points to /tmp/.X11-unix/X0. One approach is lsof +E -aUc Xorg that shows interesting output: many connections containing @/tmp/.X11-unix/X0 and one dbus connection.

A bit dirty: The fd folder also shows me

l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log 

Xorg.0.log is a clear indication for display :0.


Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how. That may be the cleanest and most portable way, if at least a dbus daemon is running.

Not a full answer, but may help a bit:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.
  • It may be a remote session without local Xorg at all.

Normally Xorg commands also contain the display number. Unfortunately, mine does not:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

-displayfd 3 somehow points to DISPLAY. If looking as root at /proc/$(pidof Xorg)/fd/3 I find

 lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437] 

Though, I don't know how to look for socket 21437. I am sure it points to /tmp/.X11-unix/X0. One approach is lsof +E -aUc Xorg that shows interesting output: many connections containing @/tmp/.X11-unix/X0 and one dbus connection.

A bit dirty: The fd folder also shows me

l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log 

Xorg.0.log is a clear indication for display :0.


Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how. That may be the cleanest and most portable way, if at least a dbus daemon is running.

On distributions with init system systemd the output of

systemctl --user show-environment 

shows DISPLAY and XAUTHORITY. This is at least true for my debian 9 system with systemd and gdm3 as display manager.

Pitfall: After running startx xterm -- :2 vt2 on tty2 systemctl gave me DISPLAY and XAUTHORITY from the new display; my main display :0 was no longer observably this way.


Other approaches:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.
  • It may be a remote session without local Xorg at all.

Normally Xorg commands also contain the display number. Unfortunately, mine does not:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

-displayfd 3 somehow points to DISPLAY. If looking as root at /proc/$(pidof Xorg)/fd/3 I find

 lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437] 

Though, I don't know how to look for socket 21437. I am sure it points to /tmp/.X11-unix/X0. One approach is lsof +E -aUc Xorg that shows interesting output: many connections containing @/tmp/.X11-unix/X0 and one dbus connection.

A bit dirty: The fd folder also shows me

l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log 

Xorg.0.log is a clear indication for display :0.


Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how. That may be the cleanest and most portable way, if at least a dbus daemon is running.

lsof -i -a -p $PID
Source Link
mviereck
  • 2.6k
  • 1
  • 21
  • 18

Not a full answer, but may help a bit:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.
  • It may be a remote session without local Xorg at all.

Normally Xorg commands also contain the display number. Unfortunately, mine does not:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

-displayfd 3 somehow points to DISPLAY. If looking as root at /proc/$(pidof Xorg)/fd/3 I find

 lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437] 

Though, I don't know wherehow to look for socket 21437. I am sure it points to /tmp/.X11-unix/X0. One approach is lsof +E -aUc Xorg that shows interesting output: many connections containing @/tmp/.X11-unix/X0 and one dbus connection.

A bit dirty: The fd folder also shows me

l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log 

Xorg.0.log is a clear indication for display :0.


Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how. That may be the cleanest and most portable way, if at least a dbus daemon is running.

Not a full answer, but may help a bit:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.

Normally Xorg commands also contain the display number. Unfortunately, mine does not:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

-displayfd 3 somehow points to DISPLAY. If looking as root at /proc/$(pidof Xorg)/fd/3 I find

 lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437] 

Though, I don't know where to look for socket 21437. I am sure it points to /tmp/.X11-unix/X0.

A bit dirty: The fd folder also shows me

l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log 

Xorg.0.log is a clear indication for display :0.


Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how.

Not a full answer, but may help a bit:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.
  • It may be a remote session without local Xorg at all.

Normally Xorg commands also contain the display number. Unfortunately, mine does not:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

-displayfd 3 somehow points to DISPLAY. If looking as root at /proc/$(pidof Xorg)/fd/3 I find

 lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437] 

Though, I don't know how to look for socket 21437. I am sure it points to /tmp/.X11-unix/X0. One approach is lsof +E -aUc Xorg that shows interesting output: many connections containing @/tmp/.X11-unix/X0 and one dbus connection.

A bit dirty: The fd folder also shows me

l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log 

Xorg.0.log is a clear indication for display :0.


Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how. That may be the cleanest and most portable way, if at least a dbus daemon is running.

follow -displayfd 3
Source Link
mviereck
  • 2.6k
  • 1
  • 21
  • 18

Not a full answer, but may help a bit:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.

Normally Xorg commands also contain the display number. Unfortunately, mine does not. I assume -displayfd 3 somehow points to DISPLAY:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

-displayfd 3 somehow points to DISPLAY. If looking as root at /proc/$(pidof Xorg)/fd/3 I find

 lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437] 

Though, I don't know where to look for socket 21437. I am sure it points to /tmp/.X11-unix/X0.

A bit dirty: The fd folder also shows me

l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log 

Xorg.0.log is a clear indication for display :0.


Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how.

Not a full answer, but may help a bit:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.

Normally Xorg commands also contain the display number. Unfortunately, mine does not. I assume -displayfd 3 somehow points to DISPLAY:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how.

Not a full answer, but may help a bit:

At least for XAUTHORITY it is more reliable to parse the output of ps aux | grep Xorg and look for option -auth. In my case it is located at /run/user/1000/gdm/Xauthority and not at ~/.Xauthority.

Pitfalls:

  • There can be more than one Xorg instance.
  • Instead of Xorg there can be Xwayland.
  • Instead of Xorg there can be Xvfb or something else.

Normally Xorg commands also contain the display number. Unfortunately, mine does not:

/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 

-displayfd 3 somehow points to DISPLAY. If looking as root at /proc/$(pidof Xorg)/fd/3 I find

 lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437] 

Though, I don't know where to look for socket 21437. I am sure it points to /tmp/.X11-unix/X0.

A bit dirty: The fd folder also shows me

l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log 

Xorg.0.log is a clear indication for display :0.


Another approach: notify-send seems to gather DISPLAY and XAUTHORITY with some dbus magic. But I have no clue how.

dbus clue
Source Link
mviereck
  • 2.6k
  • 1
  • 21
  • 18
Loading
Source Link
mviereck
  • 2.6k
  • 1
  • 21
  • 18
Loading