GitHub actions fail with latest docker image

[smark-1]

Using the ghcr.io/engineer-man/piston:latest image gives me a failed to resolve piston error.

When I switch back to the previous version ghcr.io/engineer-man/piston@sha256:63b5654156a89c5a2ad281aface21416615d62ec056d88efe8fcd307ce73575a everything works. Is this a known breaking change? How can I fix to work with latest?

[Brikaa]

Can you show the logs of the docker container? As for breaking changes, you need cgroup2 enabled and cgroup v1 disabled on your Linux system now. Also, the docker container now should be started with the --privileged flag.

[smark-1]

I attached the log although I removed a few details from it. Let me know if you need any more information. actions_log.txt

[petitout]

I also cannot start piston with latest image (even running as root) :

piston mkdir: cannot create directory 'isolate/': Read-only file system

[Brikaa]

You need to give the --privileged option to the docker run command.

On Wed, Sep 11, 2024 at 7:57 PM petitout @.***> wrote:

I also cannot start piston with latest image (even running as root) :

piston mkdir: cannot create directory 'isolate/': Read-only file system

— Reply to this email directly, view it on GitHub https://github.com/engineer-man/piston/issues/684#issuecomment-2344196268, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJUO4FAECFCGLQGT5V4GVPTZWBY7ZAVCNFSM6AAAAABN3MIWUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBUGE4TMMRWHA . You are receiving this because you commented.Message ID: @.***>

[Brikaa]

@smark-1 have you made sure the container is run in the actions as a privileged container? I.e, with the privileged flag in docker run or the privileged property in docker compose?

[smark-1]

I haven't had a chance to fully test out the new version. I added privileged: true in the docker compose file. With limited testing it appears to work.

[smark-1]

I just tried it now using docker compose in wsl2 it no longer works. For example if I run

The piston service in the docker compose looks like this:

  piston:
    restart: "no"
    image: 'ghcr.io/engineer-man/piston@sha256:5ea5c0f9d6a2daa89e71b76694aef27b372e8dd334d549fdd20b9e8838518077'
    privileged: true
    ports:
      - "2000:2000"
    volumes:
      - piston:/piston

I sent the following request to piston:

post localhost:2000/api/v2/execute

{
  "language": "py",
  "version": "3.12.0",
  "files": [
    {
      "name": "main.py",
      "content": "print('works')"
    }
  ]
}

And it returned:

{
  "run": {
    "signal": null,
    "stdout": "",
    "stderr": "Cannot write /sys/fs/cgroup/isolate/box-31/cgroup.procs: No such file or directory\n",
    "code": null,
    "output": "Cannot write /sys/fs/cgroup/isolate/box-31/cgroup.procs: No such file or directory\n",
    "memory": null,
    "message": "Cannot write /sys/fs/cgroup/isolate/box-31/cgroup.procs",
    "status": "XX",
    "cpu_time": null,
    "wall_time": null
  },
  "language": "python",
  "version": "3.12.0"
}

[smark-1]

Update: Adding

[wsl2]
kernelCommandLine = cgroup_no_v1=all

to the %UserProfile%\.wslconfig file and restarting wsl fixed the issues.

As in https://stackoverflow.com/a/73376219/14665310

[smark-1]

Although invalid code runs no longer have a signal of SIGKILL and has changed to null

[smark-1]

With this new response format how can I detect the reason for the code being killed (time/output limit)?

[Brikaa]

It should tell you explicitly now in the message and status fields. Maybe we should add SIGKILL on timeout for backward compatibility.

[smark-1]

Everything is functioning properly for me now, so I'll go ahead and close this issue. However, given the significant changes in the latest update, I think there should be release notes or an update guide outlining what has changed.