setting "xterm +" on startup

SUSE Linux Enterprise Server SLES Configure-Administer
1

Hi all, we’ve got an issue that I need help figuring out. We are
running some SLES 11 SP1 servers that run a service on startup that
opens an xterm window for interation on the server monitor.

The service runs as root and it calls a script that does an “su -
otheruser” and then calls another script that runs as the other user.
This last script is the one that actually contains the xterm commands.

When the service runs at startup, the xterm window will not open. We
can output the errors to a log file and the error say:
NO PROTOCOL SPECIFIED
XSET: UNABLE TO OPEN DISPLAY “:0.0”

If I open a console prompt and issue “xhost +” and then run SUDO
SERVICE servicename START, the service starts and opens the xterm window
perfectly. If I run “xhost -” and stop and restart the service, it
fails again.

So seems clear to me that I need to run the “xhost +” command prior to
starting the service but I have not been able to get this to work. I
tried adding the command in the /etc/init.d/xdm script but it didn’t
work. I then created another script that does nothing but runs that
single command and set it up as a service to run between xdm and our
original service but that doesn’t work either.

So my question is this: how do I automate the issuing of the “xhost +”
command. OR, is there something different I should be looking at? I
googled these errors and it led me off down rabbit trails chasing things
such as xauthentication and magic cookies which I don’t fully
understand.

Thanks

–
jgosney

jgosney’s Profile: http://forums.novell.com/member.php?userid=1513
View this thread: http://forums.novell.com/showthread.php?t=449053

2

On Fri, 02 Dec 2011 16:36:02 GMT
jgosney jgosney@no-mx.forums.novell.com wrote:
[color=blue]

Hi all, we’ve got an issue that I need help figuring out. We are
running some SLES 11 SP1 servers that run a service on startup that
opens an xterm window for interation on the server monitor.

The service runs as root and it calls a script that does an “su -
otheruser” and then calls another script that runs as the other user.
This last script is the one that actually contains the xterm commands.

When the service runs at startup, the xterm window will not open. We
can output the errors to a log file and the error say:
NO PROTOCOL SPECIFIED
XSET: UNABLE TO OPEN DISPLAY “:0.0”

If I open a console prompt and issue “xhost +” and then run SUDO
SERVICE servicename START, the service starts and opens the xterm
window perfectly. If I run “xhost -” and stop and restart the
service, it fails again.

So seems clear to me that I need to run the “xhost +” command prior to
starting the service but I have not been able to get this to work. I
tried adding the command in the /etc/init.d/xdm script but it didn’t
work. I then created another script that does nothing but runs that
single command and set it up as a service to run between xdm and our
original service but that doesn’t work either.

So my question is this: how do I automate the issuing of the “xhost
+” command. OR, is there something different I should be looking
at? I googled these errors and it led me off down rabbit trails
chasing things such as xauthentication and magic cookies which I
don’t fully understand.

Thanks

[/color]
Hi
You need to look at using xvfb then you don’t need X running. For
example;
http://stijn.tintel.eu/blog/2008/02/20/sles10-and-xvfb

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.9-desktop
up 1 day 19:18, 3 users, load average: 0.14, 0.06, 0.08
GPU GeForce 8600 GTS Silent - Driver Version: 290.10

3

Malcolm, if I understand that correctly, that would be used in a
situation where you’re in runlevel 3 but still need to run a gui app.
We are actually in runlevel 5 since the user needs other gui apps but
we’re trying to launch an xterm console from a script ran from a
service.

–
jgosney

jgosney’s Profile: http://forums.novell.com/member.php?userid=1513
View this thread: http://forums.novell.com/showthread.php?t=449053

4

On Fri, 02 Dec 2011 18:46:02 GMT
jgosney jgosney@no-mx.forums.novell.com wrote:
[color=blue]

Malcolm, if I understand that correctly, that would be used in a
situation where you’re in runlevel 3 but still need to run a gui
app. We are actually in runlevel 5 since the user needs other gui
apps but we’re trying to launch an xterm console from a script ran
from a service.

[/color]
Hi
What if you start with the -display option then?

su - username -c "nohup <some_command> -display :0.0 &"

But if the user isn’t logged in and no X is running, you will need to
use Xvfb, then when the user logs in connect to that display eg make
it :5.0.

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.9-desktop
up 1 day 19:59, 3 users, load average: 0.09, 0.24, 0.24
GPU GeForce 8600 GTS Silent - Driver Version: 290.10

5

Hi Malcolm,

That command syntax won’t even run. I checked and Xvfb is already
installed but I’m not sure how to run it.

Part of this issue is that when it comes to this part of the O/S, I’m
still a newbie and don’t really have a firm grasp of all the
interconnected components of X and authentication and magic cookies,
etc.

I was thinking that to get back to the basic question, I should just
eliminate x authentication as the issue. So I did some digging and
found the /etc/X11/xdm/Xservers file. According to the help that comes
with the X command (x --help), the -ac switch disables authentication.

When I look in my /etc/X11/xdm/Xservers file, it has one line…
:0 local /usr/bin/X -nolisten tcp -br vt7

so if I add the -ac to the end of it as such…

:0 local /usr/bin/X -nolisten tcp -br vt7 -ac

and reboot the box, the problem still occurs. So either X
authentication is not the issue or that is the wrong way to disable X
authentication.

Can you verify that this should indeed disable X authentication?

thanks

–
jgosney

jgosney’s Profile: http://forums.novell.com/member.php?userid=1513
View this thread: http://forums.novell.com/showthread.php?t=449053

6

On Fri, 02 Dec 2011 21:16:02 GMT
jgosney jgosney@no-mx.forums.novell.com wrote:
[color=blue]

Hi Malcolm,

That command syntax won’t even run. I checked and Xvfb is already
installed but I’m not sure how to run it.

Part of this issue is that when it comes to this part of the O/S, I’m
still a newbie and don’t really have a firm grasp of all the
interconnected components of X and authentication and magic cookies,
etc.

I was thinking that to get back to the basic question, I should just
eliminate x authentication as the issue. So I did some digging and
found the /etc/X11/xdm/Xservers file. According to the help that
comes with the X command (x --help), the -ac switch disables
authentication.

When I look in my /etc/X11/xdm/Xservers file, it has one line…
:0 local /usr/bin/X -nolisten tcp -br vt7

so if I add the -ac to the end of it as such…

:0 local /usr/bin/X -nolisten tcp -br vt7 -ac

and reboot the box, the problem still occurs. So either X
authentication is not the issue or that is the wrong way to disable X
authentication.

Can you verify that this should indeed disable X authentication?

thanks

[/color]
Hi
Not a good thing to disable the authentication?

But at that point only gdm is up and running on vt7, or are you auto
logging in a user in?

So, does this service indeed start at run level 5? That should be
defined in the /etc/init.d/ command your running to start the service,
and also requires X to be up?

Or are you starting your service some other way?

Until a user is logged in the only method is Xvfb?

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.9-desktop
up 1 day 22:35, 4 users, load average: 0.04, 0.04, 0.05
GPU GeForce 8600 GTS Silent - Driver Version: 290.10

7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think this is going down the right path now by trying to figure out
how the “service” is starting. For most of us using the term “at
startup” especially when referring to a service means something starting
whether or not there is X involved or a user logging in via
/etc/init.d/. If that is how things are being started I would guess
this will be hard to get right because it makes some incorrect assumptions:

  1. There will be a GUI. At startup there is no GUI, at least not until
    there is.
  2. Somebody will be logged in. On a server this is not a default and
    on most systems it’s a questionable security choice, though if the box
    is physically secure and it’s non-root I guess for monitoring that could
    be useful. Still, there’s still more delay after the GUI is up until
    something is logged in.
  3. If all of that timing works out properly you still have permissions
    on GUIs that prevent other users, including the same user from another
    shell that did not originate within X, from sending applications to X.
    You can relax these restrictions and export DISPLAY and all of that, but
    it’s a lot of work.

If we understand your requirements correctly it is to run a script, as
the non-root user who is going to be logged-in via the X session, once
that user is logged in. The easiest way to avoid timing issues is to
have the login actually load xterm. That also happens to avoid X
permissions problems, any question about service restarts when the user
logs out and back in, and generally keeps things from unnecessarily
existing in /etc/init.d/.

On my 11.3 system under ‘Control Center’ is a button for ‘Startup
Applications’. Add something in here, as the user that will be
logged-in via X, to launch your xterm with your script and see if that
works.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJO2iQsAAoJEF+XTK08PnB5PNEQALIVobcde0KhfTg4L/PUiXh1
gVewEJFTD+ALRoVR4OatwA5Rs11lLN7H7q7GYqSNNZpcd40aemnQWsjEDbuJS8A2
a3zkWFhNJ9cGHz8Z6qTN31Sttxp9R/awvoLNbDIjzWfzRAlQQpo2MnOm8pJjtf5c
iptn3g4i5gN1NlWwtYKNnW6hPPJQc8b1v5YL9zZkxLSRE8sQwJRgkkv51kIaHOcO
5L4VdkRRscxa2N54reiCcKwfCUEqHCb1szziZsnpwcGrkOO0SyvLw8oufrdOc3o2
QagJXscx7PMf3vmLR1Dh5bCaorOeYZgkkgj9kMpznzO1xUVvDhT93BMZlIjwM0oa
2ESfjhJrVkoqYEVw9VIuq2fysMcnecW7eE05RULZDmjXkeqnEmGHDBBElcx4Tz4q
aTumcuNJPILbrdKjX+Ll+oUM7iY+kW/hiFx45kHu8Ydaklnbz2FR4ZJfYpCcbMyU
ApkBSeNT7LY2m6kLyk5Wu1fd5jbbHezvgUWfdK6wTi3ygTCQK7GiO7L4R0gwwQso
CYKZjaA4ccjKiWd8e9fxyuhCk85NLU431k9q/1//xqAZEgXfCUeNZh4Gnz/bwbkm
Kkoczexkz/+2K2yeM/suTp3q+G/6RB1oUhKJRAAK85SS9bZfEbN3n+XSdxSQEmjr
AFwS7277wKfcyergwoOz
=c+/8
-----END PGP SIGNATURE-----