Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: GNUser on November 25, 2020, 06:01:55 AM
-
I'm running TCL11 64-bit on an x86_64 laptop. I have Xorg-7.7.tcz and fluxbox.tcz loaded. Also, I use the user=bruno boot command. For the purpose of this exercise (so that two different users are logged in--one in an X session, one in a console), I pressed Ctrl+Alt+F1 and logged in as tc in tty1.
Therefore, in this situation, the "right answers" are that the X11 session's user is bruno and the display happens to be :0.0 . How would a shell script find this information?
To my surprise, if I run the who command in tty1 I don't even see evidence that user bruno is logged in:
tc@box:~$ who
tc tty1 00:00 Nov 25 08:33:42
The last command is similarly unhelpful.
The ps command is not helpful, either, because the X server is started by root and not by bruno:
bruno@box:~$ ps -ef | grep X
6462 root /usr/local/lib/xorg/Xorg -nolisten tcp
17653 bruno grep X
I found this https://unix.stackexchange.com/a/117099 but in TCL Xorg's PPID is 1 so the display manager approach is not going to work.
If X is running then one can assume that the X session's user is "cat /etc/sysconfig/tcuser" and that the display is ":0.0" but I don't want to make assumptions.
So how would a shell script running in TCL find active X11 session's user and display, without making assumptions?
-
Hi, GNUser!
The same mess under Xfbdev. Xfbdev started by tc. then exit from console and login as jb. who in console shows jb only. ps in terminal under X shows jb only, unless they are started by tc.
But ps in console shows all processes, run under X, with correct user - tc.
And ps from X terminal shows the same right data.
Newly started terminal under X is started from tc.
-
But ps in console shows all processes, run under X, with correct user - tc.
Hi, jazzbiker. It would be convenient if GUI applications were children of X (i.e., if GUI apps' PPID were Xorg's PID) but it seems that Xorg has no children.
I need to find a solution that would work even if script were running in the background and not in an X terminal emulator.
-
In my case under Xfbdev newly started terminals are children of my window manager - dwm.
-
Maybe read /etc/sysconfig/desktop and ps | grep it ?
-
Yes, that would give us the GUI user's name (unlike X, the WM/DE runs as regular user). Can we find a more universal (i.e., non-TCL-specific) solution? You'd think that X itself would be able to give us this information.
Once we have the GUI username, you'd think it would be trivial to find that user's display but these do not work:
# su - bruno -c 'echo $DISPLAY'
# su - bruno -c 'env | grep DISPLAY'
-
Hi GNUser
Can multiple users be logged in under Tinycore?
... For the purpose of this exercise (so that two different users are logged in--one in an X session, one in a console), I pressed Ctrl+Alt+F1 and logged in as tc in tty1.
----- Snip -----
To my surprise, if I run the who command in tty1 I don't even see evidence that user bruno is logged in:
tc@box:~$ who
tc tty1 00:00 Nov 25 08:33:42 ...
Now, if you hit Ctrl+Alt+F2 and open a new terminal, does who show bruno is still logged in?
-
Ok, the second in order logged user can't penetrate into the first in order user's environment. You will need separate process inside X which will answer its $DISPLAY into some file (preliminarily opened) in case some signal (USR2?) will be recieved.
-
Hi, Rich!
Isn't it funny?:
tc@box:~$ whoami
tc
tc@box:~$ who
jb tty1 00:11 Nov 25 16:07:39
tc@box:~$
It's citation from within Xfbdev terminal. Probably it is busybox's jokes.
-
Hi, Rich. Yes, it seems multiple users can be logged in.
If I press Ctrl+Alt+F1 and login as tc (for the purposes of demonstration), then press Ctrl+Alt+F2 to return to my desktop, then launch a GUI terminal emulator, here's what I see when I run "who":
bruno@box:~$ who
tc tty1 00:31 Nov 25 09:35:49
bruno pts/0 00:00 Nov 25 10:12:55 :0.0
If I leave that terminal emulator open, then open another one, I get this:
bruno@box:~$ who
tc tty1 00:31 Nov 25 09:35:49
bruno pts/0 00:00 Nov 25 10:12:55 :0.0
bruno pts/1 00:00 Nov 25 10:13:09 :0.0
So it seems that each terminal emulator in X runs a login shell.
-
I can confirm jazzbiker's strange observation.
I created this shell script and bound it to a keyboard shortcut:
#!/bin/sh
who >>/home/bruno/log.txt
echo "" >>/home/bruno/log.txt
whoami >>/home/bruno/log.txt
This is what /home/bruno/log.txt looks like:
tc tty1 00:45 Nov 25 09:35:49
bruno
This is very strange. I know for a fact that I (user "bruno") am using my desktop inside of Xorg running in tty2. Yet "who" does not even see me as being logged in.
-
Hi Hi GNUser
How about:
tc@E310:~$ busybox who -a
tc tty1 00:33 Nov 18 09:43:22
tc pts/0 09:40 Nov 18 09:43:34 :0.0
tc pts/1 11:18 Nov 23 00:22:40 :0.0
tc pts/2 old Nov 18 09:44:27 :0.0
tc pts/3 00:00 Nov 25 10:35:32 :0.0
tc pts/4 ? Nov 24 10:00:36 :0.0
tc pts/5 ? Nov 23 19:42:19 :0.0
tc pts/6 ? Nov 24 09:11:00 :0.0
tc pts/7 ? Nov 24 09:56:31 :0.0
-
Hi, Rich. I get the same output as before.
Try closing all your GUI terminal emulators in your X session (in tty2). Then switch to tty1 and run "busybox who -a" and you'll see that, as far as "who" is concerned, there's nobody logged into tty2.
-
Foe me nothing changed
tc@box:~$ whoami
tc
tc@box:~$ busybox who -a
jb tty1 00:00 Nov 25 16:07:39
tc@box:~$
Xfbdev, dwm, citation from newly openet terminal
-
Jokes continues. X started as tc, then in tty1 tc exited and logined as jb. Then in X opened new terminal:
tc@box:~$ su - jb -c 'echo $DISPLAY'
Password:
tc@box:~$ echo $DISPLAY
:0.0
in tty1
jb@box:~$ echo $DISPLAY
jb@box:~$ su - tc -c 'echo $DISPLAY'
jb@box:~$
tc can acces jb's environment, but jb can't access tc's.
-
Hi, GNUser!
I think You don't need to concentrate on all this "nobody home" who's answer. These are busybox's jokes and they can not decline the fact, that if You start X server it has its own environment, which differs from the parent environment and DISPLAY is defined only in the child's environment but not in the parent's.
-
Jokes continues. X started as tc, then in tty1 tc exited and logined as jb. Then in X opened new terminal:
tc@box:~$ su - jb -c 'echo $DISPLAY'
Password:
tc@box:~$ echo $DISPLAY
:0.0
in tty1
jb@box:~$ echo $DISPLAY
jb@box:~$ su - tc -c 'echo $DISPLAY'
jb@box:~$
tc can acces jb's environment, but jb can't access tc's.
jazzbiker, this is my interpretation of what's going on here:
- user "jb" does not have the DISPLAY variable defined in his environment. That's expected (jb is logged in to a console).
- user "tc" has the DISPLAY variable defined. That's expected.
- trying to show the value of tc's DISPLAY variable by switching to user tc using "su" doesn't work. That's unexpected.
-
Assuming the most complicated situation (persistent /home for multiple users), I think I found a good-enough solution. Every user who starts an X session gets a .Xauthority file in their home directory. So a surrogate question might be: Who's the owner of the most recent .Xauthority file?
The -t flag to ls puts the most recent files on top, so something like this will give us the most recent .Xauthority file on the local machine. The -1 (that's the number one) is to ensure a single column so that "head" doesn't get confused:
$ ls -1t /home/*/.Xauthority | head -n 1
So I think this answers the first part of OP--how to find active X11 session's user?
$ ls -1t /home/*/.Xauthority | head -n 1 | cut -d/ -f3
Can you guys help me find the DISPLAY value (from outside X's environment) of that user's environment? It seems to be non-trivial (e.g., https://superuser.com/a/647484) and I don't want to assume that it is :0.0
P.S. I need the value of the user's DISPLAY so that a udev rule (which does not have the DISPLAY variable in its environment) can launch a GUI application.
-
So someone will modify rule each time X starts? It may be some script, started immediately at X start.
-
No, the udev rule is not meant to be changed. The udev rule is part of an extension that I want to share with others. Therefore, the udev rule cannot assume that everyone's DISPLAY is :0.0
I use Xorg-7.7 and not Xfbdev as you do. Just out of curiosity, does Xfbdev likewise create a ~/.Xauthority file?
-
Hi GNUser
... Can you guys help me find the DISPLAY value (from outside X's environment) of that user's environment? ...
If you can associate a PID with the user, then maybe this:
sudo grep "DISPLAY=" /proc/$PID/environ | cut -d '=' -f2
-
I think it's fine to assume :0, that will cover 99.9% of the users, and those who it doesn't cover can edit it.
It's rare to run multiple X servers at once, and the sub-screen number (.0) is only relevant in rare multi-monitor configs (separate screens, windows not draggable between them).
-
Yes, Xfbdev uses Xauthority too.
-
So one way to find X11 session's user and display is like this:
user=$(ls -1t /home/*/.Xauthority | head -n 1 | cut -d/ -f3)
display=$(for PID in $(ps | awk "\$2 == \"$user\" { print \$1 }"); do grep "DISPLAY=" /proc/$PID/environ 2>/dev/null; done | head -n 1 | cut -d= -f2)
Rich, that was an amazing tip. Wow. Thanks.
curaga, good to know that :0 is a reasonable assumption. I guess users who are savvy enough to setup multiple displays will know to edit it.
jazzbiker, thank you very much for helping me work through this.
You guys are the best!
Thread may be marked as "Solved".
-
Thanks, jazzbiker. Good to know :)
-
Thanks, if You will use this not for TC only I hope You will not forget to use ps with ax switches or even aux.
Your threads are great sources for me, thanks again.
-
Hi GNUser
... user=$(ls -1t /home/*/.Xauthority | head -n 1 | cut -d/ -f3)
display=$(for PID in $(ps | awk "\$2 == \"$user\" { print \$1 }"); do grep "DISPLAY=" /proc/$PID/environ 2>/dev/null; done | head -n 1 | cut -d= -f2) ...
If you've ever looked through the scripts I've posted, you may notice I often use aliases back to the busybox versions.
This is to reduce the chance of breakage due to possible different behavior of the GNU version if it gets installed. The
ps command is a prime example of such behavior. If procps.tcz gets installed, the ps command will return this:
tc@box:~$ ps
PID TTY TIME CMD
25558 pts/2 00:00:00 sh
25569 pts/2 00:00:00 ps
tc@box:~$instead of the long list the busybox version returns.
-
TCL comes with an aliases file for this very purpose, so there's no need for us to rewrite our own aliases. If you want to specifically use the BusyBox version of the commands (as opposed to the GNU versions in coreutils.tcz, procps.tcz, sed.tcz, etc.), then put this near the top of your script:
. /etc/init.d/busybox-aliases
-
Hi GNUser
TCL comes with an aliases file for this very purpose, ...
Yes, yes it does.
... so there's no need for us to rewrite our own aliases. ...
Unless the command you want aliased to busybox is not in that file, like ps for instance. :o
-
Unless the command you want aliased to busybox is not in that file, like ps for instance. :o
https://github.com/tinycorelinux/Core-scripts/pull/14
It is now ;)
By the way, why aren't all the BusyBox commands that are compiled into TCL's BB binary included in /etc/init.d/busybox-aliases? Having to check whether a particular BB command is included in the aliases file seems like an unnecessary complication.
If calling the useBusybox function in tc-functions only works for some BB commands, the function seems unreliable.
Is having aliases for only a subset of BB applets intentional or a bug/oversight? If the later, I can submit another pull request with all the rest of the missing applets.
-
Hi GNUser
It's possible only the commands used in the Tinycore scripts were included.
-
If all compiled busybox applets are included in the aliases file, then the file will be larger but more generally useful. This code snippet generates a complete aliases file:
#!/bin/sh
for applet in $(busybox --list); do echo "$applet() {
busybox $applet \"\$@\"
}
" >> busybox-aliases; done
for applet in $(busybox.suid --list); do echo "$applet() {
busybox.suid $applet \"\$@\"
}
" >> busybox-aliases; done
We just have to delete the first two aliases because [ and [[ are not valid function names.
I'll submit a pull request on GitHub.
-
Hi GNUser
You might want to wait for Juanito and curaga to weigh in on this. There may be a reason some aliases were left out
that I'm not aware of.
-
From curaga: "It's not about using busybox everywhere, only where the commands may differ."
So I guess the plan going forward is to update the aliases file only when we find commands like ps that need to be included.
-
Hi, GNUser!
What's Your guess, is aliasing of all the busybox applets equivalent to PATH reordering? Not proposing, just asking.
-
Hi, jazzbiker. That's a great point. Yes, I think that would be a nice way of achieving the same result. Something like this would work:
export PATH="/usr/sbin:/usr/bin:/sbin:/bin:$PATH"The four prioritized directories would appear twice in the PATH but that wouldn't cause any problems.