Could you also post the contents of the template/script.sh.erb as well?
submit.yml.erb.txt (1.7 KB)
Thatās the submit.yml.erb which I grabbed before, I was looking to check the template/script.sh.erb file in the app.
script.yml.erb.txt (864 Bytes)
Looking at the output.log file, the command xfwm4 --compositor=off --daemon --sm-client-disable from the script.sh.erb doesnāt look like it ever actually executes.
But, we do see some execute mainly those xfsettingsd commands. I donāt see the xfsetroot either in the output.log.
So, now the question is why specifically is the window manager not executing. I would think weād see error or warning messages there if the executable was outright missing, but that doesnāt look to happen.
Iād recommend reintalling xfce possibly, because other than that Iām not sure why the command isnāt actually executing since some commands run, and some donāt.
Iām not sure that will help and here is why. We use xcat to create images for all of our cluster nodes. Every three months or so we download all the new repos and create new images for each class of compute node. When the compute nodes boot that image stays resident in memory not using the local disk at all except for things like tmp var/log and var/tmp which are on disk. So can we look at a different solution? Could you tell me which executables are not executing and I can look to see why that is.
Itās the actual command to start the window manager, doesnāt look like anything happens in the output.log
For instance, looking at my own comsol session that ran, if I check my output.log I see this:
Currently Loaded Modules:
1) xalt/latest 2) comsol/5.5
+ comsol -3drend sw
+ xfwm4 --compositor=off --daemon --sm-client-disable
...
But that xfwm4 command never looks to execute based on your output.log which has me thinking it is either not installed or installed wrong somehow.
You could include a command in the script.sh.erb to query whether the xfwm4 package is even there and see that in the output.log because that would let you know if itās at least there or not.
Interesting because it is on the servers in /usr/bin.
When I try to run it by hand on the command line I get an error:
xfwm4: Unknown option --daemon.
Type āxfwm4 --helpā for usage.
I removed the --daemon option in my sandbox copy of the app and it works.
1 Like
I have the same problem. Unfortunately removing the --daemon option does not work for me: without it I get the following:
Script starting...
Generating connection YAML file...
The system default contains no modules
(env var: LMOD_SYSTEM_DEFAULT_MODULES is empty)
No changes in loaded modules
+ xfwm4 --compositor=off --sm-client-disable
(xfwm4:156542): Gtk-WARNING **: 13:28:53.092: cannot open display:
+ xsetroot -solid '#D3D3D3'
xsetroot: unable to open display ''
+ xfsettingsd --sm-client-disable
Unable to init server: Could not connect: Connection refused
(xfsettingsd:156544): xfsettingsd-ERROR **: 13:28:53.106: Unable to open display.
Currently Loaded Modules:
1) Comsol/6.1
(and a bunch of other Unable to init server: Could not connect: Connection refused which Iām sure depend on this first one).
Running the whole XFCE desktop standalone and launching Comsol (or anything else) there works just fine, but itād be slick for my users to have the option of this connector.
I looked at all the other single-app thing and they all have this same --daemon option, which is not clear why our version of it doesnāt (FWIW, my version does not even has the --help option, despite what the message say ā Iām running the semi-official EPEL version from RH)
EDIT: canāt we configure OOD to sidestep XFCE and use only TurboVNC as described at Can we run TurboVNC without showing the desktop? Ā· Issue #139 Ā· TurboVNC/turbovnc Ā· GitHub ?
We are running RHEL 8 so it may not have been removed from the version you are using.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.