how to show emergency pop up message to user? (on X)
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
One of the biggest bothers for me is that when I go
su -
on the CLI that then I cannot start GUI tools anymore, "cannot open display", without giving Root permission.
What sense does that make? None!
You need to use kdesu GUItoolname (for KDE) or gtksu GUItoolname (if using Gnome).
I have not tried the last post before this one, but xhost + so far has given me hard trouble. It always tells me "cannot open display". xhost is not a graphical application, it does not use or open a display, it sets permissions. Is there a bug in there? Why does it tell me "cannot open display" when I use it with "give permission to all"?
You may be having your remote connection refused. Many distros also set the xserver to ignore tcp connections by default. This has to be re-enabled before remote displays will work. It may vary between distros, but at the very least you may have to remove the "--nolisten tcp" line from /etc/X11/xinit/xserverrc or a similar file to allow it access.
(note, the following contains details of my experience that may or may not be useful to you, but could help some people out.)
I know this because I recently had a b**** of a time getting desktop sharing to work between my two systems. On my system I discovered that in addition to modifying xserverrc that I also had to change my /etc/kde3/kdm/kdmrc to comment out the line "ServerArgsLocal=-nolisten tcp". So far so good.
But this is where it got difficult. It seems that the freedesktop standard (I believe) doesn't look at the /etc version of kdmrc directly, but copies it on startup to /var/run for actual use from there. Unfortunately there was (still is?) some bug in the genkdmconf program that does the copying that forced it to alway generate a new default kdmrc instead of copying my modified one. I tried all sorts of things to get around it, but I finally had to resort to using brute force. I found the line in my /etc/init.d/kdm file that runs genkdmconf, and then simply added a line right after it to manually copy the correct kdmrc after genkdmconf did it's work. I know it's a dirty hack, but it did the job.
PS: note that when you do get x sharing working that it's advisable to limit your xhost permissions to only the systems you want to connect. Even better would be to set up a proper xauthority handshake, as described here.
That's because I accidentally left out a bit. Try it like this:
Code:
root@laptop:~# xmessage test
Error: Can't open display:
root@laptop:~# xhost +
xhost: unable to open display ""
root@laptop:~# export DISPLAY=:0.0
root@laptop:~# su -c "xhost +" testuser
access control disabled, clients can connect from any host
root@laptop:~# xmessage test
root@laptop:~# su -c "xhost +" testuser
access control enabled, only authorized clients can connect
root@laptop:~# exit
xit
Only the user who owns the display has permission to alter xhost access control. Hence the error messages. As root, however, you can run xhost as the user that owns the display, and so make it work. (that's the su -c command) Hopefully this works this time. Don't forget to set which display you wish to alter.
Well another way to do things would be to create your own client that is installed on the machine that listens on a port via TCP. It can receive messages and display them if necessary.
This has to be re-enabled before remote displays will work. It may vary between distros, but at the very least you may have to remove the "--nolisten tcp" line from /etc/X11/xinit/xserverrc or a similar file to allow it access.
PS: note that when you do get x sharing working that it's advisable to limit your xhost permissions to only the systems you want to connect. Even better would be to set up a proper xauthority handshake, as described here.[/QUOTE]
We are all talking about (well at least I am) local access here, not connecting from another machine. I am sitting at the machine and want access to it and cannot get it with root. Switching to root with su - and then getting blocked from using the session for any X program. xhost + should at least work in this context. It is a program to give access (local to remote or local to local) not require access to a screen to run itself. (how can you ever give access then, when you need a key to use the key to unlook a lock?)
Xserver sharing in any case is a tough cookie. Does it really need to be THAT complicated and cryptic?
That's because I accidentally left out a bit. Try it like this:
Code:
root@laptop:~# xmessage test
Error: Can't open display:
root@laptop:~# xhost +
xhost: unable to open display ""
root@laptop:~# export DISPLAY=:0.0
root@laptop:~# su -c "xhost +" testuser
access control disabled, clients can connect from any host
root@laptop:~# xmessage test
root@laptop:~# su -c "xhost +" testuser
access control enabled, only authorized clients can connect
root@laptop:~# exit
xit
Only the user who owns the display has permission to alter xhost access control. Hence the error messages. As root, however, you can run xhost as the user that owns the display, and so make it work. (that's the su -c command) Hopefully this works this time. Don't forget to set which display you wish to alter.
Thanks for the elaboration. But heck, it gets worse, now not even root has rights to give permission. Any permission MUST be available to root. This affair as it is right now is as absurd as the kernel not be able to access the display or some other aspect of the system. How the heck are you supposed to administrate a system, if you cannot do it with code running with root. I definitely have to find a way that you can enable root as superuser for all X sessions, even permission giving.
I found a solution that will work, it is a little unwieldy (you have to add it to every users .bashrc) but it seems to work:
add this line to a users .bashrc:
xhost +local:root
this gives the user root access to the users xsession.
in the root .bashrc you then have to add
export DISPLAY=:0.0
because without this, it will still fail because root does not seem to be on the same xscreen as the user ;-) *grin*
I think the Xserver could benefit from a thorough total redesign. It is very old and many structures don't fit the nowadays requirements very much anymore. And that comment is not just about permissions.
Hmmmm, but will that actually do what the OP wants? It looks like the script is running as the user that is logged in and the crux of the OP's probably is to being able to run the command as root.
The OP probably isn't paying attention any more, but in case they are and since the thread has aleady been revived, I think this is the, at least a, solution which doesn't involve adding anything to anyone's .bashrc
If run as root that should put up a notification that the person who is logged in to the machine with an X session can see. It is taken from a script I use in a production environment. I assumes that the user's xauthority file is somewhere that root can access it, rather than in say an NFS mounted home directory with root squash applied.
#!/bin/sh
export DISPLAY=:0.0
title=$1
text=$2
timeout=$3
pids=`pidof notification-daemon`
#echo $pids
if [ -z "$title" ]; then
echo You need to give me a title >&2
exit 1
fi
if [ -z "$text" ]; then
text=$title
fi
if [ -z "$timeout" ]; then
timeout=60000
fi
for pid in $pids; do
# find DBUS session bus for this session
DBUS_SESSION_BUS_ADDRESS=`grep -z DBUS_SESSION_BUS_ADDRESS \
/proc/$pid/environ | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'`
UNAME=`grep -z USERNAME \
/proc/$pid/environ | sed -e 's/USERNAME=//'`
DISP=`grep -z DISPLAY \
/proc/$pid/environ | sed -e 's/DISPLAY=//'`
XAUTH=`grep -z XAUTHORITY \
/proc/$pid/environ | sed -e 's/XAUTHORITY=//'`
# echo $UNAME $DBUS_SESSION_BUS_ADDRESS $DISP $XAUTH
# use it
DISPLAY=$DISP \
DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS \
XAUTHORITY=$XAUTH \
su $UNAME -c "notify-send -u critical -t $timeout '$title' '$text'"
done
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.