A new semester starts in a few days and it's time to move stuff to the server, but, alas, I couldn't log in to the server. More specifically, ssh worked fine, but sftp failed. And it didn't just fail from my Ubuntu desktop, but from my XP netbook. Clearly it was a problem on the server, but I decided to do a little googling before opening a ticket and suggesting to the IT staff that something was screwed up. Besides, if sftp was broken on a university-wide basis, they probably already knew about it.
Google led here, which had a link to a post from a guy whose last name meshes well with my profile picture.
The problem could be that my .cshrc on the server was generating output that sftp didn't know to deal with. Another blogger somewhere gave a hint regarding what this was, and indeed the decimal 1114795883 in the error message was 0x42726f6b, or, in ASCII: "Brok'. Yes, something was broken, and 4 bytes was all that fit into the integer error message.
So I had to figure out why GL (the server, gl.umbc.edu) was generating extra characters. My default shell is tcsh, so the problem was most likely in the init file, .cshrc. I decided not to look at the system-wide .cshrc initially. I tossed some detritus from my .cshrc, and again failed to log in.
There was still a suspicious line, '/usr/bin/mesg n', at the beginning of the file. Why wasn't this inside the conditional that distinguished between interactive shells and others? I moved it into the conditional, and suddenly I was able to log in.
I had to chuckle. I added that line last semester when a student decided that if we were logged in on GL at the same time, he could chat with me. No. But I was clearly careless when I disabled write.
4 comments:
Thanks! I happened to have the same problem on my university's server except that the university added the line mesg n to all users files. It's probably still my fault though, since I am the one who showed the entire school how to use write which they then abused.
Glad to be of service.
It's amazing how much time we can waste on silly little things like this.
Thank you! I couldn't find where the wrong line is so I just moved the whole .cshrc file to cshrc and the problem was solved. I gueass I'll have to check the cshrc file line by line.
This was great, thanks! I converted the number to ASCII using this Ruby snippet: [459093051.to_s(16)].pack('H*') and it revealed a rogue ANSI color code: \e]4;. Cleaned up my .bashrc and all was well.
Post a Comment