Deployments are failing since the environmental variables octopus server are getting from the path are no complete.
For example “ip” command works as expected locally on the server but it is not found on the path from the Octopus server
Output from Octopus server:
Echo “$PATH” /usr/local/bin:/usr/bin
Which ip which: no ip in (/usr/local/bin:/usr/bin) Error
The remote script failed with exit code 1 Fatal
Output logged in locally on the server
[octopus@server1~]$ hostname;whoami;echo “$PATH”; which ip server1.example.com
Why Octopus server is not getting the right path ?
Tentacles are fully updated. Octopus verison 2020.1.18
Octopus will be using the $PATH variable that is provided to it by the operating system. The most likely explanation for the difference is that the server is configured to provide a different path depending on the user, connection method or some other factor.
Can you please advise on the following?
Is this script running directly on the Octopus Server, in a worker or on a Tentacle? Is any form of containerisation in use? If a Tentacle which connection type is being used?
When you run the commands manually are you logged in using the same method as Octopus? For example, if Octopus is connecting using SSH, do you see the same issue when using SSH?
Has this process worked previously? If yes, has anything changed recently (such as an operating system upgrade)?
Yes, local logging (where the $PATH is show as it is, and it works as expected) is done via SSH, same as the Octopus connection
The difference between when it works and it does not (different machines), is the user used to connect the tentacle. If the user is “root”, Octopus get the $PATH right, if the user is “Octopus”, Octopus server strips out the " /usr/local " from the $PATH
Just jumping in for Charles here, as he’s away this week.
What’s likely happening here is that these are being set in your .bashrc file, which has an explicit call to exit if bash is not being run interactively when called through Octopus (but it is via an interactive SSH session).
If you look in your .bashrc, you should see the lines at or near the top:
# If not running interactively, don't do anything
case $- in
To get around this, you could put your path mods in an $HOME/.ssh/environment file, or if this changes a lot, you could add it before the above code block to set it even for non-interactive sessions.