The Wayback Machine - https://web.archive.org/web/20201028020246/https://github.com/canonical/multipass/issues/1589
Skip to content

/ multipass

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Broken process substitution for multipass launch command #1589

Open
mattiaperi opened this issue Jun 13, 2020 · 9 comments
Open

Broken process substitution for multipass launch command #1589

mattiaperi opened this issue Jun 13, 2020 · 9 comments
Labels
bug good first issue help wanted

Comments

@mattiaperi
Copy link

@mattiaperi mattiaperi commented Jun 13, 2020 •
edited

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.
@mattiaperi mattiaperi added the bug label Jun 13, 2020
@mdecalf
Copy link

@mdecalf mdecalf commented Jun 15, 2020 •
edited

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
Copy link
Collaborator

@Saviq Saviq commented Jun 15, 2020

You can pass your cloud init as standard input using --cloud-init -, does this help?
@Saviq Saviq added question and removed bug labels Jun 15, 2020
@Saviq
Copy link
Collaborator

@Saviq Saviq commented Jun 15, 2020

@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
Copy link
Author

@mattiaperi mattiaperi commented Jun 15, 2020 •
edited

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
Copy link
Collaborator

@Saviq Saviq commented Jun 15, 2020

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
Copy link
Author

@mattiaperi mattiaperi commented Jun 15, 2020

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
Copy link
Collaborator

@Saviq Saviq commented Jun 15, 2020

Sure, I agree we shouldn't have broke that.
@mattiaperi
Copy link
Author

@mattiaperi mattiaperi commented Jun 15, 2020

I remain at your disposal for any further test :)
@mdecalf
Copy link

@mdecalf mdecalf commented Jun 15, 2020

@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug good first issue help wanted
3 participants
@Saviq @mdecalf @mattiaperi
You can’t perform that action at this time.