Hi everyone,I just tried to run LoadUI from command line on CentOS (HEADLESS server) and it seems that it is not working properly. LoadUI starts but then nothing shows up. What it is strange is that I don't see any errors.I have attached a document showing the behavior. 1. Would like to provide some help on this (if there is any)? I have a feeling, this is happening because I am running it on a headless server. Is there a way to bypass the JavaFX2 package?2. I noticed some other abnormal behavior, I tried to stop it from running using "Ctrl + C". It stops for 1 second but then it restarts back so I wasn't able to stop it at all and I had to reboot the entire box. (killing the processes didn't help either. in fact each time I kill a process another one pops up) .:::. .==:::::. .====:::::::. .======:::::::::. .========:::::::::::. .:=========:::::::::::::. .:::=========:::::::::::::::. :::::=========::::::::::::::::: :::::=========::::::::::::::::: ':::=========:::::::::::::::' ':======================' '===================' '===============' '===========' ':::::::' ':::' :: :: :: :: :::: :: :: :: :: :: :: :::: ::::: :::::: :: :: :: :: :: :: :: :: :: :: :: :: :: :::::: :::: ::: : :::::: ::::: :::: LoadUI 2.7.0Starting with arguments: [--cmd=true, --nofx=true, -nofx, -Dlog4j.configuration=log4j_headless.xml]Jul 09, 2014 3:14:29 PM com.eviware.loadui.launcher.JavaFxStarter ensureFontsAvailableForJavaFXINFO: Preparing fonts for JavaFX2Jul 09, 2014 3:14:31 PM com.eviware.loadui.launcher.JavaFxStarter ensureFontsAvailableForJavaFXINFO: Restarting JRE for changes to take effect.

Hello there,No, unfortunately JavaFX2 needs to be started in order to provide charts for reports. There is a workaround however, but it might take a few steps to resolve. First off, the error you are seeing is related to your system not having any TrueType fonts, which is okay, since you are running CentOS. So what LoadUI does is that it tries to install a TrueType font from the bundled $LOADUI_HOME/jre/lib/fonts/*.ttf i think into the user home-folder if any.What you can do, is to make sure that your user has access to and that loadui can write to ~/.fonts and can run a command called 'fc-cache -v'.I'm going to refrain from suggesting what package includes it since it varies depending on OS version and is very easy to look up. This will allow it to copy the *.ttf files to that folder and import them into the systems font-cache, which in turn instructs JavaFX2 into believing that the system has the fonts that it will need. An alternative if you are unsure whether loadui should have access to the folder is to manually copy the .ttf files to a folder which fc-cache -v checks, it is very verbose about it, and run fc-cache yourself after it is copied. I hope this resolves your issue!If not, respond to this thread and we'll work something out. Best regards,Mikael

Hi Mikael,Thank you for your response. I followed the steps you asked me to do and here is the output I got after running fc-cache -v : /usr/share/fonts: caching, new cache contents: 8 fonts, 0 dirs/usr/share/X11/fonts/Type1: skipping, existing cache is valid: 13 fonts, 0 dirs/usr/share/X11/fonts/TTF: skipping, no such directory/usr/local/share/fonts: skipping, no such directory/root/.fonts: caching, new cache contents: 8 fonts, 0 dirs/var/cache/fontconfig: cleaning cache directory/root/.fontconfig: not cleaning non-existent cache directoryThen when I run LoadUI again from command line using the following: ./loadUI-cmd.sh -p /opt/SmartBear/LoadUI-2.7.0/samples/sample1.xml , I didn't see the behavior that I described previously (which is good). However, I got this error: Starting with arguments: [--cmd=true, --nofx=true, -nofx, -Dlog4j.configuration=log4j_headless.xml, -p, /opt/SmartBear/LoadUI-2.7.0/samples/sample1.xml](<unknown>:14609): Gtk-WARNING **: cannot open display: I am not sure how to move forward after this step so would you like to provide me with further instructions if possible? Is there a way to just run the test without generating the report since it seems that the tools used to generate the report are causing the issue? Best Regards,Pat.

Hello again! This is good! This is extremely common when a machine does not sport a display like yours. Remember that JavaFX2 is an interface-library, it wants to verify that it can draw the components it's requested to so it checks whether there's a DISPLAY environment variable. Isn't that clever! Unfortunately it makes it pretty hard to draw graphs, which is doable without a screen, on reports in a headless environment when the library demands it. So let's give it a mock-screen.The solution is Xvfb, and the way to accomplish this has been explained before. So here is a link to one of those topics. I hope it solves your issue, otherwise just get back and we'll troubleshoot it further. Best,Mikael

Hi Mikael,It seems that everything worked fine. I followed the instructions provided in the link and LoadUI started successfully from command line. (I haven't done any further testing yet but as far as I see , LoadUI worked on my headless server)You rock Thanks for the support,ps: I hope this fix helps other LoadUI users.Pat

patrick1980 wrote:Hi Mikael,It seems that everything worked fine. Good to hear! Drop another topic if you encounter any other trouble. Best,Mikael

Running LoadUI from command line CentOS not working

11 Replies

OstbergM
Staff
10 years ago
Hello there,

No, unfortunately JavaFX2 needs to be started in order to provide charts for reports.
There is a workaround however, but it might take a few steps to resolve.

First off, the error you are seeing is related to your system not having any TrueType fonts, which is okay, since you are running CentOS.
So what LoadUI does is that it tries to install a TrueType font from the bundled $LOADUI_HOME/jre/lib/fonts/*.ttf i think into the user home-folder if any.
What you can do, is to make sure that your user has access to and that loadui can write to ~/.fonts and can run a command called 'fc-cache -v'.
I'm going to refrain from suggesting what package includes it since it varies depending on OS version and is very easy to look up.

This will allow it to copy the *.ttf files to that folder and import them into the systems font-cache, which in turn instructs JavaFX2 into believing that the system has the fonts that it will need.

An alternative if you are unsure whether loadui should have access to the folder is to manually copy the .ttf files to a folder which fc-cache -v checks, it is very verbose about it, and run fc-cache yourself after it is copied.

I hope this resolves your issue!
If not, respond to this thread and we'll work something out.

Best regards,
Mikael
patrick1980
Occasional Contributor
10 years ago
Hi Mikael,

Thank you for your response.

I followed the steps you asked me to do and here is the output I got after running fc-cache -v :

/usr/share/fonts: caching, new cache contents: 8 fonts, 0 dirs
/usr/share/X11/fonts/Type1: skipping, existing cache is valid: 13 fonts, 0 dirs
/usr/share/X11/fonts/TTF: skipping, no such directory
/usr/local/share/fonts: skipping, no such directory
/root/.fonts: caching, new cache contents: 8 fonts, 0 dirs
/var/cache/fontconfig: cleaning cache directory
/root/.fontconfig: not cleaning non-existent cache directory

Then when I run LoadUI again from command line using the following: ./loadUI-cmd.sh -p /opt/SmartBear/LoadUI-2.7.0/samples/sample1.xml , I didn't see the behavior that I described previously (which is good). However, I got this error:

Starting with arguments: [--cmd=true, --nofx=true, -nofx, -Dlog4j.configuration=log4j_headless.xml, -p, /opt/SmartBear/LoadUI-2.7.0/samples/sample1.xml]

(<unknown>:14609): Gtk-WARNING **: cannot open display:

I am not sure how to move forward after this step so would you like to provide me with further instructions if possible?
Is there a way to just run the test without generating the report since it seems that the tools used to generate the report are causing the issue?

Best Regards,
Pat.
OstbergM
Staff
10 years ago
Hello again!

This is good! This is extremely common when a machine does not sport a display like yours.
Remember that JavaFX2 is an interface-library, it wants to verify that it can draw the components it's requested to so it checks whether there's a DISPLAY environment variable. Isn't that clever!

Unfortunately it makes it pretty hard to draw graphs, which is doable without a screen, on reports in a headless environment when the library demands it.
So let's give it a mock-screen.

The solution is Xvfb, and the way to accomplish this has been explained before.
So here is a link to one of those topics.

I hope it solves your issue, otherwise just get back and we'll troubleshoot it further.

Best,
Mikael
patrick1980
Occasional Contributor
10 years ago
Hi Mikael,

It seems that everything worked fine.

I followed the instructions provided in the link and LoadUI started successfully from command line. (I haven't done any further testing yet but as far as I see , LoadUI worked on my headless server)

You rock
Thanks for the support,

ps: I hope this fix helps other LoadUI users.

Pat
OstbergM
Staff
10 years ago
patrick1980 wrote:
Hi Mikael,
It seems that everything worked fine.

Good to hear!

Drop another topic if you encounter any other trouble.

Best,
Mikael
patrick1980
Occasional Contributor
10 years ago
Hi Mikael,

Again thanks for the tips of last time. That resolved the issue for me when I run LoadUI manually from command line on CentOS.

Now, I am trying to automate my project using Jenkins and Ant.
I wrote my build xml script and I am pretty sure I correctly invoked LoadUI. But to check, here is how I did it:

<target name="loadUI" description="Run LoadUI Project"
<exec dir="." executable="/opt/SmartBear/LoadUI-2.7.0/loadUI-cmd.sh">
<arg value="-p /project/path" />
<arg value="-L 300:0:0" />
</exec>
</target>

When I start my project from Jenkins (Web Interface), I get the following error:

[exec] Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException:
[exec] No X11 DISPLAY variable was set, but this program performed an operation which requires it.
[exec] at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:173)
[exec] at java.awt.Window.<init>(Window.java:477)
[exec] at java.awt.Frame.<init>(Frame.java:419)
[exec] at javax.swing.JFrame.<init>(JFrame.java:218)
[exec] at com.javafx.main.Main$1.run(Main.java:648)
[exec] at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
[exec] at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:676)
[exec] at java.awt.EventQueue.access$400(EventQueue.java:96)
[exec] at java.awt.EventQueue$2.run(EventQueue.java:637)
[exec] at java.awt.EventQueue$2.run(EventQueue.java:635)
[exec] at java.security.AccessController.doPrivileged(Native Method)
[exec] at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:108)
[exec] at java.awt.EventQueue.dispatchEvent(EventQueue.java:646)
[exec] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
[exec] at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
[exec] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
[exec] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
[exec] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
[exec] at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)

It seems to be the same issue as before, do you have any idea or workaround that solves it?

As I said earlier, if I run the project from command line (manually), everything works fine. Only when I run it from Jenkins, it throws the error.

I will appreciate it so much if you can provide me with some feedback.

Best Regards,
Pat.
OstbergM
Staff
10 years ago
Hey again Patrick,

It looks as if your automation-script is not picking up the environment variable, and it depends on where you export your environment variable.

export DISPLAY=:99.0

There are of course many ways to do it but if you do it only from the command-line then that environment variable is only active for your SSH session.
If you want to set variables for your session each time you logon then you can add the export to bashrc.

~/.bashrc

If you want the system to pick it up on startup then i suggest you add it to rc.local which is run on system boot.

/etc/rc.d/rc.local

or similar file of your distribution version if they changed it recently.
There's also an option of putting it as a standalone script that is called by /etc/profile or /etc/bashrc

/etc/profile.d
/etc/bashrc.d

I think that should resolve your trouble.
Best of luck!

Mikael
patrick1980
Occasional Contributor
10 years ago
Hi Mikael,

I have already done that. But it seems it is not working. It is still throwing errors:

Can't connect to X11 window server using ':99.0' as the value of the DISPLAY variable

However, I might have found a solution. I will post it once it is confirmed. It could help other LoadUI users integrate their load tests with Jenkins.

In the meantime, if you have other suggestions/solutions, please post them here.

I will keep you posted.

Thanks again,
Pat
OstbergM
Staff
10 years ago
Any progress Patrick?

Otherwise, it could be interesting to look into starting both Xvfb and create environment variables through jenkins,
it's likely that it isolates itself from anything profile-related. I'm not entirely sure about it though.

I do know that there's a settings to start Xvfb before the build and configure what screen it should create.
I haven't tried it myself, but the envInject plugin might be worth looking into.

Do get back with any solutions you might find!

Best,
Mikael
patrick1980
Occasional Contributor
10 years ago
Hi Mikael,

You are correct. What I did is that I installed an Xvfb Jenkins extension: https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin.
Then part of my Jenkins project steps, I had one step that starts Xvfb.

Build Environment
Start Xvfb before the build, and shut it down after.

After that, I added an "Execute Shell" step where I exported the variables.
export DISPLAY=:1.0
export GDFONTPATH=/opt/SmartBear/LoadUI-2.7.0/jre/lib/fonts

Then I invoked LoadUI and It run okay.

Now, I have only one last question, hopefully
I have been trying to generate the report and then possibly export it to a different machine where I can look at the results but I had no luck. There were no errors but the report is not being generated.
Is that because we are doing a workaround to get LoadUI to work which leads to loosing the possibility to generate a PDF report?

Here is the command I am using:
./loadUI-cmd.sh -p /PROJECT_PATH -L 300:0:0 -r /home/ -F PDF

Again Thanks a lot and I hope that other LoadUI users benefit from this post.
Pat