cli: cf ssh - container does not have app's environment (same issue 3 years later)

When I run cf ssh <app> the terminal session does not have the same environment that the application process has - my $PATH etc is not setup for the interpreter provided by the buildpack, etc.

I must always remember to run /tmp/lifecycle/launcher "app" "$SHELL" "" immediately after cf ssh.

When I raised this in Feb 2016 (3 years ago) in cloudfoundry/cloud_controller_ng#754 the answer was something about Windows support.

Can we please fix this now so that cf ssh always sets up the environment to match the application process from the buildpack?

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Comments: 19 (15 by maintainers)

Most upvoted comments

@drnic FYI, the CF docs at https://docs.cloudfoundry.org/devguide/deploy-apps/ssh-apps.html#ssh-env refer to a /tmp/lifecycle/shell helper binary that can replace the /tmp/lifecycle/launcher "app" "$SHELL" "" command.

I recall that after we encountered the port-mapping issues on Windows 2012R2 containers (cf-dev context at https://lists.cloudfoundry.org/g/cf-dev/topic/6332994), we also realized that there’s a theoretical problem with running the launcher command more than once: since it always invokes the .profile.d shell scripts, and since those scripts are arbitrary buildpack-provided content, there’s no guarantee that they’re idempotent or re-entrant. Ideally those scripts are purely local, in that they’re modifying only the environment of the process that sources them, but they could be modifying the mutable contents of the app in arbitrary ways (such as moving files or modifying their contents). For example, the Staticfile buildpack mvs and then erbs the provided nginx.conf file in https://github.com/cloudfoundry/staticfile-buildpack/blob/da1ba710b62633a9a922037e0bd63536203cf413/src/staticfile/finalize/data.go#L22-L23, and while I’d guess that this setup is idempotent I think it may not be re-entrant without a mutex around those two lines.

Thank you @tcdowney, appreciate the help. Moving this over to the CAPI github.