Hi @fengwei0328. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

CI is failing

CI is failing

All problems have been solved @AkihiroSuda @djdongjin

Also I didn't quite understand the issue. Why would setting ro option in a sandbox/pause container mount impact your container mount? And why fixing the sandbox mount also fix the issue in your container? Is it because when you launch a container, it inherient these mounts from the sandbox?

Even if the config.json of the container is set to rw, the container inherits the NetNS of the sandbox, so the mount property permissions of sysfs will not be higher than that of the sandbox.

{
  "destination": "/sys",
  "type": "sysfs",
  "source": "sysfs",
  "options": [
    "nosuid",
    "noexec",
    "nodev",
    "rw"
  ]
}

/ok-to-test

The CI failure is due to vagrantcloud throttling: #11364

pull-containerd-node-e2e failure seems k8s upstream flakiness. I saw it fails across multiple PRs.

@fengwei0328: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
pull-containerd-node-e2e 1fc4972 link true /test pull-containerd-node-e2e
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

/retest

LGTM on CI green

PTAL, thanks! @AkihiroSuda @djdongjin

PTAL, thanks! @AkihiroSuda

Today, An error was generated with many PR in MacOS unit tests
Like this:
level=error msg="error flushing stderr" error="read |0: i/o timeout"

some PR:
#11444 #11360

added this pull request to the merge queue

Today, An error was generated with many PR in MacOS unit tests Like this: level=error msg="error flushing stderr" error="read |0: i/o timeout"

some PR: #11444 #11360

Problem seems to have been solved
Please Re-added this pull request to the merge queue
@AkihiroSuda

@AkihiroSuda should we cherrypick this to 2.0.x given it's a bug fix?

/cherry-pick release/2.0

@AkihiroSuda: new pull request created: #11456

note: This fix aligns behavior with cri-o (cri-o/cri-o#2627) and with the spec,
BUT "fat" containers that have udevd in them might now run udevd (and some other services) if they where just checking if /sys is ro.
This is true for containers with debian + sysvinit + udev:

• https://sources.debian.org/src/sysvinit/3.14-3/debian/src/initscripts/etc/init.d/udev/?hl=45#L127-L130

systemd doesn't seem to start udevd even if it has ConditionPathIsReadWrite=/sys, there is likely something else actually starting the unit (unit and sockets are static)