Containerd: Plugin restart doesn't follow log-uri tasks

Created on 31 May 2020  路  4Comments  路  Source: containerd/containerd

Description

With change introduced by #3085, we can now specify an external binary to execute to handle logs. When a container is restarted by restart plugin, this is lost.

If any binary:// URI is specified for logs, this is lost when the container restart. Is there any way to keep that alive ?

Steps to reproduce the issue:

  1. Set a task via container.NewTask(ctx, cio.LogURI(uri))
  2. Set restart.WithStatus(containerd.Running) on container
  3. Kill the container main process

Describe the results you received:

The shim task is lost. The restart plugin support an extra argument (WithLogPath) to handle logs, but it only support log file and tasks support lot more things. (fifo, binary, etc.)

Describe the results you expected:

There should be a way to restart the same task (keep the URI and not specifying a file log path) and use this URI inside restart module ?

kinbug

Most helpful comment

Will file pr to fix it. Thanks for the reporting

All 4 comments

@maxux could you mind to provide the reproduce code for this issue? Thanks

    opts := []oci.SpecOpts{
        oci.WithDefaultSpecForPlatform("linux/amd64"),
        oci.WithRootFSPath(rootfs),
        oci.WithEnv(env),
        oci.WithHostResolvconf,
        removeRunMount(),
        withNetworkNamespace(netns),
    }

    container, err := client.NewContainer(
        ctx,
        cname,
        containerd.WithNewSpec(opts...),
        restart.WithStatus(containerd.Running),
    )

    uri, err := url.Parse("binary:///bin/external-logs")
    if err != nil {
        return err
    }

    task, err := container.NewTask(ctx, cio.LogURI(uri))
    if err != nil {
        return err
    }

    if err := task.start(ctx); err != nil {
        return err
    }

Then kill the process inside the container, process will restart but external-logs will be lost. Ideally, restart plugin should also restart tasks attached.

Will file pr to fix it. Thanks for the reporting

ping @maxux sorry for late reply. The pr #4315 is ready and waiting for review.

Was this page helpful?
0 / 5 - 0 ratings