0

As the title states, I'm finding that whenever I issue xwininfo -tree on a container running Ubuntu in lambda, there are never child screens, though when I run the same container locally it works fine (listing all the windows used by said application). The issue must lie somewhere from application start and it registering with the X server. Does anyone have any insights here as to what could be going on, or how I can get this to work?

To attach some code to this problem, the gist is essentially:

# Start Xvfb
Xvfb $DISPLAY -screen 0 1920x1080x24 -nolisten tcp -nolisten unix & 

# Open Visual Studio Code (just as an example application)
code .

# List all windows
xwininfo -root -tree

As mentioned, locally xwininfo produces something like this:

Root window id: 0x50d (the root window) (has no name)
Parent window id: 0x0 (none)
   6 children:
   0x600006 "Code": ("code" "Code")  800x600+560+240  +560+240
   0x600002 "Get Started - src - Visual Studio Code": ("code" "Code")  1024x768+448+156  +448+156
   0x600003 (has no name): ()  1x1+0+0  +0+0
   0x800003 "code": ("code" "Code")  200x200+0+0  +0+0
      1 child:
      0x800004 (has no name): ()  1x1+-1+-1  +-1+-1
   0x800001 "code": ("code" "Code")  10x10+10+10  +10+10
   0x600000 "Chromium clipboard": ()  10x10+-100+-100  +-100+-100

but in lambda, the output only shows the root window, with no children:

Root window id: 0x50d (the root window) (has no name)
Parent window id: 0x0 (none)
   0 children.

What could be going on here? Why are my application windows not appearing in the output of xwininfo -tree?

fullStackChris
  • 1,300
  • 1
  • 12
  • 24
  • Why is this tagged with `amazon-ecs` if you are running the container in Lambda? – Mark B Dec 10 '22 at 13:08
  • My apologies, I got it confused with ECR, which is where the image is stored. – fullStackChris Dec 10 '22 at 13:32
  • 1
    So you try to run an XServer on a container in AWS lambda? Does not the XServer need some kind of a display for rendering? Can you explain what your lambda function should do? At least for me, this looks confusing. – petrch Dec 10 '22 at 14:08
  • @fullStackChris Can you please explain what you’re trying to achieve, ultimately? Lambda is a server-side technology and there are no screens or anything available. Are you trying something like headless rendering? – lxg Dec 10 '22 at 15:32
  • Yes, I'm combining xvfb with ffmpeg to record automated workflows, namely I'm opening Visual Studio Code and typing some code in. I know that there is no monitor hardware attached to a lambda function, that's where xvfb comes in, it uses a memory buffer in place of a physical monitor. Again, all this works when I run the container locally, which leads me to beleive the difference in expected behaviour has something to do with the lambda architecture. – fullStackChris Dec 10 '22 at 16:02
  • Getting closer to answering this, it appears to be a Visual Studio Code issue, as suspected, due to differences in lambda environment, running code with `--verbose` is showing me errors, and thus why the window never opens or appears in the output of `xwininfo` – fullStackChris Dec 13 '22 at 08:59

1 Answers1

0

This is a sort of half answer in that I'm unable to definitely solve the root cause of the original question, but it's an answer that explains tells why Visual Studio Code fails to launch (and does not appear in xwininfo). If you pass the --verbose flag to Visual Studio code when it launches, in a Lambda environment, you'll get output like this:

prctl(PR_SET_NO_NEW_PRIVS) failed

prctl(PR_SET_NO_NEW_PRIVS) failed

Unable to create argv.json configuration file in /home/sbx_user1051/.vscode/argv.json, falling back to defaults (Error: ENOENT: no such file or directory, mkdir \'/home/sbx_user1051/.vscode\')
[94:1213/213845.593392:ERROR:bus.cc(398)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[94:1213/213845.593463:ERROR:bus.cc(398)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[94:1213/213845.626853:ERROR:bus.cc(398)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
[94:1213/213845.626936:ERROR:bus.cc(398)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
[94:1213/213845.671433:WARNING:bluez_dbus_manager.cc(248)] Floss manager not present, cannot set Floss enable/disable.
[94:1213/213845.671514:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213845.671522:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 1 time(s)
[94:1213/213845.672685:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213845.672708:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 2 time(s)
[94:1213/213845.688115:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213845.688143:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 3 time(s)
[94:1213/213845.689768:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213845.689790:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 4 time(s)
[94:1213/213845.690646:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213845.690662:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 5 time(s)
[94:1213/213846.470027:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213846.470054:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 6 time(s)
[94:1213/213846.471084:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213846.471101:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 7 time(s)
[94:1213/213846.471742:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213846.471761:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 8 time(s)
[94:1213/213846.472344:ERROR:gpu_process_host.cc(974)] GPU process launch failed: error_code=1002
[94:1213/213846.472357:WARNING:gpu_process_host.cc(1282)] The GPU process has crashed 9 time(s)
[94:1213/213846.472371:FATAL:gpu_data_manager_impl_private.cc(450)] GPU process isn\'t usable. Goodbye.

The problem is that even though Visual Studio Code is built on Electron / Chromium, it doesn't seem to support a --headless option yet (as apposed to something like Chrome, which is possible to launch in a Lambda function with some careful tinkering). So, due to the restrictions of the Lambda environment, for now, it seems that it's not possible to Launch Visual Studio code in a lambda environment. (I know there is the web version, but I don't want this). Would have been nice as a single instance per call would have been perfect for what I was trying to accomplish. I'm going to move on to some other backend infrastructure to do what I want...

fullStackChris
  • 1,300
  • 1
  • 12
  • 24