Mixed libc environments

Deepfactor intercepts libc (C Standard Library) functions in your running application. Two popular implementations of libc are glibc and musl libc. glibc is used in most linux distributions such as Ubuntu, CentOS, SUSE etc, where Alpine base images use musl libc.

You can read about musl libc and the differences between the two implementations in the following articles

musl - Introduction

musl libc - Functional differences from glibc


Based on the container image OS distribution, Deepfactor injects the right interception code compatible with glibc or musl into your container. Glibc and musl require a different version of the Deepfactor interception library. However, there are scenarios where your container may have both glibc and musl implementations of libc.

Example: You are launching a java[1] spring boot application in your alpine container using a script. In this case, the shell will use the musl libc present on the OS, but java spring boot application uses glibc which is packaged along with the application.

In order to address such scenarios, we have built in an auto detection mechanism.

For containerized workloads, if the libc required by the entrypoint does not match the OS distribution libc then it can be specified with the following instructions

  • Docker workloads
    Add the --entrypoint-libc "glibc" or "musl" option in the dfctl run command

  • Kubernetes workload
    Add the annotation df.k8-app.entrypoint.libc: "glibc" or "musl" in your pod spec
    Enable the Webhook image manifest and entrypoint analysis service.
    See 5. Tech Preview: Namespace Instrumentation

[1] - There are java-glibc and java-musl openjdk apk packages for alpine. A java-musl openjdk in alpine does not require enabling Deepfactor automatic multilibc support.

Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.