lxc-attach

Attach to a container

$ sudo lxc-attach [container_name]

$ lxc-attach [[-?|--help]]

lxc-attach -n name [-e] [-s namespace]... [-P] [-v] [--] command [arguments...]

-n name
    Specifies the name of the LXC container to attach to. This is a mandatory option.

-e
    Keeps the environment variables from the host process when executing the command inside the container. By default, the environment is cleared.

-s namespace
    Specifies which namespaces to attach to. Multiple -s options can be provided, or a comma-separated list (e.g., PID,NET,MOUNT). Common namespaces include PID (process ID), NET (network), UTS (hostname), IPC (inter-process communication), MOUNT (filesystem), and USER (user ID). By default, lxc-attach attempts to join all namespaces except the user namespace.

-P
    Prints the PID (Process ID) of the process that was created inside the container.

-v
    Enables verbose output, providing more detailed information about the attachment process.

--
    A conventional separator used to distinguish options passed to lxc-attach from the command and its arguments that are to be executed inside the container. Everything following -- is treated as the command and its arguments.

command
    The command to execute inside the specified container (e.g., /bin/bash, ls -l).

arguments...
    Any arguments to pass to the command being executed inside the container.

The lxc-attach command allows users to execute arbitrary commands inside a running Linux Container (LXC) instance. Unlike commands that start a new container or execute a one-off command upon container launch, lxc-attach connects to an already active container, placing the user directly within its isolated environment. It achieves this by leveraging Linux kernel features like namespaces (PID, network, mount, UTS, IPC, user) and cgroups, effectively making the executed command run as if it were launched from within the container itself.

This utility is invaluable for administrative tasks, debugging containerized applications, installing software, or simply exploring the container's filesystem and processes without needing to restart it. It ensures that the command inherits the container's resource limits and isolation, making it a robust tool for container management.

The container specified by -n must be in a RUNNING state for lxc-attach to succeed. It cannot attach to stopped or frozen containers.

Typically, lxc-attach requires root privileges on the host system to perform namespace manipulations, unless user namespace configuration is specifically set up to allow unprivileged users to attach.

The command executed inside the container will run with the privileges of the user that lxc-attach maps to within that container. If the container uses user namespace ID mapping, a host user may map to a non-root user inside the container. Otherwise, a host root user executing lxc-attach will typically execute the command as root inside the container.

At its core, lxc-attach utilizes the setns(2) system call. This call allows a process to enter a different namespace (e.g., PID, network, mount) than its own. When you execute lxc-attach, it identifies the target container's namespaces and then uses setns(2) to effectively 'move' the newly spawned command process into those namespaces, thereby making it appear as if it originated from within the container.

By default, when lxc-attach is used without explicit -s options, it attempts to join all namespaces associated with the target container except the user namespace. This ensures that the attached command runs within the container's isolated network, process tree, filesystem, and hostname, providing a comprehensive container environment for interaction.

lxc-attach is a core component of the Linux Containers (LXC) project, which pioneered OS-level virtualization on Linux. LXC emerged as a light-weight alternative to traditional virtual machines, leveraging Linux kernel features like control groups (cgroups) and namespaces that became available in the mid-2000s.

As LXC matured, lxc-attach was developed as a direct and efficient way to interact with running containers, providing administrators with the ability to enter and manage the container's environment without the overhead of re-spawning processes or reconfiguring container startup. Its design is intrinsically tied to the kernel's namespace functionality, making it a fundamental tool in the LXC ecosystem for operational control and debugging of containerized workloads.

lxc(7), lxc-start(1), lxc-stop(1), lxc-execute(1), lxc-ls(1), lxc-info(1), nsenter(1), chroot(1)