LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 01-16-2011, 05:33 AM   #1
sylye
Member
 
Registered: Feb 2003
Location: Malaysia
Distribution: Mandrake 9.1, Debian 3.1,Slackware 13.37
Posts: 47

Rep: Reputation: 0
Unhappy vim freeze at startup when in ssh session


Hi,

I have been using vim for years without problem but today I have met one weird scenario which I can't solve it after troubleshoot for the whole day and google around. This happen to my 2 machine at home which both installed with Slackware 13.1

Here is the scenario. I just got my laptop done setup with Slackware 13.1 and I ssh from my laptop to my desktop that have vim installed. I use one of my laptop virtual console to do the ssh login to that desktop. When I'm remotely in that desktop, I fire up a simple
Code:
vim
and then the whole session hang there without any response. Ctrl-C didn't kill it and I need to kill it from another ssh session.

If I am in my laptop KDE, fire up Konsole and ssh into that desktop, and do the same, everything runs fine.

And if I'm in laptop virtual console, ssh to the desktop, do the following all facing the same result, freeze and no response:
Code:
vim -i NONE
vim -X
And if I do the following, it will work fine:
Code:
vim -u NONE
vim -u ~/.vimrc
and the .vimrc sit in that desktop ~/ is as followed:
Code:
colorscheme desert
set nobackup
and the :version output of that vim in that desktop is :
Code:
:version                                                                                  
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled May 12 2010 01:38:07)
Included patches: 1-416
Compiled by <volkerdi@slackware.com>
Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent -clientserver -clipboard +cmdline_compl
+cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork() +gettext
 -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap
+menu +mksession +modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse
 +mouse_xterm +multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra +perl +postscript +printer
+profile +python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +startuptime +statusline
-sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
-toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu
+windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE  -fstack-pro
tector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -I/usr/lib/perl5/5.10.1/i486-linux-thread-mult
i/CORE  -I/usr/include/python2.6 -pthread
Linking: gcc   -Wl,-E   -L/usr/local/lib -o vim       -lncurses -lacl -lgpm   -Wl,-E  -fstack-protector -L/usr/local/l
ib  -L/usr/lib/perl5/5.10.1/i486-linux-thread-multi/CORE -lperl -lcrypt -lutil -lc -L/usr/lib/python2.6/config -lpytho
n2.6 -lpthread -lutil -lm -Xlinker -export-dynamic
And I have totally no problem if I'm physically in front of my desktop doing vim both in virtual console and in KDE Konsole.

And using vim in that laptop virtual console and Konsole itself, all works fine. The problem only occur when I ssh into the desktop using a virtual console.

It seems like if I supply the vim specifically a .vimrc, it will work fine. It seems like it's taking forever to find the .vimrc file. But if I remove that .vimrc, it will also freeze. If I create a new user in that desktop and ssh again and then do vim, it will also freeze.

Any one face this strange problem before ? I know I can still use Konsole to ssh and do vim, but I wish to solve this and since vim is been there for so long, I think this problem will most likely faced by someone before.

Thanks and appreciated for the sharing.
 
Old 01-16-2011, 09:57 AM   #2
DonnieP
Member
 
Registered: Jan 2008
Location: Richmond, VA USA
Distribution: Slackware
Posts: 144

Rep: Reputation: 29
Unable to replicate on several 13.1 machines here. You might try running strace on the pid of the hung process to see what it's doing (using your pid of course):

Code:
# strace -p 10546
 
Old 01-17-2011, 12:01 PM   #3
sylye
Member
 
Registered: Feb 2003
Location: Malaysia
Distribution: Mandrake 9.1, Debian 3.1,Slackware 13.37
Posts: 47

Original Poster
Rep: Reputation: 0
I nearly can't simulate this error yesterday. But just now after I wait long enough after the desktop booted, I login again from my lapotp and fire up 'vim' and I successfully replicate the error and do a strace -p the_problematic_pid. Here is what it shows:

Code:
Process 3677 attached - interrupt to quit
connect(4, {sa_family=AF_FILE, path="/dev/gpmctl"...}, 13 <unfinished ...>
Process 3677 detached
And except from the strace result, I got more progress. I notice my laptop KDE Konsole is using environment TERM=xterm, so I do a test to confirm that difference is making the Konsole vim will not hang. So, in the KDE Konsole, I ssh to the desktop, and do
Code:
TERM=linux
vim
it freeze.

And
Code:
TERM=xterm
vim
,thing works fine.

So why is it TERM=linux will cause problem on a ssh session vim ? I go back to my desktop and make TERM=linux in both virtual console and Konsole, no problem occur.
 
Old 01-17-2011, 01:46 PM   #4
gezley
Member
 
Registered: Sep 2009
Location: Ireland
Distribution: Slackware-64, Crux-64, NetBSD-64
Posts: 570

Rep: Reputation: 273Reputation: 273Reputation: 273
Quote:
Originally Posted by sylye View Post
And except from the strace result, I got more progress. I notice my laptop KDE Konsole is using environment TERM=xterm, so I do a test to confirm that difference is making the Konsole vim will not hang. So, in the KDE Konsole, I ssh to the desktop, and do
Code:
TERM=linux
vim
it freeze.

And
Code:
TERM=xterm
vim
,thing works fine.

So why is it TERM=linux will cause problem on a ssh session vim ? I go back to my desktop and make TERM=linux in both virtual console and Konsole, no problem occur.
Just a stab in the dark here: would it have anything to do with a custom console font you might have selected?
 
Old 01-17-2011, 04:02 PM   #5
rg3
Member
 
Registered: Jul 2007
Distribution: Slackware Linux
Posts: 514

Rep: Reputation: Disabled
The strace output appears to be vim trying to connect to GPM, doesn't it?
 
1 members found this post helpful.
Old 01-18-2011, 12:50 PM   #6
sylye
Member
 
Registered: Feb 2003
Location: Malaysia
Distribution: Mandrake 9.1, Debian 3.1,Slackware 13.37
Posts: 47

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by rg3 View Post
The strace output appears to be vim trying to connect to GPM, doesn't it?
Your eyes are sharp Yes, now the problem is getting closer to be solved. I further more the testing and I found out the culprit related with gpm and TERM=linux

Firstly I use my laptop virtual terminal(VT) to ssh into the desktop and making sure the gpm is running:
Code:
root      6191  0.0  0.0   2020   532 ?        Ss   00:52   0:00 /usr/sbin/gpm -m /dev/mouse -t imps2
Then I fire up a 'watch' to monitor the gpm behaviour:
Code:
watch -d -n 1 "netstat -ap|grep gpm"
and I got this:
Code:
unix  2      [ ACC ]     STREAM     LISTENING     35444    6191/gpm            /dev/gpmctl
unix  2      [ ]         DGRAM                    35442    6191/gpm
Then by making sure the TERM=linux, I fire up a 'vim' and it works fine and I close it and the monitoring of gpm got this:
Code:
unix  2      [ ACC ]     STREAM     LISTENING     35444    6191/gpm            /dev/gpmctl
unix  2      [ ]         STREAM     CONNECTING    0        -                   /dev/gpmctl
unix  2      [ ]         DGRAM                    35442    6191/gpm
I repeated that step SIX time and I will got the following:
Code:
unix  2      [ ACC ]     STREAM     LISTENING     35444    6191/gpm            /dev/gpmctl
unix  2      [ ]         STREAM     CONNECTING    0        -                   /dev/gpmctl
unix  2      [ ]         STREAM     CONNECTING    0        -                   /dev/gpmctl
unix  2      [ ]         STREAM     CONNECTING    0        -                   /dev/gpmctl
unix  2      [ ]         STREAM     CONNECTING    0        -                   /dev/gpmctl
unix  2      [ ]         STREAM     CONNECTING    0        -                   /dev/gpmctl
unix  2      [ ]         STREAM     CONNECTING    0        -                   /dev/gpmctl
unix  2      [ ]         DGRAM                    35442    6191/gpm
At the 7th attempt to fire up a 'vim', it replicate the error and then it got freeze at the VT.

Now I ssh to the desktop again and shutdown the gpm and I got all the above 'connecting' entry killed. A subsequent of 'vim' will work fine since no more gpm connection being invoked. This mean my desktop can't have gpm turn on if I want to ssh in from my laptop and use vim??

Now I fire up gpm again by '/etc/rc.d/rc.gpm start':
Code:
unix  2      [ ACC ]     STREAM     LISTENING     42261    7094/gpm            /dev/gpmctl
unix  2      [ ]         DGRAM                    42224    7094/gpm
Again, ssh to the desktop and this time I change TERM=xterm, fire up 'vim' a few times,but now I still got the gpm connection remain the same:
Code:
unix  2      [ ACC ]     STREAM     LISTENING     42261    7094/gpm            /dev/gpmctl
unix  2      [ ]         DGRAM                    42224    7094/gpm
and no problem at all using vim since the gpm connection is not full.

So, apparently, when ssh in to a machine with TERM=linux and having gpm running, fire up a vim SEVEN time will cause the above problem. Now, questions are:

1)Is this a bug of gpm ? (it is gpm-1.20.1-i486-5) or it's normal for gpm to behave like that ? Why is it gpm doing a 'CONNECTING' ?
2)If it's not a bug of gpm, then problem is the $TERM I use. Should I or shouldn't I use TERM=linux in a ssh session or TERM=linux is not a good idea at all and I should use TERM=xterm ? (Is there a reason to use TERM=linux at all?)

Thanks for the input from you guys and it really help a lot in solving this. Hope to have more input about this issue. Apology for my lack of knowledge in this but I will be glad to learn more from the sharing.

I looked into the net and think the following link related to my issue:

http://bugs.gentoo.org/show_bug.cgi?id=219577
http://www.linuxquestions.org/questi...ocally-849708/
http://www.linuxquestions.org/questi...solved-650061/
 
Old 04-02-2011, 05:50 PM   #7
amzeroot
LQ Newbie
 
Registered: Apr 2011
Posts: 2

Rep: Reputation: 0
(slackware 13, vim 7.2.416)
Hi, nice to meet you on this forum...
sorry to unearth this topic, but it might be helpful for someone who has that same pb again.
I had just the same, like invoking vim once, twice, was ok, then the third frozed the session... and then nothing to do except kill it from another virtual console. And at some other times, no bug anymore for weeks. And everything's okay under X.
Today the bug came back, I decided to attack seriously. I went on doing kind of a debugging on /usr/share/vim/vimrc and it appeared that commenting that line: set mouse=a resolved everything. So it became clear that somewhere interaction between gpm driver and vim was the key. But a less drastic solution seems possible: just move a bit the mouse when everything gets frozen at vim startup, and it'll come gently! (that's the case for me at least).
Cheers

Last edited by amzeroot; 04-02-2011 at 05:51 PM.
 
Old 04-03-2011, 07:08 AM   #8
audriusk
Member
 
Registered: Mar 2011
Location: Klaipėda, Lithuania
Distribution: Slackware
Posts: 248

Rep: Reputation: 107Reputation: 107
Well, in my .vimrc I have this setting for console Vim

Code:
" Don't need the mouse in console.
set mouse=
and something like this for GVim

Code:
" This section is bigger in my .vimrc, this is just an excerpt.
if has('gui_running')
  " Mouse on GUI comes handy.
  set mouse=a
endif
This way I don't have any mouse related issues. I understand that it's not a real solution, but thought that it might be helpful for some.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SSH concurrent session limit and idle session time out lasygsd Linux - Newbie 3 10-30-2014 08:56 AM
Strange vim startup behavior when accessed via cygwin ssh nicklaszlo Linux - Desktop 4 03-13-2010 11:49 PM
Vim problem with tabs and session nicostcado Linux - Software 1 12-14-2008 12:03 PM
Session disconnect causes thread freeze brodsky99 Linux - Newbie 1 10-07-2008 09:13 PM
X-Window Freeze when closing X Session smitchel Linux - Software 3 11-12-2001 12:37 PM


All times are GMT -5. The time now is 01:12 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration