AKS sysbox container missing /proc/sys/net/ipv4/neigh/default

[tanwar57]

Sysbox installed on AKS nodes, with image used nestybox/sysbox-deploy-k8s:latest , container running successfully. But the sysbox container missing the below mentioned path:-

[root@sysbox-deploy-k8s-bmptg /]#  ls -l //proc/sys/net/ipv4/neigh/default/gc_thresh1
ls: cannot access //proc/sys/net/ipv4/neigh/default/gc_thresh1: No such file or directory

But the host on which sysbox container is running having the above mentioned path .

[rodnymolina]

Thanks for filling this one up @tanwar57.

For security purposes, we are not exposing all node's /proc resources, especially the non-namespaced ones like this one. So my question: how is this missing resource affecting you? Which app is failing?

[tanwar57]

@rodnymolina actually i was building an node application inside the docker container which is running over sysbox as runtime , and that app building task is looking for the above mentioned default directory under proc

SO,could you please let me how can i enable this dir or mount under sysbox container, or any other good way

[tanwar57]

@rodnymolina any update on this ?

[ctalledo]

Hi @tanwar57,

Sorry, just replied to your question in issue #618 where you had asked this same question.

Let's use this new issue though, since more specific to your problem.

Copying my reply from issue #618:

[root@sysbox-deploy-k8s-bmptg /]# cd /proc/sys/net/ipv4/neigh/ [root@sysbox-deploy-k8s-bmptg neigh]# ls eth0 lo

Got it; so it's clear the problem is that the /proc/sys/net/ipv4/neigh/default dir does not exist inside the pod in your K8s cluster (for some reason).

@rodnymolina: any idea on how can this occur? I see that sysbox-fs has a handler to emulate that directory inside Sysbox containers.

As a point of comparison, on a GKE K8s cluster, using the "ubuntu with containerd" nodes, and deploying a sysbox pod with image ubu-focal-systemd-docker, I can't reproduce:

$ kubectl exec -it ubu-focal-systemd-docker -- bash
root@ubu-focal-systemd-docker:/# ls -l /proc/sys/net/ipv4/neigh/default/
total 0
-rw-r--r-- 1 root root 0 Feb 15 05:02 gc_thresh1
-rw-r--r-- 1 root root 0 Feb 15 05:02 gc_thresh2
-rw-r--r-- 1 root root 0 Feb 15 05:02 gc_thresh3

The Sysbox image won't make a different I think; it has got to be a bug in Sysbox I think.

[rodnymolina]

In my first comment above, I mentioned that not all procfs nodes are exposed, which is true, but in this particular case, Sysbox is indeed emulating /proc/sys/net/ipv4/neigh/default presence, so this folder and its gc_threshold nodes should be seen within the container.

At first glance, I thought that problem could have been caused by this specific Linux kernel not exposing the default folder (i.e., /proc/sys/net/ipv4/neigh/default), but @tanwar57 mentioned above that the host on which sysbox container is running having the above mentioned path, so that doesn't seem to be the issue.

@tanwar57, please confirm the above by doing this in your host system:

$ ls -l /proc/sys/net/ipv4/neigh
$ ls -l /proc/sys/net/ipv4/neigh/default
$ ls -l /proc/sys/net/ipv4/neigh/default/gc_thresh1

Then repeat the above instructions within a sysbox container.

If all looks good, then I would suggest enabling sysbox-fs debugging traces and collecting the logs that you see while executing the same instructions above. See some basic documentation here on how to do the above (just need to add --log-level debug to your sysbox-fs systemd file).

[tanwar57]

Hello @rodnymolina please have a look I tried to run above mentioned command on node the out put is like:-

/ # ls -l /proc/sys/net/ipv4/neigh

total 0
dr-xr-xr-x    1 root     root             0 Feb 15 07:19 azv0d717e5d285
dr-xr-xr-x    1 root     root             0 Feb 15 07:19 default
dr-xr-xr-x    1 root     root             0 Feb 15 07:19 eth0
dr-xr-xr-x    1 root     root             0 Feb 15 07:19 lo

/ # ls -l /proc/sys/net/ipv4/neigh/default

total 0
-rw-r--r--    1 root     root             0 Feb 15 07:19 anycast_delay
-rw-r--r--    1 root     root             0 Feb 15 07:19 app_solicit
-rw-r--r--    1 root     root             0 Feb 15 07:19 base_reachable_time
-rw-r--r--    1 root     root             0 Feb 15 07:19 base_reachable_time_ms
-rw-r--r--    1 root     root             0 Feb 15 07:19 delay_first_probe_time
-rw-r--r--    1 root     root             0 Feb 15 07:19 gc_interval
-rw-r--r--    1 root     root             0 Feb 15 07:19 gc_stale_time
-rw-r--r--    1 root     root             0 Feb 15 07:19 gc_thresh1
-rw-r--r--    1 root     root             0 Feb 15 07:19 gc_thresh2
-rw-r--r--    1 root     root             0 Feb 15 07:19 gc_thresh3
-rw-r--r--    1 root     root             0 Feb 15 07:19 locktime
-rw-r--r--    1 root     root             0 Feb 15 07:19 mcast_resolicit
-rw-r--r--    1 root     root             0 Feb 15 07:19 mcast_solicit
-rw-r--r--    1 root     root             0 Feb 15 07:19 proxy_delay
-rw-r--r--    1 root     root             0 Feb 15 07:19 proxy_qlen
-rw-r--r--    1 root     root             0 Feb 15 07:19 retrans_time
-rw-r--r--    1 root     root             0 Feb 15 07:19 retrans_time_ms
-rw-r--r--    1 root     root             0 Feb 15 07:19 ucast_solicit
-rw-r--r--    1 root     root             0 Feb 15 07:19 unres_qlen
-rw-r--r--    1 root     root             0 Feb 15 07:19 unres_qlen_bytes

/ # ls -l /proc/sys/net/ipv4/neigh/default/gc_thresh1

-rw-r--r--    1 root     root             0 Feb 15 07:19 /proc/sys/net/ipv4/neigh/default/gc_thresh1

And If I ran same thing to the sysbox container the output will be:-

[root@sysbox-deploy-k8s-wrgjz /]# ls -l /proc/sys/net/ipv4/neigh

total 0
dr-xr-xr-x 1 root root 0 Feb 15 11:46 eth0
dr-xr-xr-x 1 root root 0 Feb 15 11:46 lo

[root@sysbox-deploy-k8s-wrgjz /]# ls -l /proc/sys/net/ipv4/neigh/default

ls: cannot access /proc/sys/net/ipv4/neigh/default: No such file or directory

[root@sysbox-deploy-k8s-wrgjz /]# ls -l /proc/sys/net/ipv4/neigh/default/gc_thresh1

ls: cannot access /proc/sys/net/ipv4/neigh/default/gc_thresh1: No such file or directory

[tanwar57]

@rodnymolina ^^ any update on this please ?

[tanwar57]

@ctalledo @rodnymolina