/proc/mounts -> /etc/mtab symlink broken

[LeoCavaille]

Description

While running a "base" image (in this case debian:buster-slim), it seems like the behavior of symlinking /proc/mounts to /etc/mtab has changed and I could not find anything related to it in documentation.

I found some reference to symlinking this in the rootFS here but I do not think this code is used anymore.

Opening the issue to confirm if it's expected (could not find anything related to this in the CRI spec) or if it should be kept for compatibility, and documenting the case if people hit the same issue. Happy to contribute with patches and/or to be pointed to code/docs.

Steps to reproduce the issue:

1. Run sudo ctr run --rm -t docker.io/library/debian:buster-slim test-leo /bin/bash -c "stat /etc/mtab"

Describe the results you received:

stat: cannot stat '/etc/mtab': No such file or directory

Describe the results you expected:
Same results as running with docker CRI

$ docker --version
Docker version 18.03.0-ce, build 0520e24
$ docker run -t --rm debian:buster-slim /bin/bash -c "stat /etc/mtab"
  File: /etc/mtab -> /proc/mounts
  Size: 12        	Blocks: 0          IO Block: 4096   symbolic link
Device: 10001bh/1048603d	Inode: 2305269     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-06-22 16:54:07.386583024 +0000
Modify: 2018-06-22 16:54:07.386583024 +0000
Change: 2018-06-22 16:54:07.386583024 +0000
 Birth: -

Output of containerd --version:

containerd github.com/containerd/containerd v1.1.0 209a7fc3e4a32ef71a8c7b50c68fc8398415badf

[LeoCavaille]

Just documenting here that this caused an issue again for us, software like elasticsearch (using old versions) used /etc/mtab via some C bindings (haven't checked thoroughly but I believe the Glibc uses /etc/mtab) to check for disk usage and trigger data reallocation.
In this case and the previous case when I reported the issue we had to manually create the symlink to restore functionality.

[crosbymichael]

We could probably create an option that would create these symlinks when creating a snapshot. We left this out of containerd by default, because not all users want these populated and it should be up to them to populate them. That is how docker consumes containerd today, it creates the symlinks.

[crosbymichael]

Going to close this as containerd is much lower level than docker and provides the tools to create symlinks like this at runtime vs auto populating these by itself.