I have written a shell script with "echo $DISPLAY"

shell script:
*************
#!bin/bash
echo DISPLAY=$DISPLAY
*************

and running it from a systemd service then it does not detect display
expected value of $DISPLAY should be ":0"

getting output:
"blank"

In case of manual execution of the same script from a console it detects display.

getting output:
DISPLAY=:0

I don't know why this is happening, is there any xsession related problem?


PS: if I export environment variable from a systemd service then it shows DISPLAY=:0 but I dont want to export the value of DISPLAY

Thank you in advance

Much more info about the systemd setup and the service itself would be required, but generally speaking:
This is to be expected. Systemd does not know your environment (variables) by default.
Why do you need this?

I am checking if xserver is running or not by using "xset q" for display information. I have a shell script consist of the following code snippet.
"""
if /usr/bin/xset q >/dev/null 2>&1; then
echo "X server found: DISPLAY=$DISPLAY"
return
fi

DISPLAY="$DEFAULT_DISPLAY"
export DISPLAY

if /usr/bin/xset q >/dev/null 2>&1; then
echo "X server found: DISPLAY=$DISPLAY"
return
fi

echo "X server not found" >&2
exit 1
"""

so here "xset q" is not working. I have checked with "echo $DISPLAY" but getting nothing. exporting display won't work too. but same thing If I am doing through terminal then its working.

PS: I am running this script through a systemd service

arco Linux, I have to admit I know little to knowing about systemd even though because I use this distro i am forced into using systemD.

nevertheless, running your code as written.
as stated return is for functions not if statements.

now having fixed that bit of code by removing the return(s) in it, I get
where the last statement echo'ed out is showing false data because of how it is written to be shown, as a no matter what print this to the screen with a no matter happens, exit code of 1

bad programming there.
0 = no errors had
anything other than 0 = errors had.

I'd adjust your code accordingly.

Suggested required reading.
Linux, environment variables list
Chapter 20. I/O Redirection
Linux and Unix exit code tutorial with examples

then add all of that and what ondoho said about systemD and what you're trying to do.

use this in a search string, then follow where it takes you.

DISPLAY is relative to the display device from which you start the X session. Since you're running this via systemd you're doing it in the background so there is no display device.

You can do background X using Xvfb (X virtual frame buffer) as some programs (e.g. Oracle DBs) require an X window even if they're not actually showing it to you. Xvfb is provided by the xorg-x11-server-Xvfb package on RHEL/CentoS.

$DEFAULT_DISPLAY is defined in a CONFIG file.
return is fine in my context. I am using this code in a function and called this function in a different script.
I just wanted to know, when I am running a shell script including
""echo $DISPLAY"" on terminal it gives
output: ":0"

but the same script I am running from a system service.
not getting expected output.

DEFAULT_DISPLAY is a variable. Setting it does not mean you in fact have an X display device available in your background systemd program.


As an illustration - despite setting:
CASH=one_million_dollars

And then echoing the variable:
echo $CASH

With the output:
one_million_dollars

I do NOT in fact have one million dollars.

Like I stated run this in a search string, 'xset and systemd linux' then read up on it.

The OP's general problem with the script is expecting a background program to work the same way as it does from command line. This is usually because the environment for a background program (be it SysV init, cron or systemd) is almost never the same as the environment one has at the command line. I wrote a blog post regarding init and cron but the same principle applies to systemd.

The specific issue here is there is no X environment for background processes so X commands won't work because they depend on such an environment. The solution for X background processes as I mentioned in my first post is to use Xvfb.

However, the OP mentions trying to determine if X is running. It might be more to the point to check for specific processes.

The methodology for systemd, by the way, is different than that for SysV init. In the latter one had to setup the order things start overall so that services required by later items were started earlier in the order. (e.g. networking had to be started before most things). In systemd however the default is to start everything at the same time. This means if one has a systemd script that is dependent on another one having started first that dependency must be expressed within the second systemd script as otherwise it might try to start without the first one having run. The intent of this is to make bootups faster by NOT requiring dependencies that aren't necessary. Given that rather than writing a script to determine if X is running it might be more to the point to simply check for antecedent systemd scripts having started successfully then reporting same.

On RHEL7 running gdm (Gnome Display Manager) for X windows console the systemd process is gdm.service. If one runs "systemctl status gdm" it will show that is running:
Notice /usr/bin/X is running as part of that. One could make a systemd program dependent on successful start of gdm if desired.

Yes but you're still not telling us what you are trying to achieve.
FWIW, you don't want to run this sort of script as a systemd service.
There's a whole list of complications (some of which simply errors in the script, others because you don't have an environment when you run this as a systemd service) which I'm sure MensaWater up there listed for you.

Shortly:
Learn what you can learn now (proper shell scripting for example), tackle systemd later.