Automatically run --appimage-extract-and-run when in Docker

[probonopd]

Consistent with our "it should just work" mantra, automatically run --appimage-extract-and-run when in a Docker container

• If the file /.dockerenv exists, and/or
• If /proc/1/cgroup begins with /lxc/ or /docker/

@TheAssassin re-iterates that one should not enable FUSE for security reasons in Docker containers...

[probonopd]

Outside Docker:

me@host:~$ cat /proc/1/cgroup 
12:rdma:/
11:memory:/
10:perf_event:/
9:cpuset:/
8:freezer:/
7:pids:/
6:net_cls,net_prio:/
5:devices:/
4:hugetlb:/
3:cpu,cpuacct:/
2:blkio:/
1:name=systemd:/init.scope
0::/init.scope
me@host:~$ cat /proc/cmdline 
BOOT_IMAGE=(loop)/casper/vmlinuz file=/cdrom/preseed/xubuntu.seed boot=casper iso-scan/filename=/boot/iso/xubuntu-18.04-desktop-amd64.iso quiet splash --- for-casper --> iso-scan/filename=/boot/iso/xubuntu-18.04-desktop-amd64.iso console-setup/layoutcode=de locale=en_US timezone=Europe/Berlin username=me hostname=host noprompt init=/isodevice/boot/customize/init max_loop=256

[TheAssassin]

There are strong reasons not to do this:

• AppImages != self-extracting archives. We should never ever promote that, hence the "hidden" flag. You were the one who suggested to do it as a flag, and also not to include this flag anywhere (e.g., in help texts).
• There is an optimization called $NO_CLEANUP. If set, the runtime will leave the files extracted, and won't have to re-extract everything on every invocation. This wouldn't be used at all any more, since noone could predict when it would help.
• The .dockerenv stuff just doesn't exist in a majority of containers. You can try yourself.
• I don't think the cgroup "method" you suggested is working on every Docker host. Please provide some references.

[probonopd]

Inside Docker on GitLab CI:

cat /proc/1/cgroup
11:perf_event:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
10:hugetlb:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
9:net_cls,net_prio:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
8:pids:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
7:memory:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
6:blkio:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
5:devices:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
4:cpu,cpuacct:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
3:freezer:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
2:cpuset:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1
1:name=systemd:/docker/a0182497e4c02394b5afca3fa0cfc1d7c500a2d27d55246a6b69cbd05d4981c1

[TheAssassin]

After the very intense discussion about this change (you know which I mean) in linuxdeployqt, I need to see some strong arguments why to make this the default after having had to make it a flag in the first place.

I'd be very open to promoting this flag in e.g., the FUSE error message, and the help texts. Also, I'd put it in docs.appimage.org.

[probonopd]

There is an optimization called $NO_CLEANUP.

It should just "do the right thing". Not even I knew (or want to know) about such details.

If running "properly" on Docker is not possible/recommended, then "just do the right thing".

I want my tools to have an "autopilot" for everything, that works for 99% of users.

[probonopd]

After the very intense discussion about this change (you know which I mean) in linuxdeployqt, I need to see some strong arguments why to make this the default after having had to make it a flag in the first place.

Indeed I was not happy about this, because I feared that everyone with a broken FUSE setup would not even notice the broken FUSE setup.

But if in Docker FUSE is not recommended, then why not "just do" what is optimal for FUSE, without bothering the Docker user?

[TheAssassin]

The flag works just fine for users, too (of course only once they know). That's not really convincing.

[probonopd]

That's the problem: Users will only learn about the flag once they already run into "problems". Hence it is perceived "problematic" whereas it should be perceived as "it just works"...
https://www.youtube.com/watch?v=hdv1sPcADGE

[TheAssassin]

Error messages are never bad. But they become really helpful when adding information how to resolve/work around the issue.

[probonopd]

Error messages where unexpected errors are, yes.
When you can already know that the "error" is not an error but expected (e.g., you say FUSE should not be used in Docker), then why run into an error in the first place - just "do the right thing"...

[TheAssassin]

How about showing a warning that we implicitly "add" --appimage-extract-and-run to the call?

[probonopd]

Something like

Running in Docker, hence extracting the AppImage before running it. Set APPIMAGE_DO_NOT_EXTRACT_IN DOCKER=1 if this is not intended.

would probably be an excellent idea, yes.

[TheAssassin]

I could live with that. But I still need to see your references re. "recognizing Docker".

[probonopd]

Sorry, I had meant to paste them into the first post.

• https://stackoverflow.com/a/20012536
• https://stackoverflow.com/a/25518345

[probonopd]

Would probably help in cases like this.