Service is not being created

[gvarph]

This does not seem to work on NixOS unstable. When I when I rebuild nixos with

  imports = [
        (fetchTarball "https://github.com/nix-community/nixos-vscode-server/tarball/master")
  ];
  services.vscode-server.enable = true;

in my configuration.nix, it builds without an issue. However, it seem that the service is not being created. I know this configuration should work because it worked for a while before I updated my packages, rebooted my server and could not start the service again

✦ ❯ systemctl --user enable auto-fix-vscode-server.service
Failed to enable unit: Unit file auto-fix-vscode-server.service does not exist.

[xyven1]

I am in the same situation. I could probably do a git bisect on my config and figure out what update broke things, but that is not very enticing.

[jjamesmartiin]

I'm in a similar boat. I discovered the the service is being made and enabled, but the "state" is bad.

I can view the systemd service file at /etc/systemd/user/auto-fix-vscode-server.service but when running systemctl --user list-unit-files | grep auto-fix-vscode-server I can see the bad state.

[qknight]

@gvarph i restarted the nixos WSL guest and afterwards it was working. so might be a first-time deployment thing. didn't check the logs so can't tell what is going on.

[jmatsushita]

I also get the bad state when checking list-unit-files but running the binary manually works around the problem for now. I'm not sure what's wrong with the service, so here's what I have:

> more /etc/systemd/user/auto-fix-vscode-server.service
[Unit]
Description=Automatically fix the VS Code server used by the remote SSH extension

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/3pd6pf95h3fsgq8w0wj4nv7s9fn98zyp-glibc-locales-2.38-44/lib/locale/locale-archive"
Environment="PATH=/nix/store/mb488rr560vq1xnl10hinnyfflcrd51n-coreutils-9.4/bin:/nix/store/rr5pqqck5f6fjkv7agwjyhaljvh27ncn-findutils-4.9.0/bin:/nix/store/320v66ili0mwnyrxj3dwbxm0z8ndkbw7-gnugrep-3.11/bin:/nix/store/q7kq0naays5251ihghw0ccsz39id7kk5-gnused-4.9/bin:/nix/store/klc3y2c97sc22wsv1cjwf4dfwcws095l-systemd-255.2/bin:/nix/store/mb488rr560vq1xnl10hinnyfflcrd51n-coreutils-9.4/sbin:/nix/store/rr5pqqck5f6fjkv7agwjyhaljvh27ncn-findutils-4.9.0/sbin:/nix/store/320v66ili0mwnyrxj3dwbxm0z8ndkbw7-gnugrep-3.11/sbin:/nix/store/q7kq0naays5251ihghw0ccsz39id7kk5-gnused-4.9/sbin:/nix/store/klc3y2c97sc22wsv1cjwf4dfwcws095l-systemd-255.2/sbin"
Environment="TZDIR=/nix/store/iq0aigzp8b381hzn3bp9yivpm2hgg25p-tzdata-2024a/share/zoneinfo"
ExecStart=/nix/store/qmn4pdcrij1nhi5qns1ck26sklmgkqx6-auto-fix-vscode-server/bin/auto-fix-vscode-server
Restart=always
RestartSec=0

[Install]
WantedBy=default.target

[julius-boettger]

I'm still running into this issue, any updates?

To quickly run the binary manually I use

sh -c $(grep 'ExecStart=' /etc/systemd/user/auto-fix-vscode-server.service | sed 's/^ExecStart=//')

[adrblo]

I ran into the same issue after some time of using it. It works again after recreating the symlink according to the README:

Enabling the user service creates a symlink to the Nix store, but the linked store path could be garbage collected at some point. One workaround to this particular issue is creating the following symlink:

ln -sfT /run/current-system/etc/systemd/user/auto-fix-vscode-server.service ~/.config/systemd/user/auto-fix-vscode-server.service

and then running systemctl --user start auto-fix-vscode-server.service