Some of my packages require a certain user to be logged out prior to running, so we made a disconnect-user function that checks for the user being logged in (via the Windows built-in command “query user”) and disconnects that session. However, in the case where no users are logged in, this writes to stderr, and even if I redirect that write to null in my powershell script with quser 2>$null it fails out the octopus step, stopping my deployment - even though the script finishes just fine in a normal (non-octopus) environment because the query step’s failure is wrapped in so many ways to catch the failure that no matter how it fails I keep moving on (and just report the user isn’t found in a non-failing way).
What do I have to do to get non-current-user session data without risking a fail here?
Thanks for reaching out, and sorry to hear that you’re having issues with your deployment script.
What Octopus mostly operates on is the exit code for the script, so in the case where you’re redirecting output to another stream, if it’s returning a non-zero exit code in these scenarios, it will likely still fail.
There’s a couple of option here to help resolve this:
You could add a try/catch block in the script, to handle that scenario and gracefully exit the script in the event they’re not logged in.
You could have the subsequent steps use a variable run condition, to continue to run, regardless of the outcome of the disconnect-user step.
Personally, I’d lean towards option 1, that way you have some more visibility into any potential errors outside of that particular one.
Turns out “query user” returns an exit code of 1 in some cases (for example, when being used to set a powershell variable) where “quser” -which is supposed to be the same command- returns a 0.
On a related tangent, if you don’t find a cleaner solution you can always $global:LASTEXITCODE = 0 after the dirty command.