Error: input: Resource temporarily unavailable

[Robert Watson]

On Thu, 27 May 2004, Gustafson, Tim wrote:

> I am getting the following error in "vi" pretty consistently: 
> 
> Error: input: Resource temporarily unavailable
> 
> Usually I get this at every attempt I make to run vi.  Every now and
> then I'll somehow manage to stay in vi however long I want.  It seems
> that if it's going to bomb, it bombs in the first 30 seconds of running
> the program.  Otherwise, it doesn't happen at all. 
> 
> No other programs do this, as far as I know. 
> 
> I have tried installing the nvi-devel port to see if maybe this is fixed
> in a new version, but it does the exact same thing.  I even rebuilt the
> kernel and world after a cvsup to make sure something wasn't broken, but
> that didn't work wither.  I have tried switching shells from bash to
> just sh to see if it's related somehow to bash, but that did not have
> any effect either. 
> 
> I am currently running FreeBSD 4.9-RELEASE-p8 i386
> 
> This problem pops up about once a month and then seems to go away by
> itself after a few days, but I would really like to know what is causing
> it.  I have searched the FreeBSD mailing list archives and found a few
> references to changing some flag in my shell, and I followed their
> instructions, but it did not help. 
> 
> Obviously, it is a real pain in the neck since I use vi exclusively and
> I despise having to us pico for anything. 
> 
> If anyone has any idea how I can fix this, I would really appreciate it. 

Are you using this when SSH'd into a remote system?  I started seeing this
after the SSH changed to introduce "untrusted X11 forwarding", but it
lasted for about a day and then vanished.

FYI, the problem is likely that a system call is returning EAGAIN, and
that's getting pushed up through the vi ncurses or another component which
doesn't know how to handle that error code, so simply exits.  There used
to be a similar problem with EINTR as a result if the window change signal
and certain bits of vi's state machine.  If you can reproduce this easily,
could you try running vi under ktrace, then see if you can trigger the
problem?  The last few dozen lines of kdump would be very helpful, as it
would identify the system call that's returning EAGAIN.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research