[Bug]: Docker is misdetected on Arch Linux because agent cmd.Which() depends on external `which`

[lurkerlin]

Contact Details

No response

1Panel Version

v2.1.10

Problem Description

On Arch Linux, 1Panel incorrectly reports that Docker is not installed / not detected, even though Docker is installed and running normally.

The backend API /api/v2/containers/docker/status returned:

{"code":200,"message":"","data":{"isActive":false,"isExist":false}}

But on the same host:

• docker.service was active
• docker version worked normally
• /var/run/docker.sock existed and was accessible
• docker compose version worked normally

The root cause is in the agent implementation:

• agent/app/service/docker.go -> LoadDockerStatus()
• agent/utils/cmd/cmd.go -> Which()

LoadDockerStatus() first checks cmd.Which("docker").
Which() is implemented as shelling out to:

which docker

On this Arch Linux host, docker existed at /usr/bin/docker, but there was no usable which executable in the runtime environment used by 1panel-agent.
So Which("docker") returned false, and 1Panel incorrectly marked Docker as not existing.

Creating a simple compatibility script at /usr/local/bin/which immediately fixed detection, and the backend API changed to:

{"code":200,"message":"","data":{"isActive":true,"isExist":true}}

Steps to Reproduce

1. Install 1Panel v2.1.10 on Arch Linux
2. Install and start Docker normally
3. Ensure docker is available (for example at /usr/bin/docker)
4. Open 1Panel container-related pages
5. 1Panel reports that Docker is not detected / not installed

The expected correct result

1Panel should detect Docker correctly as long as the docker binary is available in PATH and the Docker client/daemon are reachable.

Related log output

Earlier logs also showed this during diagnosis:

Docker Compose command not found, please install Docker Compose Plugin

That part was solved separately by making Compose discoverable for the service environment.

The remaining Docker detection issue was specifically caused by cmd.Which() depending on the external which command.

Suggestions

Please avoid using shell which for command existence checks.
A more robust fix would be to replace it with Go-native lookup such as exec.LookPath("docker"), or use command -v in a controlled shell.

Current implementation:

func Which(name string) bool {
    stdout, err := RunDefaultWithStdoutBashCf("which %s", name)
    if err != nil || (len(strings.ReplaceAll(stdout, "\n", "")) == 0) {
        return false
    }
    return true
}

This is fragile on distributions/environments where which is not installed or not available to the service process.

Additional Information

Environment where this was reproduced:

• OS: Arch Linux
• 1Panel: v2.1.10 stable
• Docker: running normally
• 1panel-agent internal API before workaround: isActive:false, isExist:false
• 1panel-agent internal API after adding /usr/local/bin/which: isActive:true, isExist:true

[wanghe-fit2cloud]

感谢反馈，我们会在后续版本持续优化相关兼容性问题。