[windows self-hosted] Running as a service doesn't include user PATH env var

[milesj]

Describe the bug I've been trying to setup my own windows self-hosted runners for a while now, but every attempt always ran into the same issue: rustup could not be found. For context, Rust installs all of it's tools to ~/.cargo/bin and ~/.rustup. Both of these paths are in the user's PATH environment variable:

echo $env:PATH
C:\Program Files\PowerShell\7;C:\Program Files\Git\cmd;C:\Program Files\Git\bin;C:\ProgramData\chocolatey\bin;C:\Program Files\nodejs\;C:\Program Files\Amazon\cfn-bootstrap\;C:\Program Files\PowerShell\7\;C:\Python311\Scripts\;C:\Python311\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\Administrator\.cargo\bin;C:\Users\Administrator\AppData\Local\Microsoft\WindowsApps;C:\Users\Administrator\AppData\Roaming\npm

But when steps are ran from the context of a runner, all the PATHs in the user directory are missing. It only includes the system PATH environment variable.

echo $env:PATH
C:\Program Files\PowerShell\7;C:\Program Files\Git\cmd;C:\Program Files\Git\bin;C:\ProgramData\chocolatey\bin;C:\Program Files\nodejs\;C:\Program Files\Amazon\cfn-bootstrap\;C:\Program Files\PowerShell\7\;C:\Python311\Scripts\;C:\Python311\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\WindowsApps

I've gone crazy over trying to figure this out. Is it windows security settings? Permission issues? The runner using a different user? The runner misconfigured (everything passed)? Restarting the service. Rebooting the windows OS. So on and so forth.

But I finally figure out the problem. Running the runner as a service does not include the user PATH env var, only system PATH. However, if I stop the service and run ./run.cmd manually from powershell, everything works accordingly!

To Reproduce Steps to reproduce the behavior:

1. Setup the runner
2. Run ./configure.cmd and when it prompts to start as a service -> Yes
3. Run a job that requires bins found on user's PATH

Expected behavior Running the runner as a service includes user PATH env var.

Runner Version and Platform

Version of your runner? 2.303.0

OS of the machine running the runner? Windows server 2022 64-bit

What's not working?

Please include error messages and screenshots.

Job Log Output

N/A

Runner and Worker's Diagnostic Logs

N/A

[malkir]

The environment is likely lost when the subprocess is kicked off by the runner. Possibly try something like:

jobs: 
  build:
    runs-on: windows-latest
    steps:
      - run: |
        echo "C:\some\dir" >> $GITHUB_PATH

[AF250329]

I am not sure why it is a bug ?? It seems "working as expected". Github Runner application started from Windows Service. Usually it is done to assign more privileges to process (running it as SYSTEM or Windows build-in account that has more access rights than regular user). This is most popular practice.

In your case - yes ! it is running in different account <- very popular practise. Just scroll on your services in your Windows and check what it user account that running it. It is never defined 'user' of some kind.

If you insist to set up your account as a 'running' account for Windows Service you could just right mouse click on it and select 'Properties' then click on 'Log On' on the top and in the middle of the screen switch to 'This account' and enter any credentials that you want.

According to your questions I understand that you are not very familiar with Windows Services and why they actually exist. So here I just want to warn you:

1. Never delete this user account that you enter into Windows Service - it could lead to hard to catch errors and silent shutdowns
2. It will be troublesome to diagnose access denied errors in case your account miss configured for the mission
3. Other errors that could occur when Windows Service depend on something or you will need to update it some day

[jun2zhou]

I had been suffering this issue on my self-hosted win11, and win2019 runners, but it is ok on the win2022 runner. finally I got a solution, set all the necessary env variables in the .env file, the issue gone. looks like some of the path variables need much buffer length for passing.

[bryanmacfarlane]

Correct, running as a service was the reason we initially added support for the .env file. Since a service can run as a service account and not your logged in account, it was a way to bootstrap the environment after the service started up the runner listener.

[pastre]

I'm sorry, but where do you create the .env file?

[jun2zhou]

under your runner folder, check the doc here: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-a-proxy-server-with-self-hosted-runners

[pastre]

Huh, apparently wasn't being picked up by macos. On the current version, though, it loads the $PATH variable from a local .path file - I've just written my path there and it works now :D

[oNaiPs]

@milesj I had the same problem today and was able to solve it using --windowslogonaccount and --windowslogonpassword when running config. It will run the service as a real user, and inherit the user PATH as you require.