Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

code prints to stderr #118

Open
brydling opened this issue May 24, 2023 · 3 comments · May be fixed by #138
Open

code prints to stderr #118

brydling opened this issue May 24, 2023 · 3 comments · May be fixed by #138

Comments

@brydling
Copy link

brydling commented May 24, 2023

The 'code' command recently started printing the following line to stderr when run through sudo:
mkdir: cannot create directory ‘’: No such file or directory

This can be recreated by executing sudo -u $USER code --list-extensions giving the output

mkdir: cannot create directory ‘’: No such file or directory
coolbear.systemd-unit-file
cschlosser.doxdocgen
jeff-hykin.better-cpp-syntax
...

This results in this ansible role failing because of checks like this:

rc, out, err = module.run_command([executable, '--list-extensions', name])
    if rc != 0 or err:

By replacing the condition with if rc != 0 or (err and 'No such file or directory' not in err): (and similar for the other places where erris checked) the role works as expected again.

I am on Ubuntu 22.04 using the snap version of VS Code.

I just tried to remove the snap version and install the apt version instead (from Microsofts apt repo). The problem disappeared. I will switch to the visual-studio-code role instead to get the apt version installed automatically.

@lifeisafractal
Copy link
Contributor

I also ran into this somewhere between Ubuntu 20.04 and 23.04, although I'm installing VSCode from Snap so it likely has more to do with the VSCode version and not Ubuntu version. I narrowed it down to the environment variable XDG_RUNTIME_DIR not being set. As a work around for now I set it in the role as follows:

    - role: gantsign.visual-studio-code-extensions
      become: true
      environment:
        # workaround so this role works. VSCode will dump errors without this env var set
        # this is a hack as the UID is hard coded. Consider opening a PR upstream
        XDG_RUNTIME_DIR: "/run/user/1000"
      users:
        - username: "{{ ansible_user_id }}"
          visual_studio_code_extensions:
            - eamodio.gitlens
            [...]

This is obviously not a robust solution for a few reasons but this should fix it for people if they want a work around. Issues with this fix:

  1. This hard codes the UID of the target user.
  2. I don't know enough about XDG and that particular var to know if that is to be counted on as a robust solution (relying on /run/user as a good base for XDG_RUNTIME_DIR in all cases.
  3. Requiring users of an Ansible role to set env vars seems a little clunky.

Some thoughts on more robust ways to deal with this:

  1. Rather than going to /run/user/..., create a new folder in /tmp with correct ownership and permissions (see https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables )
  2. Count on /run/user/, but dynamically check the UID of the target user and set that in there. (Not sure if this is a good idea).
  3. Use become_method: machinctl as suggested here. This requires installing extra dependencies which is kind of annoying.
  4. Some other more sanctioned method of populating XDG_RUNTIME_DIR dynamically based on the target user.

This role is using AnsibleModule.run_command which can be passed in extra env vars to set in the context for running programs (https://docs.ansible.com/ansible/latest/reference_appendices/module_utils.html). Again, not sure if that's the best way to handle this, but that would make a pretty easy and opaque fix for users of this role.

@C0rn3j
Copy link
Contributor

C0rn3j commented Feb 8, 2024

Why on earth is any STDERR output treated as a hard error?

Passing any flags to VSC that are for Chromium/Electron will fail this alone irregardless of RC, so good luck having any global Electron/Chromium configs.

If this was implemented because VSC does not always throw an error code on an error, file that upstream, don't try to work around it downstream.

[0] % code --ozone-platform=wayland --list-extensions > /dev/null
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.

[0] % 

@C0rn3j C0rn3j linked a pull request Feb 8, 2024 that will close this issue
@C0rn3j
Copy link
Contributor

C0rn3j commented Feb 9, 2024

@brydling @lifeisafractal

Please try to reproduce this on current VSC and extension.

If you are able to, please post your full playbook and how you're launching it, output with -vvv (please wrap with <details>triple backticked content</details>).

Afterwards manually apply #138 and once again post -vvv from that - post it even if that PR fixes your issue, it would be nice to confirm it works fine.

Are you sure you need become? This is my role.

- name: Install Visual Studio Code extensions
  ansible.builtin.include_role:
    name: gantsign.visual-studio-code-extensions
  vars:
    visual_studio_code_extensions_build: oss
    users:
      - username: '{{ username }}'
        visual_studio_code_extensions:
          - redhat.ansible               # Ansible support
          - vsciot-vscode.vscode-arduino # Arduino
          - ms-vscode.cpptools           # C/C++
          - hediet.vscode-drawio         # Draw.io Integration
          - eamodio.gitlens              # GitLens
          - oderwat.indent-rainbow       # ident-rainbow
          - timonwong.shellcheck         # shellcheck
          - simonsiefke.svg-preview      # SVG preview
        visual_studio_code_extensions_absent:
          - simonsiefke.svg-preview      # Test removing an already installed thing
          - zbr.vscode-ansible           # Test removing a thing not installed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants