Linux attach to running process

Linux Terminal: Reptyr attach a running process to a new terminal

If, like me, you work on terminals connected via ssh to remote computer/server you are probably used to tmux and screen and so it’s not a problem if you have to close your session, as you’ll be able to easily re-connect when you need it, but sometimes you could forget about using one of these utility.

Started a long-running process over ssh, but have to leave and don’t want to interrupt it?
Just start a screen, use reptyr to grab it, and then kill the ssh session and head on home.

Reptyr is a utility for taking an existing running program and attaching it to a new terminal, and is particularly useful for moving a long-running process into a GNU screen session.

reptyr does a more thorough job of transferring programs than many other tools, including the popular “screenify” shell script, because it changes the program’s controlling terminal. This means that actions such as window resizes and interrupts are sent to the process from the new terminal.

USAGE

The usage of reptyr it’s quiet easy, just discover the PID of the process you want to “move” to screen with a ps command and run the command:

reptyr PID
reptyr -l, reptyr will create a new pseudo-terminal pair with nothing attached to the slave end, and print its name out.

If you are debugging a program in gdb, you can pass that name to “set inferior-pty”. Because there is no existing program listening to that tty, this will work much better than passing an existing shell’s terminal.

Источник

Attach to process

CLion provides a way to attach the debugger to both local and remote processes.

For C/C++ applications, you can attach to a process with GDB on Windows, LLDB on macOS, and both GDB and LLDB on Linux. When applicable, debuggers for other languages (for example, Python debugger or Swift LLDB) can be used as well.

First off, if you want to debug a program that can be started from CLion, the best way to do it is to start a local debugging session.

Prerequisites for Ubuntu users

If you are using CLion on Ubuntu (or probably, on some other Linux distribution), an error message ptrace: Operation not permitted may appear upon your first attempt to attach to a process. In this case, do one of the following:

To disable this restriction temporarily, enter the command:

To disable this restriction permanently, open the /etc/sysctl.d/10-ptrace.conf file for editing and change the line kernel.yama.ptrace_scope = 1 to kernel.yama.ptrace_scope = 0 .

To apply the changes immediately, enter the above command echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope .

Alternatively, run sudo service procps restart or restart your system.

You can find more details here.

Attach to a local process

Press Ctrl+Alt+F5 or choose Run | Attach to Process from the main menu.

The list of running local processes is shown. Select the process to attach to.

If necessary, narrow down the list of processes by typing the first letters of its name or PID. If there are several debuggers that can be used for the selected process, you can choose among them in the popup menu:

By default, you will not be able to attach the debugger to a process launched with sudo privileges. As a workaround, try running CLion under the same privileged user.

Proceed with debugging the same way as you usually do it in CLion (set breakpoints, step through, pause and resume the process, evaluate expressions, and so on):

Note that in case the process you have attached to does not provide debug information, breakpoints will be unavailable and stepping will be performed in the disassembly view.

Detach from a process

The procedure to detach from a remote process is the same as for stopping a local debug session, however, the effect is different. When you detach, the debugging session closes but the process continues to run.

Click the Stop button on the main toolbar on in the Debug tool window.

Alternatively, click Stop on the main toolbar or press Ctrl+F2 , then select the session to be closed.

Источник

Attach to a process running on a Docker container

You can debug apps running in either a Windows Docker Container or a Linux .NET Core Docker container using Visual Studio.

Prerequisites

If it’s not already present on the Linux server, you need to install SSH server, unzip and install with either curl or wget. For example, on Ubuntu you can do that by running:

SFTP must be enabled as well. Most SSH distributions install and enable SFTP by default, but that is not always the case.

Attach to a process running on a Linux Docker container

You can attach the Visual Studio debugger to a process running in a Linux .NET Core Docker container on your local or remote machine using the Attach to Process dialog box.

To use this feature, you must install the .NET Core Cross-Platform Development workload and have local access to the source code.

To attach to a running process in a Linux Docker container:

1. In Visual Studio, select Debug > Attach to Process (CTRL+ALT+P) to open the Attach to Process dialog box.

Set the Connection type to Docker (Linux Container).

Select Find. to set the Connection target via the Select Docker Container dialog box.

You can debug a Docker container process either locally or remotely.

To debug a Docker container process locally:

1. Set Docker CLI host to Local Machine.
2. Select a running container to attach to from the list and hit OK.

B. To debug a Docker container process remotely:

There are two options for connecting remotely to a running process in a Docker container. The first option, to use SSH, is ideal if you don’t have Docker tools installed on your local machine. If you do have Docker tools installed locally and you have a Docker daemon that’s configured to accept remote requests, try the second option, using a Docker daemon.

To connect to a remote machine via SSH:

1. Select Add. to connect to a remote system.
   
2. Select a running container to attach to after connecting to the SSH or daemon successfully and hit OK.

To set the target to a remote container running a process via a Docker daemon

1. Specify the daemon address (i.e. via TCP, IP, etc.) under Docker host (Optional) and click the refresh link.
2. Select a running container to attach to after connecting to the daemon successfully and hit OK.

Choose the corresponding container process from the list of Available processes and select Attach to start debugging your C# container process in Visual Studio!

Attach to a process running on a Windows Docker container

You can attach the Visual Studio debugger to a process running in a Windows Docker container on your local machine using the Attach to Process dialog box.

To use this feature with a .NET Core process, you must install the .NET Core Cross-Platform Development workload and have local access to the source code.

To attach to a running process in a Windows Docker container:

In Visual Studio, select Debug > Attach to Process (or CTRL+ALT+P) to open the Attach to Process dialog box.

Set the Connection type to Docker (Windows Container).

Select Find. to set the Connection target using the Select Docker Container dialog box.

The target process must have the same processor architecture as the Docker Windows container it is running on.

Setting the target to a remote container via SSH is currently unavailable and can only be done using a Docker daemon.

To set the target to a remote container running a process via a Docker daemon

Specify the daemon address (i.e. via TCP, IP, etc.) under Docker host (Optional) and click the refresh link.

Select a running container to attach to after connecting to the daemon successfully and choose OK.

Choose the corresponding container process from the list of Available processes and select Attach to start debugging your C# container process.

Choose the corresponding container process from the list of available processes and choose Attach to start debugging your C# container process.

Источник

WSL + Visual Studio = attaching/launching a Linux .NET Core application on Window 10

This post shows how to attach to a .NET Core process running on Linux with WSL and also how to start a Linux process with Visual Studio debugger

Coming from the Windows world, I don’t find that easy to develop .NET Core applications for Linux. I’m used to code and debug in Visual Studio. Now, I need to build on Windows (due to our Criteo continuous integration), deploy an artifact to Marathon in order to get an application running inside a Mesos container. At Criteo, we had to build a whole set of services to allow remote debugging or memory dump analysis.

But what if I just wanted to test and debug a small scenario on my beloved Windows machine? Windows Subsystem for Linux (aka WSL) is perfect for running a Linux .NET Core application on Windows. However, how to attach to it or even start a debugging session from Visual Studio? In the rest of this post, I’ll explain how to setup your Windows 10 machine to achieve these miracles.

Linux on Windows: welcome WSL

It is obviously not the place to dig into Windows Subsystem for Linux. You just need to know that once installed, it allows you open up a Linux shell on your Windows machine without any virtual machine kind of technology. It is also possible to share folders between Windows (where you want to build your application) and Linux (where you want to execute the built assemblies).

The first step is to turn on WSL feature in your Windows:

After a reboot, you are able to start a WSL prompt:

The next step is to install .NET Core runtime or SDK so you are able to run your application on Linux.

It is now time to look at your hard drive from a Linux perspective:

Your drives are mapped under /mnt without the “:”. In my case, I created a wsl folder under my d: drive to do my experiments. With Visual Studio, I generated a TestConsole application with the following code:

I’m publishing the application to get all needed assemblies:

In a WSL prompt, type dotnet with the name of your application assembly et voila!

A Linux .NET Core application is running on your Windows machine.

How to attach to a running Linux application

Let’s say that I’m detecting a problem and I want to debug the Linux application with Visual Studio. When attaching the Visual Studio debugger to a process, several connection types are available:

The SSH connection type will be used with WSL with the following kind of communications architecture:

The Visual Studio debugger is sending commands to the remote Linux debugger vsdbg via an SSH channel. Here are the steps to follow to install the missing components:

1. By default, an SSH server is installed with WSL. However, I was not able to make the whole pipeline work with it so I had to uninstall and reinstall it:
   sudo apt-get remove openssh-server
   sudo apt-get install openssh-server
2. The SSH configuration needs also to be changed in order to allow username/password kind of security needed by Visual Studio (if you prefer key-based security, look at the end of the post for available resources). If you don’t know how to use vi efficiently to simply edit a file, install nano (thanks @kookiz for the tips :^)
   sudo apt-get install nano
3. In /etc/ssh/sshd_config, change the PasswordAuthentication settings
   sudo nano /etc/ssh/sshd_config
   PasswordAuthentication yes
4. Restart the ssh server
   sudo service ssh start
5. You need to install unzip in order to get vsdbg
   sudo apt-get install unzip
   curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l

You are now ready to select SSH as connection type and enter your machine name before clicking the Refresh button. At that time, a new dialog should pop up for you to enter your WSL credentials:

After you click the Refresh button, the list at the bottom should contain the Linux processes running in WSL

Select your .NET Core application and click Attach to select the Managed debugger:

Now, if you set a breakpoint in the code and trigger it with an appropriate action in your WSL prompt

then the debugger will break as expected:

Note that when you stop your debugging session, the Linux application is not stopped; just detached from the debugger and keeps on running.

Showtime for F5!

Attaching to a running Linux application is nice but it would be even better to start a Linux process from Visual Studio debugger. In order to achieve this goal you need to add another piece to the architecture puzzle:

As detailed in this WIKI page, it is possible to tell Visual Studio to execute debugging actions thanks to a launch.json file such as the following:

The plink tool from putty will be used as an adapter for Visual Studio to communicate with vsdbg running in WSL. The adapterArgs property gives the same SSH/machine/user/password information that you provide via Visual Studio UI in the Attach scenario. The configuration section defines which request (“launch” instead of attach and which folder/assembly to start) will be sent to vsdbg.

Once this file is created (in my case in d:\wsl\vs folder), you just need to type the following command in the Immediate pane of Visual Studio:

and if you had set a breakpoint on the first line of your application, the debugger should break there:

In a WSL prompt, you can see the expected 2 new spawned processes:

Источник