
The other day one of our projects at work had its Git master branch updated, I had been working on a few projects of my own with local branches based off of the earlier master branch. As usual, I had to pull down the latest version of master and merge it in to my local branch. My normal workflow is for this is:
# Ensure I switch to the master branch locally
git checkout master
# Pull down the latest version of the repo
git fetch -p origin
# Merge the pulled down origin in to my local master
git merge origin/master
# Switch to the branch I am working on
git checkout my-local-branch
# Merge the master branch in to my-local-branch
git merge master
The above works great and is my regular workflow. Most of the time I am able to merge things without conflict, however on this occasion there was a merge conflict. This wouldn’t be an issue, however I overlooked the git
output that indicated this to me.
What followed is I built a local .deb
package to test on one of our dev servers. I pushed to the package up, installed it via dpkg
and thought awesome, let’s give it a test. That’s when I ran in to a problem.
-bash: /usr/local/lib/path/to/the/script.sh: line 20: syntax error near unexpected token `<<<'
-bash: /usr/local/lib/path/to/the/script
.sh: line 20: `<<<<<<< HEAD'
Connection to dev.server closed.
Well that’s not good! Essentially the profile on the server loads a set of scripts by default and in one of those scripts was my merge error from git
. This caused a syntax error when reading the file and the profile failed to load, closing my SSH
connection.
I didn’t have direct root access so I started looking for a way to disable loading of the profiles in order to allow me to SSH in. This yielded the following to tack on to the SSH command:
ssh dev.server "bash --noprofile"
The above tacks executes the bash
command with the --noprofile
flag. This flag specifically prevents profiles from loading, including as explained in the Bash man pages and includes /etc/profile
as well as local user profiles such as /home/user/.bashrc
.
This is great, I was able to log in, however at the same time, what I found was that this also meant a TTY
terminal control session was not started and I was unable to sudo
in order to edit or remove the file. I kept running into the following error:
sudo: no tty present and no askpass program specified
After some searching I found a great article on shell-tips.com that shed some further light on to what was happening with regard to the lack of a TTY
session and the proposed fix being adding the -t
flag to the SSH
call. In a nutshell the flag provides a pseudo-sudo shell when the connection is made, allowing me to run sudo
commands without loading the profiles that were calling the corrupt file.
I was able to successfully amend the file on the server and restore access while resolving the merge conflict locally and successfully merging the branches. The above is a great way to get around issues where a script being called from a user profile fails and your SSH session fails to load.