OOD interactive desktop Xfce4 desktop lock screen-timeout and disable lock screen option under user menu

Dear community,

I got the interactive desktop session working on OOD 2.0 on the xfce4 vnc session. But one problem I am running into, screensaver timeout, or the user might lock their screen. How to disable it since the vnc password doesn’t work once the screen is locked after timeout?

Any suggestions to disable the lock-screen option and timeout are appreciated.

Hi and welcome!

The best practice here is to naviagate back to Open OnDemand → My Iterative Sessions → click to reconnect to the session. The desktop session will be there just as you left it.

Timeouts, though annoying, are good for all sorts of reasons. So I’d maybe avoid that route and instead just navigate back.

Hope that helps!

Thanks @jeff.ohrstrom for your reply.

We usually allow users to run interactive desktop for a couple of hours. Some of our users have left their desktop session running and went away from the keyboard. Once they come back, XFCE has a screen lock and asks them for a password. If they close the window and try to reconnect as you mentioned then get an authentication error. (See my screenshots attached)

@jeff.ohrstrom After digging around on this discourse. I think we are having similar issues as
noVNC and shell session timeout after 1 minute this thread.

We are on OnDemand version: v2.0.18

I think this is a configuration issue with XFCE itself. Maybe I’m missing something, but that seems like where your problem is coming from.


$ sudo dnf remove xfce4-screensaver

solve the problem?

Hello @bennet,

Ya, I think the screensaver issue would be resolved with that. And also just disabling that process on startup solves that as well.

Do you have any other suggestions for keeping the VNC session reconnectable? Since my users are unable to reconnect their VNC sessions similar to the thread I mentioned earlier.
Thanks for your feedback.

We’ve not had any issues reconnecting. We are at OnDemand 1.8, though, so if something changed for 2.0 that might be different.

I just started a session. I’ll check back in a couple of hours after disconnecting.

Unless you are referring to an ssh timeout for a console, which would be a different setttting.

@bennet we are having issues with basically re-connecting the VNC session. At the reconnecting of the session, we get the error, Authentication failed as shown in the screenshot.

SSH timeout is not an issue for us.

Hello @jeff.ohrstrom and @bennet

I think I narrowed out our problem. Basically, I looked at the connections.yml file for the password
and if I edit the VNC connection join hyperlink then I am able to connect it.

But for some reason Launch VNC session button link is not reflecting the new password from the interactive desktop card.
vnc.log for more info

18/11/2021 11:30:28 Got connection from client
18/11/2021 11:30:28 Using protocol version 3.8
18/11/2021 11:30:28 Enabling TightVNC protocol extensions
18/11/2021 11:30:28 Advertising Tight auth cap ‘VENCRYPT’
18/11/2021 11:30:28 Advertising Tight auth cap ‘VNCAUTH_’
18/11/2021 11:30:28 Advertising Tight auth cap ‘ULGNAUTH’
18/11/2021 11:30:28 rfbVncAuthProcessResponse: authentication failed from
18/11/2021 11:30:28 Client gone
18/11/2021 11:30:28 Statistics:

Which VNC client/server are you using? I think it needs to be TurboVNC everywhere. Any chance that the server is falling back to a different VNC server?

Yes, I am using /opt/TurboVNC/bin recommended by the installation guide.

I’m out of ideas. Sorry!


That’s no problem at all. Thanks for your help.

I will try to schedule a meeting with perhaps the OOD developer/support team and see if they can help us with this issue.


First of it’s important to know that this password is a 1 time use password. As soon as you use it, we generate a new one and put it in the connection.yml. So this can happen as many times over the lifetime of the job.

Did you happen to set POLL_DELAY? If you have the right information in the connection.yml then it should get reflected in the card. The question then becomes - how often is the file read (determined by POLL_DELAY which I think is 30 seconds). And where did you read the connection.yml and observe that it had a new password. Perhaps theres a sync issue where the compute node updated the file but the web node (where OnDemand is deployed) is unable to see the updated file due to NFS latency.

I have not seen the setting for POLL_DELAY yet, where should I find that?

I basically went inside the ondemand session interactive destop creates. Then I copied the password generated by connection.yml then edit the hyperlink generated by VNC session and I was able to reconnect to my running VNC session.

However the problem is, upon refresh of the interactive desktop under my sessions card, join button is not getting that changed password, it still shows uses old password in hyperlink hence we get authentication error upon trying to reconnect VNC session.

Directory /home/bch229/ondemand/data/sys/dashboard/batch_connect/sys/bc_desktop/mcc/output/
[bch229@mcc-login001 92def0b6-3927-4cb6-96ea-84d377e94d11]$ cat connection.yml
host: frome001
port: 5905
password: TzGx5oFZ
display: 5
websocket: 28459
spassword: rlyclcPV
[bch229@mcc-login001 92def0b6-3927-4cb6-96ea-84d377e94d11]$ cat connection.yml
host: frome001
port: 5905
password: VT2RTNGN
display: 5
websocket: 28459
spassword: rlyclcPV

See what the connection.yml file is from the node that run OnDemand. Does it’s filesystem reflect the same file content?

Sure, I can look into ondemand node. Do you know where it gets generated? Meaning directory path on ondemand node?

Same path. It’s written entirely during the compute job. It’s not clear why it’d be able to read it once, but not the second time.


You are right, as we mount GPFS over NFS on Ondemand node but computes directly mount GPFS.

There is bit mismatch going on with connection.yml credentials

spassword: OXGiEkfP
[bch229@ondemand 125a0091-8011-4f7c-b72b-16744641ddae]$ cat connection.yml
host: frome001
port: 5905
password: A0vu8Kpy
display: 5
websocket: 21809
spassword: OXGiEkfP

[bch229@mcc-login001 125a0091-8011-4f7c-b72b-16744641ddae]$ cat connection.yml
host: frome001
port: 5905
password: sldoHd5b
display: 5
websocket: 21809
spassword: OXGiEkfP

Could that be a permissions issue? Would the update possibly change the permissions from those that were in effect when the file is first created? If so, then perhaps a group read permission is being removed, or an ownership change is (or is not) happening that should not (should)?