Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct create.go's failure to detect WSL2 kernel's compiled-in swap capabilities #43674

Open
skepticoitusInteruptus opened this issue Jun 2, 2022 · 10 comments · May be fixed by #43711
Open

Comments

@skepticoitusInteruptus
Copy link

skepticoitusInteruptus commented Jun 2, 2022

Description

Docker fails to detect the swap capabilities of a Windows Subsystem for Linux (WSL2) kernel running Alpine Linux.

My WSL2 kernel has cgroup v2 and swap capabilities enabled.1

Although docker info correctly detects and reports the cgroup v2 info, docker run -m 1024m --memory-swap 1024m, however, evidently fails to detect the kernel's swap capabilities.

Steps to reproduce the issue:

  1. Configure Alpine Linux v3.15 installed in Windows Subsystem for Linux following the steps listed here
  2. Follow the "Steps to reproduce" listed here: https://bit.ly/podm14236 2

Describe the results you received:

The first thirty, forty seconds of this recording illustrate the occurrence of the misdiagnosed WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap3

Illustration of crun 923 reproducer

Describe the results you expected:
docker run, executed on a cgroup v2-configured kernel with swap capabilities compiled in, should not print, WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.

Additional information you deem important (e.g. issue happens only occasionally):

  • I got that warning regardless of the fact that WSL2's 5.10.102.1-microsoft-standard-WSL2 kernel does, indeed, support swap limit capabilities
  • My Alpine distro is not inited by systemd4
  • I discovered @AkihiroSuda's 43649 fix that resolves the WARNING: No swap limit support that's observed in docker info output
  • An identical issue was reported in Podmans' #14236 and resolved in Support running podman under a root v2 cgroup

Tangential info:

Output of docker version:

Client:
 Version:           20.10.15
 API version:       1.41
 Go version:        go1.18.2
 Git commit:        fd82621d35d2d9662854c8351976d5cc1e4186ce
 Built:             Thu May 12 00:24:02 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.15
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.2
  Git commit:       4433bf67ba0a3f686ffffce04d0709135e0b37eb
  Built:            Thu May 12 00:00:55 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.6.4
  GitCommit:        212e8b6fa2f44b9c21b2798135fc6fb7c53efc16
 runc:
  Version:          1.1.2
  GitCommit:        a916309fff0f838eb94e928713dbc3c0d0ac7aa4
 docker-init:
  Version:          0.19.0
  GitCommit:

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
WARNING: Plugin "/usr/local/lib/docker/cli-plugins/docker-buildx" is not valid: failed to fetch metadata: fork/exec /usr/local/lib/docker/cli-plugins/docker-buildx: no such file or directory
WARNING: Plugin "/usr/local/lib/docker/cli-plugins/docker-compose" is not valid: failed to fetch metadata: fork/exec /usr/local/lib/docker/cli-plugins/docker-compose: no such file or directory
WARNING: Plugin "/usr/local/lib/docker/cli-plugins/docker-sbom" is not valid: failed to fetch metadata: fork/exec /usr/local/lib/docker/cli-plugins/docker-sbom: no such file or directory
WARNING: Plugin "/usr/local/lib/docker/cli-plugins/docker-scan" is not valid: failed to fetch metadata: fork/exec /usr/local/lib/docker/cli-plugins/docker-scan: no such file or directory

Server:
 Containers: 7
  Running: 0
  Paused: 0
  Stopped: 7
 Images: 16
 Server Version: 20.10.15
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 212e8b6fa2f44b9c21b2798135fc6fb7c53efc16
 runc version: a916309fff0f838eb94e928713dbc3c0d0ac7aa4
 init version:
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.102.1-microsoft-standard-WSL2
 Operating System: Alpine Linux v3.15
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 12.04GiB
 Name: ******************************
 ID: KI3T:JNJC:Y7RO:24JH:ZOKU:QXVB:IC6S:V5UE:6IO4:MQC6:VJKG:JGLS
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support 

Additional environment details (AWS, VirtualBox, physical, etc.):
Alpine Linux v3.15 in Windows Subsystem for Linux (WSL) 2 on a Windows 10 physical host





 1 _Kernel config for MS 5.10.x WSL2 showing kernel is compiled with swap capabilities CONFIG_MEMCG_SWAP=y https://bit.ly/confMemCGSwap _

 2 To reproduce the WARNING, the process in which docker run is executed MUST be in the root cgroup

 3 Illustrates a reproducer for an issue reported in the crun project

 4 Considering systemd as a dependency is off the table

@thaJeztah
Copy link
Member

Was there a specific reason you're using https://bit.ly/ links for the links? If not, would you be ok changing them to the upstream links?

@thaJeztah
Copy link
Member

Q. Does #43649 resolve the …kernel does not support swap limit capabilities or the cgroup is not mounted… warning too?

Looks like that PR fixed a regression on "master" (which was introduced in #43347, and not in the 20.10 release), so if the issue is in docker 20.10, that fix likely will be different.

@skepticoitusInteruptus
Copy link
Author

Hey @thaJeztah 👋

Thank you for engaging so promptly 👍

"…Was there a specific reason you're using https://bit.ly/ links for the links? …"

My employer requires them for some kind of internal accounting of access to links to certain kinds of internet resources.

I wasn't told — and don't understand — their strategic rationale for that particular tracking mechanism.

Even if I did know though, I presume I'd be contractually bound to not reveal specifics of internal practices publicly.

@thaJeztah
Copy link
Member

Hmm... that's a bit of an odd policy, as effectively it means users that want to read your report must accept to visit an "unknown" link, and to accept it's tracked by your company 🤔

@thaJeztah
Copy link
Member

I edited the description to make the bit.ly links visible, so that people clicking them are not caught off-guard 👍

@neersighted
Copy link
Member

Since nothing stops me from unmasking the links:

@skepticoitusInteruptus
Copy link
Author

I think I might be getting warmer, @thaJeztah.

I've done a very cursory reading of the following two blocks of moby code…

  1. daemon.RawSysInfo()
// RawSysInfo returns *sysinfo.SysInfo .
func (daemon *Daemon) RawSysInfo() *sysinfo.SysInfo {
	daemon.sysInfoOnce.Do(func() {
		// We check if sysInfo is not set here, to allow some test to
		// override the actual sysInfo.
		if daemon.sysInfo == nil {
			daemon.loadSysInfo()
		}
	})

	return daemon.sysInfo
}
  1. daemon.loadSysInfo()
func (daemon *Daemon) loadSysInfo() {
	var siOpts []sysinfo.Opt
	if daemon.getCgroupDriver() == cgroupSystemdDriver {
		if euid := os.Getenv("ROOTLESSKIT_PARENT_EUID"); euid != "" {
			siOpts = append(siOpts, sysinfo.WithCgroup2GroupPath("/user.slice/user-"+euid+".slice"))
		}
	}
	daemon.sysInfo = sysinfo.New(siOpts...)
}

My, admittedly, very naive intepretation so far of those two blocks of code is…

Anybody expecting this implementation to find swap and cgroup info when running on a host that doesn't use systemd, is S.O.L. …1

Please correct me if my interpretation is wrong, though. I hope it is, anyway.

TIA.





 1 Sh!t Out o' Luck _

@skepticoitusInteruptus
Copy link
Author

Inching toward Docker inception; but in WSL2 Alpine…

Docker inception in WLS2 Alpine - 0

@skepticoitusInteruptus
Copy link
Author

Hey @thaJeztah , does daemon.NewDaemon(): fix network feature detection on first start impact, in any way, the behavior reported in this issue…

Commit 483aa62 introduced a regression, causing
spurious warnings to be shown when starting a daemon for the first time after
a fresh install
…"

❔ ❔ ❔

@thaJeztah
Copy link
Member

That fix was addressing a regression on master (not in the 20.10 branch, or any release)

skepticoitusInteruptus added a commit to skepticoitusInteruptus/moby-podmanVdockerSpike that referenced this issue Jun 9, 2022
Fixes moby#43674

To stop the display of the spurious warning reported in moby#43674,
I propose the following solutions:

	- Refactor daemon.getSwapLimitV2() to make it testable
	- Detect the kernel's actual swap support

My best guess for what the root cause of the defect might be:

	- The previous implementation assumes it will
	  *never* be running in the root cgroup

The general idea behind what this refactored implementation
and its tests codify:

	- Root cgroup use cases should be taken into
	  consideration whenever attempting to detect
	  the kernel's swap support

——

Signed-off-by: Randi Sheaffer-Klass <hgyao63bn@mozmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants