Bash Script x11 açan Kullanıcı Tespiti

loginctl list-sessions: Açık olan oturumları id'leri ile listeler.

loginctl show-session -p Display -p Active $ids: id değeri belli olan kullanıcının aktif olup olmadığını ve hangi display kullandığını gösterir.

Aşağıdaki kod grafik arayüzü açan kullanıcıyı gösterir..

 for ids in $(loginctl list-sessions|grep "seat" | awk '{print $1}')

do
status=$(loginctl show-session -p Display -p Active $ids|awk '$1 ~ /Active=yes/ { print $ids}')
if [ "$status" = "Active=yes" ]; then
loginctl list-sessions|awk -v idss="$ids" '$1 == idss {print $3}'
fi
done

Yukarıda yapılan işlemi daha basit 

cat /run/systemd/sessions/userid user id ise loginctl list-sessions komutu ile bulunuyor aşağıdaki döküman anlatıyor.

Yukarıda kırmızı ile yaptığımız işlemin farklı bir yolu:
cat /run/systemd/sessions/$(loginctl list-sessions|grep "seat"|awk '{print $1}')|grep "USER"|awk -F '=' '{print $2}'

/****************************************************************************/

kaynak:  https://bugzilla.redhat.com/show_bug.cgi?id=1857969

Description of problem:

When a user logs in via gdm on RHEL- the /run/systemd/sessions/<n> created via

systemd-logind does not contain the DISPLAY information and loginctl can't

show it.

It is also impossible to use sd_session_get_display() to get the display

information programatically.

Version-Release number of selected component (if applicable):

# rpm -q gdm systemd

gdm-3.28.3-29.el8.x86_64

systemd-239-30.el8_2.x86_64

How reproducible:

Always

Steps to Reproduce:

1. Log in as an ordinary user

2. List the existing sessions

   # loginctl list-sessions

   SESSION   UID USER     SEAT  TTY 

        18     0 root               

        25 22174 casantos seat0 tty2

        c3    42 gdm      seat0 tty1

3. Show the user session information

   # loginctl show-session 25

Actual results:

   Id=25

   User=22174

   Name=casantos

   Timestamp=Thu 2020-07-16 16:16:42 -03

   TimestampMonotonic=21677574113

   VTNr=2

   Seat=seat0

   TTY=tty2

   Remote=no

   Service=gdm-password

   Scope=session-25.scope

   Leader=43159

   Audit=25

   Type=wayland

   Class=user

   Active=yes

   State=active

   IdleHint=no

   IdleSinceHint=0

   IdleSinceHintMonotonic=0

   LockedHint=no

Expected results:

   Should show a line containing "Display=:0"

Additional info:

   # cat /run/systemd/sessions/25

   # This is private data. Do not parse.

   UID=22174

   USER=casantos

   ACTIVE=1

   STATE=active

   REMOTE=0

   TYPE=wayland

   CLASS=user

   SCOPE=session-25.scope

   FIFO=/run/systemd/sessions/25.ref

   SEAT=seat0

   TTY=tty2

   SERVICE=gdm-password

   VTNR=2

   LEADER=43159

   AUDIT=25

   REALTIME=1594927002204542

   MONOTONIC=21677574113

   CONTROLLER=:1.2362

   DEVICES=13:65 13:64 13:67 226:0 13:66 13:69 

Disabling Wayland does not make any difference.

It would be good to find a workaround, since there is a customer case in which

the user needs to find the associated display of running sessions by means of

sd_session_get_display().

Comment 1Carlos Santos 2020-07-16 19:34:06 UTC

The display information is shown correctly in RHEL 7.8, so the current behavior

should be considered is a regression.

Comment 2Ray Strode [halfline] 2020-08-11 19:40:02 UTC

This is because, in RHEL 8, the X server (or wayland display server) is started as part of the user session instead of as root before the session starts.  loginctl gets passed it's information at the time the session is created.  There's no way we can know the display at that point.

Fixing this requires adding api to logind to allow the session controller to update the display variable after the session is created.

As far as workarounds goes, i'm not sure...  The user could install an autostart file in /etc/xdg/autostart that does omsething like:

[Desktop Entry]

Name=Record Display To Runtime Dir

Exec=sh -c 'echo $DISPLAY > $XDG_RUNTIME_DIR/display'

and then look at /run/user/1000/display to find the session display.

Of course it's better to run things within the session instead of trying to connect to the session from the outside, anyway.

Moving to systemd. If they ack adding the proposed logind API, then I'll add the bits needed in GDM.

/*******************************************************************/

kaynak: https://askubuntu.com/questions/53177/bash-script-to-set-environment-variables-not-working

root kullanıcısının export komutu çalışmama problemini sct-ript dosyasını çalıştııtrken source eki getirilecek

örnek:

source /usr/bin/e-AgRuns.sh gibi

aşağıda anlaan gönderielr mevcut....

BASH script to set environment variables not working

Asked 9 years, 6 months ago

Active 2 years, 3 months ago

Viewed 300k times

169

64

I've written the following script to set some environment variables when needed.

#!/bin/sh

export BASE=/home/develop/trees

echo $BASE

export PATH=$PATH:$BASE

echo $PATH

Below the command and the results I can see on my terminal: the script runs, but the variables are not set at the end.

~$: ./script.sh

/home/develop/trees

/bin:......:/home/develop/trees

~$: echo $BASE

~$: 

What's wrong? Thanks in advance. Mirko

bash

environment-variables

Share

Improve this question

Follow

edited Jul 15 '11 at 15:21

Marco Ceppi♦

45.8k2727 gold badges164164 silver badges196196 bronze badges

asked Jul 15 '11 at 8:18

MirkoZa

1,80122 gold badges1212 silver badges44 bronze badges

Shells are opened hierarchically. You can set a parent's shell's vars using . ./yourscript.sh – Janac Meena Jan 29 '20 at 14:54

add a comment

3 Answers

238

export exports the variable assignment to child processes of the shell in which the export command was ran. Your command-line environment is the parent of the script's shell, so it does not see the variable assignment.

You can use the . (or source) bash command to execute the script commands in the current shell environment and achieve what you want, e.g.

source ./script.sh

echo "$BASE"

Will produce

/home/develop/trees

The source command, often seen in scripts, is a bash synonym for ., which is part of the POSIX standard (so . is available in dash, for example, but source isn't).

. ./script.sh     # identical to "source ./script.sh"

(. script.sh and source script.sh will first look for script.sh in PATH, so it's safer to specify the path to script.sh.)