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

Debugging sandbox documentation #6029

Closed
gordicaleksa opened this issue Jan 4, 2025 · 5 comments
Closed

Debugging sandbox documentation #6029

gordicaleksa opened this issue Jan 4, 2025 · 5 comments
Labels
enhancement New feature or request Stale Inactive for 30 days

Comments

@gordicaleksa
Copy link

I was wondering if there are any instructions for debugging the sandbox environement similar to this:

https://docs.all-hands.dev/modules/usage/how-to/debugging

which "will allow debugging the agent, controller and server elements, but not the sandbox"

Thanks!

@gordicaleksa gordicaleksa added the enhancement New feature or request label Jan 4, 2025
@gordicaleksa
Copy link
Author

gordicaleksa commented Jan 4, 2025

I figured out a workaround:

  1. I hardcode the default value for LOG_TO_FILE and LOG_ALL_EVENTS to true ('1') as apparently the launch.json specification:
            "env": {
                "LOG_ALL_EVENTS": "1",
                "LOG_TO_FILE": "1",
            },

impacts the rest of the system (frontend and backend minus the sandbox) but the env vars inside of sandbox pull from some different source as they are not set to true for some reason.

  1. I use logger.info in sandbox instead of logger.debug

  2. now i can log into the docker container via docker exec -it <container id> bash and navigate to /openhands/code/logs and then cat the log file

@gordicaleksa
Copy link
Author

Ideally we'd have an option to step through the code, and put breakpoints, similar as for the rest of the codebase (the debugging docs i shared above) - but for now this unblocks me a bit.

Copy link
Contributor

github-actions bot commented Feb 4, 2025

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the Stale Inactive for 30 days label Feb 4, 2025
Copy link
Contributor

This issue was closed because it has been stalled for over 30 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 11, 2025
@enyst
Copy link
Collaborator

enyst commented Feb 11, 2025

We now have the ability to run on a local runtime, without docker, which may help much more, assuming of course use cases for which sandboxing isn't necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Stale Inactive for 30 days
Projects
None yet
Development

No branches or pull requests

2 participants