Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable process cleanup #598

Closed
patrickmscott opened this issue Jul 17, 2020 · 18 comments
Closed

Disable process cleanup #598

patrickmscott opened this issue Jul 17, 2020 · 18 comments
Labels
bug Something isn't working

Comments

@patrickmscott
Copy link

Describe the bug
Our build process starts a bazel server on each run but the runner kills the process on cleanup. I want the server to stay around.

To Reproduce
Steps to reproduce the behavior:

  1. Start a background process in a job
  2. Complete job steps kills the process

Expected behavior
I expect some kind of ability to disable this behavior. I see process.clean but have no idea how to modify that variable.

Runner Version and Platform

linux-x64-2.267.1

@patrickmscott patrickmscott added the bug Something isn't working label Jul 17, 2020
@TingluoHuang
Copy link
Member

@croachrose can you start the background process on the host machine before the runner starts?

@patrickmscott
Copy link
Author

@TingluoHuang not really. The process is started based on the repository being tested and the version of the tool we are using (bazel). Is there no way to expose process.clean to either the config script or to the workflow config?

@michhyun1
Copy link

This would be really helpful for me as well. We are trying to run a server in the background while we run tests against it

@TingluoHuang
Copy link
Member

RUNNER_TRACKING_ID="" && ./yourtool before starting your process, then the process you start should not get killed by the runner.

@patrickmscott
Copy link
Author

RUNNER_TRACKING_ID="" && ./yourtool before starting your process, then the process you start should not get killed by the runner.

What do you mean by "before starting your process"? Is this within my workflow config or before starting my runner?

@TingluoHuang
Copy link
Member

RUNNER_TRACKING_ID="" && ./yourtool before starting your process, then the process you start should not get killed by the runner.

What do you mean by "before starting your process"? Is this within my workflow config or before starting my runner?

In your workflow.

@TingluoHuang
Copy link
Member

close this, and hope this worked. 😄

@VasuInukollu
Copy link

Adding this in front the command solved the problem.
RUNNER_TRACKING_ID="" &&

Changed this
forever start app.js
to
RUNNER_TRACKING_ID="" && forever start app.js

@TingluoHuang you saved my day.

@swamicontact
Copy link

Run RUNNER_TRACKING_ID=" " ./jfrog.exe is this the correct representation? for me each workflow run JFROG CLI settings are getting disappeared, so due to this the other parallel workflow jobs are getting failed since it is searching for JFROG setup

@subratliku
Copy link

subratliku commented Aug 9, 2023

how to resolve this on a Windows runner with powershell?

@MaksZhukov
Copy link

@subratliku Hey! Have you found a solution?

@ChristopherHX
Copy link
Contributor

how to resolve this on a Windows runner with powershell?

By using powershell syntax to set an env?

- run: |
    $env:RUNNER_TRACKING_ID=""
    # start your script
  shell: powershell # default for windows if pwsh is not installed

@subratliku
Copy link

subratliku commented Sep 2, 2023 via email

@gladykov
Copy link

So then how one would will kill such runner / process at the end of workflow?

@Pwuts
Copy link

Pwuts commented Mar 21, 2024

The $env:RUNNER_TRACKING_ID="" && ./start-something trick doesn't seem to work on Windows runners. :/

I'm trying to get a process to continue running between two steps but no luck so far. @TingluoHuang any suggestions?

Pwuts added a commit to Significant-Gravitas/AutoGPT that referenced this issue Mar 21, 2024
* Matrix the AutoGPT Python CI's `test` job across Ubuntu, macOS and Windows

   - Set up MinIO in a step rather than specifying it under `jobs[test].services`, because services are only supported on Linux runners

   - Add Windows version of step to install Poetry

   - Add macOS compatibility patches to 'Install Poetry (Unix)' and `setup_git_auth` steps
  
   **Caveats:**
   - **No Docker on macOS or Windows**
      * Windows comes with Docker but only supports running Windows containers, while we're mainly interested in using Linux containers for code execution and/or running auxiliary services.
      * [The macOS runner doesn't come with Docker](actions/runner-images#17). Setting it up is possible but takes ~3-4 minutes, and the performance of the Colima engine is poor: a `docker pull` that takes 2 seconds on Linux takes 45 seconds on macOS.

   - **No S3 service available on Windows**
   It seems that running a background process [isn't possible on Windows](actions/runner#598 (comment)), and neither is running Linux-based Docker containers.

* Add `autogpt-agent` and OS-specific flags to Codecov upload step

* Improve caching of Python dependencies in CI by changing the cache key
   - Include hash of `poetry.lock` instead of `pyproject.toml` in key
   - Remove date component from key; it was included to avoid getting stuck to old cached versions of packages when we were still using `requirements.txt`. With `poetry.lock` that is no longer a concern.

* Fix skip check in test_s3_file_storage.py
@pekspro
Copy link

pekspro commented May 12, 2024

@Pwuts, does it works if you start the process in bash instead of PowerShell in Windows? That solved the issue for me.

https://stackoverflow.com/questions/78464218/running-a-background-process-in-multiple-steps-on-windows

@jasonsketchup
Copy link

So then how one would will kill such runner / process at the end of workflow?

For POSIX shell...

pkill -lif [...]

For example...

pkill -lif /opt/homebrew/bin/appium

@buzzy
Copy link

buzzy commented Sep 18, 2024

That does not work at all for me.

RUNNER_TRACKING_ID="" && ./server &

It starts the server for a few seconds and when the workflow finishes, it gets forced killed! Like with kill -9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests