Broken process substitution for multipass launch command

[mattiaperi]

Describe the bug I manage multipass vms via bash scripts, providing cloud-init configuration files via process substitution (<(command)). Since multipass v1.2.0 multipass is not managing correctly this kind of inter-process communication providing error: No such file: /dev/fd/63 running command multipass launch. Please find hereunder the difference between v1.1.0 and v.1.2.0 (and v1.2.1 of course).

To Reproduce

macos:~ perim$ multipass version
multipass  1.1.0+mac
multipassd 1.1.0+mac

###########################################################################################
New Multipass 1.2.1 release
Ubuntu 20.04 LTS released!

Go here for more information: https://github.com/CanonicalLtd/multipass/releases/tag/v1.2.1
###########################################################################################

macos:~ perim$ k3s_cloud_init() {
> cat << EOF
> #cloud-config
> runcmd:
>  - '\curl -sfL https://get.k3s.io | sh -s -'
> EOF
> }

macos:~ perim$ multipass launch --name k3s --cpus 2 --mem 2G --disk 2G --cloud-init <(k3s_master_cloud_init)
Waiting for initialization to complete /^C

[...] [fast-forward uninstall 1.1.0 and install 1.2.0]

macos:~ perim$ multipass version
multipass  1.2.0+mac
multipassd 1.2.0+mac

###########################################################################################
New Multipass 1.2.1 release
Ubuntu 20.04 LTS released!

Go here for more information: https://github.com/CanonicalLtd/multipass/releases/tag/v1.2.1
###########################################################################################

macos:~ perim$ multipass launch --name k3s --cpus 2 --mem 2G --disk 2G --cloud-init <(k3s_master_cloud_init)
error: No such file: /dev/fd/63

Expected behavior I expect the correct management of the process substitution <(command) as inter-process communication, as before version 1.2.0

Logs No log related to the issue in /Library/Logs/Multipass/multipassd.log

Additional info

• macOS 10.14.6
• multipass version

multipass  1.2.0+mac
multipassd 1.2.0+mac

Additional context According to 1.2.0 release notes, my suspect is that the feature "check for --cloud-init file existence (#1491)" might have broken the normal behaviour, because of the type of file created by the process substitution (i.e. /dev/fd/63) that it only exists as long as the process is running.

[mdecalf]

Same issue for me :

multipass launch --name test --cpus 2 --mem 4096m --disk 40G --cloud-init /tmp/cloudinit.test.yaml
error: No such file: /tmp/cloudinit.test.yaml

ls -larth /tmp/cloudinit.test.yaml 
-rw-rw-r-- 1 max max 734 juin  15 09:32 /tmp/cloudinit.test.yaml

multipass --version
multipass  1.3.0
multipassd 1.3.0

[Saviq]

You can pass your cloud init as standard input using --cloud-init -, does this help?

[Saviq]

@mdecalf I suspect your issue with 1.3.0 is that of confinement, we can't read the file in /tmp since our /tmp is something different. You can also feed the file in using stdin.

[mattiaperi]

You can pass your cloud init as standard input using --cloud-init -, does this help?

If the question was for me, something like cat <(k3s_cloud_init) | multipass launch --name k3s --cpus 2 --mem 2G --disk 2G --cloud-init - is a valid workaround.

[Saviq]

If the question was for me, something like cat <(k3s_cloud_init) | multipass launch --name k3s --cpus 2 --mem 2G --disk 2G --cloud-init - is a valid workaround.

No need for cat <(…) here, is there? :)

[mattiaperi]

oh yes, of course, just k3s_cloud_init | multipass launch --name k3s --cpus 2 --mem 2G --disk 2G --cloud-init - will do. Nevertheless, this is a "workaround", I believe the "standard" process substitution should be restored anyway 👍 Thanks for the support @Saviq :)

[Saviq]

Sure, I agree we shouldn't have broke that.

[mattiaperi]

I remain at your disposal for any further test :)

[mdecalf]

@mdecalf I suspect your issue with 1.3.0 is that of confinement, we can't read the file in /tmp since our /tmp is something different. You can also feed the file in using stdin.

Yes. that's surely that. I didn't pay attention that 1.3.0 introduced strict containment. Thank you, the workaround works

[h0tbird]

I like it like this:

multipass launch --name master --cpus 2 --mem 2G --disk 4G --cloud-init - << EOF
#cloud-config
runcmd:
 - 'curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s - --node-taint node-role.kubernetes.io/master=effect:NoSchedule'
EOF