nesi / nesi-virtual-desktops Goto Github PK

groups $USER | tr ' ' '\n' | tail -n +3 | grep -v -- - | grep -v $USER

One less warning

Command runs fine on cluster.
Server starts fine, websocket starts fine.
Black screen after clicking the 'connect' button in web browser.

Create a config file that sets up modules to load, paths to mount and icons to create.

Should be easy to hide, but would be good to know the cause beforehand.

Possibly since the slurm upgade, eg sbatch:

sbatch: error: plugin_load_from_file: dlopen(/opt/slurm/lib64/slurm/cli_filter_lua.so): liblua-5.1.so: cannot open shared object file: No such file or directory
sbatch: error: Couldn't load specified plugin name for cli_filter/lua: Dlopen of plugin file failed
sbatch: error: cannot create cli_filter context for cli_filter/lua
sbatch: fatal: failed to initialize cli_filter plugin

in the container we have /lib64/liblua-5.3.so but slurm is looking for liblua-5.1.so

Looks like websocket is being initialised twice, then failing the second time?
Gets around the usual port checking by getting a free port, then failing.

WebSocket server settings:
  - Listen on localhost:56703
  - Web server. Web root: /opt/noVNC
  - No SSL/TLS support (no cert file)
  - proxying from localhost:56703 to :66424
  - Navigate to http://localhost:56703 in web browser to connect
  - Press 'Ctrl + C' to close connection ( Note: VDT instance not persistent )
WebSocket server settings:
  - Listen on localhost:56703
  - Web server. Web root: /opt/noVNC
  - No SSL/TLS support (no cert file)
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/opt/websockify/websockify/__main__.py", line 4, in <module>
    websockify.websocketproxy.websockify_init()
  File "/opt/websockify/websockify/websocketproxy.py", line 701, in websockify_init
    server.start_server()
  File "/opt/websockify/websockify/websockifyserver.py", line 704, in start_server
    lsock = self.socket(self.listen_host, self.listen_port, False,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/websockify/websockify/websockifyserver.py", line 470, in socket
    sock.bind(addrs[0][4])
OSError: [Errno 98] Address already in use

Happens during first connection only.

After making a new desktop and killing the connection with ctrl + c, attempting to re-connect will lead to a blank screen when connecting to noVNC.

If websocket is killed manually (using pkill for example) connection can be re-established without a problem. Also, all subsequent times socket is killed with ctrl + c will not cause an issue.

Suspect some element of the container is being lumped in the parent process. Subsequent connections do-not cause this to happen as they are a different process.

Hi,

It seems that the desktop locks itself after some inactivity. However it is not clear which password should be used to unlock it.
I didn't manage to unlock it with my NeSI password (it may be me typing the wrong one 😅). Please could you document which password to use. Thank you :).

Close the warning

Currently, if container specified in image overwrite doesn't exist, or isn't readable vdt session will hang and use won't know anything went wrong unless they read the logs.

Steps to reproduce.
Connect through icon.
Top right, click log out.
Try connect through icon again.

'GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: User of caller and user of subject differs.' on startup

Contents of home directory can cause unreliable behavior.

Advantages of setting HOME to be equal to somewhere inside the container.

• Can deliver already set up desktop.
• Same experience for everyone
• Easier to maintain.

Advantages of using a persistent overlay for HOME.

• User can modify desktop env.
• Will not interfere with regular home.

Not strictly a kenral. move to its own category if possible

https://nesi.slack.com/archives/CNB5QUEQ5/p1652998664335079?thread_ts=1652407669.439419&cid=CNB5QUEQ5

Steps to repeat

glxinfo

as per Maxime

https://github.com/TurboVNC/turbovnc/blob/main/ChangeLog.md

I think it ships with noVNC now, and possibility no websockify required?
Also adds clipboard support.

Seems to happen to about 1 in 20 attempts to connect.

From user with this issue.

[I 2023-09-26 14:11:39.408 SingleUserLabApp log:189] 101 GET /user/*/vdt/vnc.html (@::ffff:130.195.253.20) 1.65ms
[I 2023-09-26 14:11:39.408 SingleUserLabApp handlers:447] Trying to establish websocket connection to ws://localhost:60075/vnc.html
[I 2023-09-26 14:11:39.419 SingleUserLabApp handlers:454] Websocket connection established to ws://localhost:60075/vnc.html
127.0.0.1 - - [26/Sep/2023 14:11:39] 127.0.0.1: Plain non-SSL (ws://) WebSocket connection
127.0.0.1 - - [26/Sep/2023 14:11:39] 127.0.0.1: Path: '/vnc.html'
127.0.0.1 - - [26/Sep/2023 14:11:39] connecting to: :43889
127.0.0.1 - - [26/Sep/2023 14:11:39] Failed to connect to :43889: [Errno 111] Connection refused

Problem is fixed with a jupyter session restart.