How can I force Delve in VS Code to use root privileges?
I'm trying to debug go file that involves gopacket/pcap:
hndl, err := pcapgo.NewEthernetHandle(ifname)
// err == "couldn't open packet socket: operation not permitted"
Launching same program using sudo doesn't trigger error.
I've tried several methods:
Launch sudo code . It warns that it is not recommended. Plus there are issues to use dlv in this mode as environment variables are messed up.
Using this guide https://fatdragon.me/blog/2020/06/debug-golang-vs-code-linux-root. However "go.alternateTools" seems to know nothing about "dlv": Property dlv is not allowed. Probably something is missing in guide.
Search for .vscode/launch.json config property that allows to sudo. VSC allows to do such for Python, but not for Go.
Is there any trivial way to launch debugger with root privileges?
Environment:
Ubuntu 18.04
VSCode 1.48.0
Go 1.13.4
Delve 1.4.0
Update May 2022
Debugging programs and tests as root in the documentation of the VSCode Go addon has been updated accordingly with task and launch configuration examples to not only debug programs but also tests as root.
Old
Debugging Go programs and tests that require root privileges using VSCode has been sore for a long time. As of VSCode version 1.65.0 I noticed a new experimental launch option "asRoot": "true" 🙌 that needs to be combined with "console": "integratedTerminal".
For instance, in your launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Test/dbg pkg as root",
"type": "go",
"request": "launch",
"mode": "test",
"program": "${fileDirname}",
"console": "integratedTerminal",
"asRoot": true,
},
]
}
When launching this configuration by pressing F5, a new debug terminal session opens (or might get reused) and the following command executed:
/usr/bin/env GOPATH=/home/foobar/go /usr/bin/sudo /home/foobar/go/bin/dlv dap --check-go-version=false --client-addr=:41945
This now automatically inserts the sudo command before dlv itself, so this needs to be launched into an internal or external interactive terminal (and thus does not work in the internal console). After authenticating to sudo, VSCode switches back to the debug console view and you are good to go.
This now avoids having to fiddle around with remapping the dlv command in your workspace to a wrapper shell script.
Related
How can I debug while using --host option on Vue 3 Vite so I can debug my phone instance for example. At the moment Im using visual studio code plugin "Vite"
launch.json:
{
"version": "0.2.0",
"configurations": [
{
"type": "pwa-chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:4000",
"webRoot": "${workspaceFolder}/app",
}
]
}
package.json
"scripts": {
"dev": "vite --host --port 4000",
}
Vite config options
with this I'm being able to run on lan and debug but only on my pc, if I try from my phone or other pc, it connects but it wont stop on any breakpoint.
In order to debug any web app, web browser running on your phone must support a debugging protocol. Chrome for Android for example does support what you need, see Remote debugging article.
As for another PC, you need to launch Chrome there with a remote debugging command line switch as well, and then edit your launch.json to attach your vs code instance to different host (ip and port). That is of course if you want to be able to set breakpoints in vs code on your developer machine and then reflect that on another PC.
Roughly saying, you need to point your vs code to a running target
browser, for example, in your current config vs code launches instance of Chrome with a debugging switch enabled for you, behind the scenes
I run a process inside a docker container that needs to be debugged. The process is started in the docker's entry point via
dlv debug /go/src/path/to/package --headless --listen=:2345 --log for the purpose of enabling debugging later in VSCode.
The docker container is started via
docker run --rm -it -p 2345:2345 my_image:tag. Note delve's port is exposed.
In VSCode I define launch.json as follows:
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach remote",
"type": "go",
"request": "attach",
"mode": "remote",
"port": 2345,
"host": "127.0.0.1",
"apiVersion": 1
}
]
}
Upon starting the "attach remote" VSCode debugging configuration I get
It isn't crystal clear, but that UI leads me to believe I'm now connected to the remote headless debugger and ready to debug. I have one breakpoint defined which I know would be hit by a request I can send the remote process. I send that request, I get a result, and that breakpoint never hit, indicating that I haven't yet achieved remote debugging.
Is something wrong with my VSCode "attach remote" configuration? I can do command-line debugging with dlv connect :2345 and actually debug the remote process just fine, which indicates the headless server is functional. I would rather debug with source code, in VSCode though.
Try again with the latest beta of vscode-go (April 2020) (for any time after April 2020, the latest official vscode-go release will be enough)
Microsoft/vscode-go issue 2010 includes this confirmation from Ramya Rao:
The fix from #3108 is available in the latest beta version of this extension. Please do try and share feedback
The latest version of the extension now has the fix to this issue
And:
I can confirm that I am able to hit breakpoints now using AWS SAM to launch a linux container with delve and go binaries compiled from Windows.
For anyone still having this problem (like I was before I edited this comment), take care that the "remotePath" element of your launch.json is the absolute path to the source files as compiled on your local system (not the container).
As implied above - it's the absolute local path that is added to the DWARF compilation unit file table when you compile the binary.
I am trying to setup a headless delve debugger that I can attach to remotely.
I am unable to find a way to launch a debugging server that doesn't pause the application I am debugging.
I have been using dlv attach --headless=true --listen=:2345 attach 32 but this pauses the process.
Alternatively I could use dlv --headless=true --listen=:2345 exec app if this allowed the app binary to run.
I don't know if the init file can do something like this? I cannot find any documentation on what that actually is.
If you consider delve issue 145, that might be a feature, not a bug:
I can't see the value of starting an actual debug session without pausing unless you're simply relying on providing an init file (to load breakpoints / tracepoints) and then want to immediately continue execution, which you could do by writing a continue command at the end of the init file.
You can already set tracepoints without stopping the program indefinitely with the trace subcommand, which takes a pid flag.
That being said, with Delve 1.3.0 (August 2019, 2 years later):
go-delve/delve issue 245 is resolved by PR 1585
cmd/dlv: add --continue to continue process on launch/attach
Add --continue option for attach, debug, exec, and trace, to issue a continue on start.
The main use case for this feature would be to start a headless delve server (for example within a container)
My intention is to start automatically an internal webserver (using express extension https://marketplace.visualstudio.com/items?itemName=Compulim.vscode-express) with a launch configuration in the preLaunchTask property. For debugging I'm using Debugger for Chrome in vscode.
Express offers vscode commands like 'express.hostWorkspace' or 'express.hostWorkspaceWithRandomPort'.
I tried to config this vscode commands in a task and use this task in the preLaunchTask property, but it doesn't worked.
Is it possibile to run vscode commands as a task and use it in preLaunchTask or is there an other possibility?
I would like to debug my revel application with Jetbrain's gogland built in debugger but gogland run configuration allowing to setup either package or file run scenario not debug process started by revel run myapp.
Now Gogland is Goland
I find official manual for create debug-config. I'll post here if you do not mind...
INTELLIJ DEBUGGING (GOLAND)
Create your project, for this example i will be using canonical “revel new github.com/myaccount/my-app”
“revel run github.com/myaccount/my-app” to generate tmp/main.go - this file is needed by intellij
Shutdown the running server
Create run configuration and in “Program arguments” add “-importPath github.com\myaccount\my-app -srcPath \src -runMode dev"
Point “File” to \src\github.com\myaccount\my-app\app\tmp\main.go
In “before launch” add “Run external tool”. There: Program: \bin\revel(.exe) Paramerets: build github.com/myaccount/my-app
It works for Linux&Windows
AFAIK, Gogland built-in debugger is delve.
I think you must try run debug with option attach:
Attach to an already running process and begin debugging it.
This command will cause Delve to take control of an already running process, and
begin a new debug session. When exiting the debug session you will have the
option to let the process continue or kill it.
Usage:
dlv attach pid [flags]
I don't have installed gogland now, but I had similar problem in past.