My application will trigger a terminal window to run some task. It does open the window when running under VNC server side since its display port number is 0.
When the application runs in VNC client viewer, the terminal windows will not be opened since the display port is not 0.
In order to fix this issue, I need to know where my application is running at either on Server or Client, so I can set it to the correct display port.
Thanks!
Tom
Related
Build: Server with Ubuntu 18.04 in data center with Ubuntu Mate Desktop interface.
As I understand, any GUI app needs a display in which to function. I connect to the server via x2go to display the ubuntu mate interface.
Once connected, I have a scheduled cron job that launches a terminal, a GUI and some commands.
Everything works perfect as I have previously detected what display I'm using as a user and specify that to launch the terminal and the commands.
Problem: if I'm not connected via x2go client to the server and provide that display, I noticed today that the cron job didn't launch at the specific time (08:50), which was previous to my x2go client connection (09:23); it just launched when I did the x2go client connection from my desktop manually -- my understanding is that it didn't launch because there was not any available display.
I'm not technical enough to get more deep into this problem.
¿Is there anyway in which I can make the cron script function (i.e. that it launchs the terminal and the GUI) without the need of manually getting into my desktop and launching the remote desktop client (x2go)?
My ideas go for having another minimal setup in that data center or another that takes the advantages of being there and have a physical monitor to display constantly connected to the main server OR just manually entering the server via x2go every day.
EDIT: When I disconnect the x2go client session from the server, the launched GUI and etc perfectly maintains, without dissapearing because "I have terminated the session and eliminated the display".
Finally got it working with the great help of one of x2go founders (Oleksandr Shneyder) after understanding how x2go handles the sessions and the X server.
Sessions can suspended/hibernated, disconnected and terminated.
Suspended/hibernated: when "manually" or automatically the x2go server side suspends so that it saves resources.
Disconnected: when you exit the session window and the x2go client in your desktop/laptop.
Terminated: when you log out from the DE environment or issue the x2goterminate-session command in the terminal inside the session.
My x2go app was somehow entering into suspending mode in the server, causing that the display (50 in my case) in which the scheduled cronjob need to be run and launche the GUIs, "was not awaken" until I entered into the session via the
app. In that moment, the cronjob started executing.
To tell x2go server to not hibernate, I needed to change the X2GO_NXOPTIONS in /etc/x2go/x2goagent.options to X2GO_NXOPTIONS="sleep=0"
After this, everything functions perfectly in the server.
Hope it helps others.
I'm connected to my Raspberry PI via SSH (Rasbian). Now I want to start an Application from it that uses a Graphical Interface. That Application is a simple Mono Window. It should be displayed on the PI's Display
I can't do it because it tells me that is has no DISPLAY set (thats true, since I use SSH)
When I'm starting it from the terminal app on the PI's Desktop it works as expected.
My querstion is now: What do I have to do, that I can start this app over SSH and the window pops up on the PI's desktop?
If you're trying to start the X application on the remote X server, see https://serverfault.com/questions/142244/how-do-i-start-a-x-application-on-remote-server-over-ssh
If you're trying to start the X application on the Pi, but show its window on your local desktop (you'll need X11 on your local desktop), use ssh -X.
I have Linux compute server A on which I would like to execute an application, say HV (I use this HV application to render a CAE model and capture the image). Eventhough I run this HV in batch mode, from putty terminal, it requires X windows. That is I need to run Xming and forward the display from server A, else it exits with error "No valid fonts - exiting". (In this case I am connecting to server A from my windows laptop using putty)
Instead of using Xming, the workaround I use is Xvfb. This works great in 90% of the cases. In the remaining 10% cases, few of the objects are not rendered in the captured image file.
Is there any alternate to Xvfb. There are few mention on net about Xdummy, but not much details. Or, it there any way to pass the relevant font, without forwarding the display?
My actual use case is, I have web application running on another Linux server, let us call it Server B. When I trigger the event from the client browser, the Server B connects to Linux Server A via ssh and executes the HV application. Even in this scenario, I tried ssh -X instead of just ssh for the connection between B and A. Still the application is exiting error "No valid fonts - exiting" if I don't use Xvfb.
We had the similar issue with xvfb not working consistent and contacted the vendor, their suggestion was to upgrade graphics drivers to the latest version. It did the trick. Xvfb created consistent size images.
Thanks,
anony
For capturing ssh sessions I use "script" command: "script -c 'ssh user#host' outfile". But I have no idea how to capture sessions to remote hosts, that connected over com(serial) port.
screen script -c 'screen /dev/ttyS0 57600' file
ends immediately with empty log. Both 2 functions that implemented in screen is necessary: ability to switch between opened sessions and ability to perform i/o to /dev/ttyS. I started develop some tiny utility to redirect stdin/stdout to /dev/ttyS but now it's so buggy and doesn't work yet.
First off, a terminal program, like minicom (or good-ol cu), as suggested by Laszlo, is needed to communicate with the remote system. Once you can get such a program to work, then screen can be brought into the picture. Note that this also requires a getty running on the remote computer's serial port. If it's an old-fashioned serial port, you may also need a special null-modem cable.
Screen can be used with such a connection to be able to move access of the session across terminals. However, it cannot be used to spawn more than one session with the remote server. That's because the program running on the serial port (getty) only supports a single session. In this case, the screen runs on the local machine, and the terminal-program session running within screen connects to the remote server. So, it is possible to have multiple screens, but just not more than one connected to the remote server over a single serial port.
With all of that said, serial ports can be used to network two machines, assuming both support the same serial-line networking protocol. Networking eliminates these restrictions.
To open an interactive terminal session to a COM port (/dev/ttyS*), you probably want to use a terminal emulator software, like 'minicom'.
I am having some problems with launching firefox from a Linux daemon written in C.
When I launch firefox on the machine itself (via terminal) from the command shell using /usr/bin/firefox it works OK and a firefox browser window lanunches as it should.
However if I try this within my C daemon using system("/usr/bin/firefox"), firefox launches its process in the terminal but the browser window is not opened?
A similar thing happens when I try to do this using remote terminal acces. It's something to do with telling the system to open firefox in window mode rather than trying to open it in terminal mode - but I dont know how to specify this using bash commands?
I am using Lubuntu 11.10 in my Linux System.
Any help is most appreciated.
There's a reason I asked why you're attempting to do what you want. I didn't want to get into great details in my comment.
Firefox on Unix is an X-Window process (most of the Linux/Unix desktops are based upon the X11 protocol which is the heart of X-Window). What X-Window does is separate the display of the program from the process running the program. For example, I am now running Firefox from a Linux box at work, but the Linux box is actually displaying the Firefox browser window at home on my Mac.
In order to do this, I had to:
Run X11 on my Mac. The X11 program creates a default X11 client display called 0.0 which pretty much says the first screen and the first instance of X11 running (computer geeks like counting from zero). The process runs in the background on my Mac. In a certain sense, it's really a server process and not a client because it's waiting on port 6000 for a client X11 process (Firefox) to tell it what to do.
Before I run firefox, I have to tell my Mac's X11 process that I grant the X11 server running Firefox to be able to display on my X11 client process. Otherwise, you can imagine someone spamming another person by continuously popping up Windows on their display. You can use the xhost program to do this.
In order to run Firefox on the Linux box, I have tell the Firefox process what X11 client I'm running it on. I can do this by setting the DISPLAY environment variable to something like "10.0.1.33:0.0". This means the X11 client is running the the machine on IP address 10.0.1.33, and I want you to use the first screen, and the first instance of the X11 client on that screen.
Now, I can run Firefox on my Linux box, and the display will display on my Mac.
The problem you're running into is that there's simply no X11 client when you're starting FireFox as a daemon process. An X11 client is associated with a user and a display of some sort. The display could be a virtual display, but there's got to be an X11 client that's running and is addressable in some way, so the process knows where to display the output.
By the way, you said daemon which has a very, very specific meaning in Unix/Linux. A daemon is a process that runs in the background and usually has a service (and a port) associated with it. For example, there's an FTP daemon called ftpd, the mail server uses the sendmail daemon, ssh has the sshd daemon. Daemons have no display associated with them.
However, it looks like you might be using the word to mean launching Firefox via another process. Is that true? If so, you'll have to make sure that Firefox knows the X11 display to use (there's a command line setting to use to specify the display), and that your X11 client (your login session) has given permission for another process to update your display with the program window.
Can you please explain what you're trying to do in a bit more detail? If you simply want to download a file from a remote http server (which of course is running the http daemon process called httpd), you should use curl or wget which don't require a display and are way simpler to use. If you're trying to do something else, let us know exactly what it is.
Firefox needs to know which display it should open on. When you run it from within a gui, even through a terminal emulator, the DISPLAY environment variable is set to the appropriate value. When you launch from the daemon, try system("/usr/bin/firefox -display=:0").
Make sure that the DISPLAY environment variable is properly set in your daemon to refer to the X server that you want your firefox to use.
If the daemon is run as a different user account than the user account that "owns" the X server that you want to use, you will also need to use xauth(1) to configure the authentication token to grant permission to use the X server.
Often times, it is far easier to use ssh -X to tunnel X and properly configure the xauth(1) tokens in one go than try to manage xauth(1) tokens yourself. Maybe adding ssh -X into your environment would be suitable, maybe not. (I've even used ssh -X root#localhost before when I needed to run an X client as root and didn't want to bother with configuring xauth(1) manually. ssh(1) is just so much easier.)