PowerShell Core cannot start a PS Job in .NET Core SDK Alpine image

[jeepingben]

Describe the bug

There appears to be a regression of issue #1922

docker run  -it --rm mcr.microsoft.com/dotnet/sdk:9.0-alpine pwsh -Command "& { Start-Job { 'test' } | Receive-Job -Wait }"
OpenError: [localhost] An error occurred while starting the background process. Error reported: An error occurred trying to start process '/usr/share/powershell/.store/powershell.linux.alpine/7.5.3/powershell.linux.alpine/7.5.3/tools/net9.0/any/pwsh' with working directory '/'. No such file or directory.
[user@umwey6bv docker-ci-powercli]$ 

[admin@tenable-umwey6bv docker-ci-powercli]$ docker run  -it --rm mcr.microsoft.com/dotnet/sdk:8.0-alpine pwsh -Command "& { Start-Job { 'test' } | Receive-Job -Wait }"
OpenError: [localhost] An error occurred while starting the background process. Error reported: An error occurred trying to start process '/usr/share/powershell/.store/powershell.linux.alpine/7.4.12/powershell.linux.alpine/7.4.12/tools/net8.0/any/pwsh' with working directory '/'. No such file or directory.
[user@umwey6bv docker-ci-powercli]$ 

The fix shown in the declined PR for issue 1922 (replacing $PSHOME/pwsh with /usr/bin/pwsh) fixes the issue for me

Which .NET image(s) are you using?

mcr.microsoft.com/dotnet/sdk 8.0-alpine 2827d64f3133

Steps to reproduce

docker run -it --rm mcr.microsoft.com/dotnet/sdk:9.0-alpine pwsh -Command "& { Start-Job { 'test' } | Receive-Job -Wait }"

docker run -it --rm mcr.microsoft.com/dotnet/sdk:8.0-alpine pwsh -Command "& { Start-Job { 'test' } | Receive-Job -Wait }"

Other information

No response

Output of docker version

Client: Docker Engine - Community
 Version:           28.4.0
 API version:       1.51
 Go version:        go1.24.7
 Git commit:        d8eb465
 Built:             Wed Sep  3 20:59:27 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.4.0
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.7
  Git commit:       249d679
  Built:            Wed Sep  3 20:56:49 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.7.28
  GitCommit:        b98a3aace656320842a23f4a392a33f46af97866
 runc:
  Version:          1.3.0
  GitCommit:        v1.3.0-0-g4ca628d1
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info

Client: Docker Engine - Community
 Version:    28.4.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.28.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.39.4
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 27
  Running: 0
  Paused: 0
  Stopped: 27
 Images: 34
 Server Version: 28.4.0
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: b98a3aace656320842a23f4a392a33f46af97866
 runc version: v1.3.0-0-g4ca628d1
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
 Kernel Version: 4.18.0-553.75.1.el8_10.x86_64
 Operating System: Oracle Linux Server 8.10
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.486GiB
 Name: umwey6bv
 ID: 4W3S:ZPHT:RDXV:LCOI:OUCR:HV5E:OBPJ:6HHS:5PXQ:JY3G:NPU5:BKSA
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

[lbussell]

I was able to reproduce this. I suspect it never got truly resolved in the first place.

#1922 was supposedly fixed by PowerShell/PowerShell#19995. However, I'm not sure the new package, powershell-7.*.*-linux-x64-musl-noopt-fxdependent.tar.gz, ever got integrated into the .NET SDK images. I'm not sure if that is what's in PowerShell.Linux.Alpine.7.*.*.nupkg (the package that we consume).

The workaround using Start-ThreadJob instead of Start-Job (as suggested in #1922) still works in the .NET SDK image.

The pwsh binary in powershell-7.*.*-linux-x64-musl-noopt-fxdependent.tar.gz still tries to link to glibc:

$ ldd pwsh 
        /lib64/ld-linux-x86-64.so.2 (0x7df15dc78000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7df15dc78000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7df15dc78000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7df15d9ba000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7df15dc78000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7df15d98e000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7df15dc78000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by pwsh)

In PowerShell.Linux.Alpine.7.*.*.nupkg,

$ ldd /usr/share/powershell/pwsh
        /lib/ld-musl-x86_64.so.1 (0x7c6490c14000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7c6490955000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7c6490929000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7c6490c14000)
$ ldd /usr/share/powershell/.store/powershell.linux.alpine/7.5.3/powershell.linux.alpine/7.5.3/tools/net9.0/any/pwsh    
        /lib64/ld-linux-x86-64.so.2 (0x72878b7b5000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x72878b7b5000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x72878b7b5000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x72878b4f7000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x72878b7b5000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x72878b4cb000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x72878b7b5000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /usr/share/powershell/.store/powershell.linux.alpine/7.5.3/powershell.linux.alpine/7.5.3/tools/net9.0/any/pwsh)

@adityapatwardhan, @TravisEz13, @daxian-dbw, what do you think we can do to resolve this?

[TravisEz13]

@lbussell ThreadJobs have significantly different behaviors.
If we can rely on [System.Environment]::ProcessPath I know where to fix this. Since the file we think should exist, doesn't. I think I can make a targeted fix for that scenario.
cc @adityapatwardhan