# Run yc-360 Script in Sidecar Container Beta

The yc-360 script can run as a sidecar container alongside your Java application container on the same Docker host. This configuration enables yc-360 script to capture critical diagnostic data from the target Java application, without requiring the script to run inside the same container.

The most straightforward way to enable cross-container access is by running the yc-360 script container with the --pid=host flag. This allows yc-360 script to observe all processes running on the host, including those inside other containers.

docker run --rm --pid=host ycrash/yc-360-script:latest ...
1

If you prefer to limit access to a specific container, you can use the following Docker runtime options instead of --pid=host:

  • --pid=container:java-container-id: Shares the process namespace with the target Java application container.
  • --net=container:java-container-id: Shares the network namespace with the Java application container.
  • --user root: Runs yc-360 as root to enable access to system-level tools.
  • -v /tmp:/tmp: Shares the /tmp directory between the Java application container and the yc-360 container, allowing yc-360 script to access .java_pid files required for JVM interaction.
docker run --rm --pid=container:4fdf503c2b6e --net=container:4fdf503c2b6e --user root -v /tmp:/tmp ycrash/yc-360-script:latest ...
1

These options grant the yc-360 script access only to the specified container’s process, network, and temporary file systems—minimizing exposure and improving security posture.

INFO

Examples in this documentation use --pid=host for simplicity. However, for production environments with stricter security requirements, the container-targeted approach is recommended.

# Run yc-360 Script Inside a Docker Container

You can run the yc-360 script in a standalone Docker environment (without Kubernetes) using one of the following methods:

Option 1: Use Official Docker Image

We provide a prebuilt Docker image for yc-360 script at: ycrash/yc-360-script:latest. Please follow the below instructions to pull the prebuild docker image and run the yc-360 script.

The script supports multiple execution modes tailored for various monitoring needs. Select your preferred mode below to see how to configure the script.

Not sure what these modes mean? Learn more about Execution Modes

    Option 2: Build Your Own Docker Image

    If you need customizations or want to bundle the yc-360 script into your own image, follow these steps:

    The yc-360 script supports multiple execution modes tailored for various monitoring needs. Select your preferred mode below to see how to configure the script.

    Not sure what these modes mean? Learn more about Execution Modes

      IMPORTANT NOTE

      • The yc-360 script must be executed with the same user privileges as the Java application. For example, if the application runs under the tomcat-user user, yc-360 script must also be executed by tomcat-user user.

      • To detect memory-related issues, GC logging must be enabled for your application. You can enable GC logging by using the JVM arguments listed here.

      • The yc-360 script doesn't capture heap dump by default. Pass -hd argument to capture heap dump. For more information, please visit How to Capture Heap Dump?

      • If you get an error while running yc-360 script in Alpine docker container, please install a libec6-compat package in your Alpine docker container. For example,

      RUN apk add --no-cache libc6-compat
      
      1