search

NVIDIA / enroot

A simple yet powerful tool to turn traditional container/OS images into unprivileged sandboxes.
Apache License 2.0
648 stars 94 forks source link

enroot list -f behaviour on fedora #84

Closed EmilEOGG closed 3 years ago

EmilEOGG commented 3 years ago

Description

First, I start a container twice (also works with any number of containers. When running enroot list -f with started enroot containers on ubuntu, I get following output:

task-3c554ed8d06d7535969acfd17e8f5e519aad3ffd12f99ad7fc15d083fca0b6fa  539646  python  Sl+    Jun14    19:13:00  4026534798  4026534797  python -c my_super_command
                                                                                573074  python  Ssl    08:54    00:08     4026534795  4026534794  python -c mysupercommand

which clearly tells me that I started two instances of my containers. Running the same thing on fedora 33 yields:

task-3c554ed8d06d7535969acfd17e8f5e519aad3ffd12f99ad7fc15d083fca0b6fa                                                                                                                    
<unknown>                                                                       11645  python  Ssl    10:53    11:06  4026532818  4026532817  python -c mysupercommand
                                                                                12722  python  Ssl    11:00    03:42  4026532821  4026532820  python -c mysupercommand

On my fedora installation, all running containers are marked as unknown, and not associated with the name they should be. The task is still marked as built. Any ideas where this might come from? This poses no problem with the actual usage of enroot, but I want to use the information provided by enroot list -f (pid etc) in my programm. Thanks in advance for your hints/answers!

3XX0 commented 3 years ago

Um not sure, you can try to troubleshoot what's going on manually, the code doing this is here Check the output of /proc/<PID>/mountinfo for example to see why the rootfs is not visible there

EmilEOGG commented 3 years ago

I do not really know how to read this output, but following lines are present:

...
2132 2091 0:33 /home/emil/.local/share/enroot/archipel-task-3c554ed8d06d7535969acfd17e8f5e519aad3ffd12f99ad7fc15d083fca0b6fa/usr/local/cuda-10.2/compat/libcuda.so.440.118.02 /usr/lib/x86_64-linux-gnu/libcuda.so.440.118.02 ro,nosuid,nodev,relatime master:43 - btrfs /dev/nvme0n1p3 rw,seclabel,ssd,space_cache,subvolid=256,subvol=/home
...
2140 2091 0:33 /home/emil/.local/share/enroot/archipel-task-3c554ed8d06d7535969acfd17e8f5e519aad3ffd12f99ad7fc15d083fca0b6fa/.lock /.lock ro,nosuid,nodev,noexec,relatime - btrfs /dev/nvme0n1p3 rw,seclabel,ssd,space_cache,subvolid=256,subvol=/home

Edit: looking a bit further, I have the impression that the /proc/<pid>/root/.loc file does not exist.

3XX0 commented 3 years ago

Is your container name supposed to start with archipel- ? It is omitted in your output of enroot list -f

EmilEOGG commented 3 years ago

Yes it is, I removed it in the first snippet for clarity

EmilEOGG commented 3 years ago

@3XX0 Any idea?

3XX0 commented 3 years ago

Not sure no, I wasn't able to reproduce. Somehow the entry /proc/<PID>/mountinfo for / doesn't match the name in ENROOT_DATA_PATH

You can try to copy this snippet, clean it and see why the condition doesn't match in your particular environment

EmilEOGG commented 3 years ago

I do not use this environment anymore, so I won't be able to do more research. @3XX0 I think this can be closed if you weren't able to reproduce.

3XX0 commented 3 years ago

Closing, will reopen if I manage to reproduce