error: fork/exec /bin/sh: argument list too long

[glennpratt]

What happened?

Running pulumi up on an existing stack on Linux fails.

Poking at the code, I see this is because of PULUMI_COMMAND_STDOUT/PULUMI_COMMAND_STDERR and the previous run containing rather long output.

pulumi-command/provider/pkg/provider/local/commandOutputs.go

Lines 73 to 78 in 7c5c4bd

	if out.Stdout != "" {
	cmd.Env = append(cmd.Env, fmt.Sprintf("%s=%s", util.PULUMI_COMMAND_STDOUT, out.Stdout))
	}
	if out.Stderr != "" {
	cmd.Env = append(cmd.Env, fmt.Sprintf("%s=%s", util.PULUMI_COMMAND_STDERR, out.Stderr))
	}

Since I don't use this feature and I don't always have the option of adjusting limits, I'd like an option to turn it off. Furthermore, I'd prefer if the option could be made off by default as well, as I don't generally need this information in state files.

Example

strace

sudo -E strace -E PATH=$PATH -u $USER -f -e trace=execve -s 1000 -v --signals=SIGPWR pulumi up 2> log

From log above, we can tell our command is not particularly long, the environment is massive.

execve("/bin/sh", ["/bin/sh", "-c", "ansible REDACTED"], ["SHELL=/bin/bash", ...REDACTED..., "PULUMI_COMMAND_STDOUT=ansible-playbook [core 2.14.6]\n  config file REDACTED"...]) = -1 E2BIG (Argument list too long)

Output of pulumi about

CLI
Version      3.75.0
Go Version   go1.20.5
Go Compiler  gc

Host
OS       ubuntu
Version  20.04
Arch     x86_64

Backend
Name           REDACTED
URL            file://~
User           REDACTED
Organizations

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[AMKamel]

Same here:

CLI          
Version      3.91.1
Go Version   go1.21.3
Go Compiler  gc

Plugins
NAME    VERSION
nodejs  unknown

Host     
OS       ubuntu
Version  22.04
Arch     x86_64

[AMKamel]

I was only able to work around this by pulumi stack export then edit the stack manually to make command "stdout": "" then pulumi stack import.

This is the reason, also I am heading towards always using no_log:true in ansible playbook to avoid this, but what was the objective of storing this stdout/stderr in state?

[glennpratt]

@antdking pointed me to #167 in Slack, thanks!

I think as a first change, it just needs to become opt-out.

I think it should be opt-in long term because it's very surprising and I'm not sure it can be reliably detected - and even if it can it's presumably going to require a pile of platform specific code. Also, it balloons the state file for something most probably don't depend on.

Personally, I'd consider deprecating it; it would seam preferable for users to immediately parse stdout into assets or something else to track after create, not at delete time. Stderr is for error messages and diagnostics, it doesn't match the spirit of the stream to implicitly store for future parsing.

[theneva]

@iwahbe I've just encountered this issue in @pulumi/command version 0.11.1 with a remote.Command. After some digging, it seems to me like #355 only addresses local.Commands. Am I completely missing something?

If I'm not missing anything, is this issue the right place to ask nicely for opt-out support for remote.Command as well?