rtorrent not responding to keystrokes

[redherring]

I have been running rtorrent for a few months on a CentOS machine: Linux 2.6.16.33-xenU #2 SMP Thu Aug 2 18:09:26 PDT 2007 i686 athlon i386 GNU/Linux This OS is running on a VPS

-- Recently rtorrent has stopped responding to keystrokes. Usually it runs in a screen and i have tried running it under different usernames, with and without the rc file, in and out a screen but no luck. I have removed the lock files, session files and even uninstalled rtorrent using yum and reinstalled it

Once rtorrent is open we can upload files into watch and files are sent to Completed but no keystrokes are accepted by Rtorrent. When the rtorrent process is killed those keystrokes appear on the screen tty.

Has this happened to anyone? Assistance would be appreciated!

[H]

It has happened to me a few times before, very infrequently. Whenever that happened, top reported 100% CPU usage from rtorrent. I don't remember saving a backtrace or anything, sorry.

[anonymous]

Sounds like a bug in epoll not delivering events for stdin. Are you using epoll (it should say so when starting rtorrent)?

First make sure you're using the latest version of rtorrent (0.8.4).

Next try recompiling rtorrent using ./configure --without-epoll and see if that helps.

Replying to H:

It has happened to me a few times before, very infrequently. Whenever that happened, top reported 100% CPU usage from rtorrent. I don't remember saving a backtrace or anything, sorry.

I think that's something else. In that case rtorrent wouldn't successfully complete downloads like the OP says.

[anonymous]

Actually more likely it's a problem with the terminal being set to software flow control. Then ctrl-S will be interpreted as XOFF and stop all input/output in the terminal. Ctrl-Q is XON and re-enables it.

If this is the problem, all keys will work until you press ctrl-S once. Then they'll all work after you press ctrl-Q.

To fix it, turn off software flow control in your terminal or the screen session (ctrl-A f).  http://en.wikipedia.org/wiki/Software_flow_control

[redherring]

Sorry about the late feedback. Thank you everyone for their feedback.

The problem is still there as described earlier. I've tried to answer questions and include more information this time:

1) rtorrent is using epoll - I'm not sure how i would go about installing rtorrent with the without-epoll flag using 'yum'

2) rtorrent works 100% but no keystrokes are accepted until the rtorrent process is killed. Then all the keystrokes are shown as text in the tty

3) Problem also occurs when using rtorrent in normal tty and also inside a screen

4) running the screen first with -fn (flow control off) does not solve the problem

5) running rtorrent on this specific server as any other user does not solve the problem - All users' rtorrent's do not accept keystrokes

6) Server Information:

* Generally would like to run screen (Screen version: Screen version 4.00.02 (FAU) 5-Dec-03 ) * Server is running CentOS uname provides (Linux 2.6.16.33-xenU #2 SMP Thu Aug 2 18:09:26 PDT 2007 i686 athlon i386 GNU/Linux) * Rtorrent version is ( rtorrent,i386,0.8.0-1.el4.rf,rpmforge,430 k) yum install

7) Some background on the cause: I am not certain what could have caused this but rtorrent was running fine. A few torrents were uploaded (quite large) and some bad chunks occured, rtorrent crashed in the screen and when it was started up again in the same screen no keystrokes were registered. Subsequent attempts to fix this problem as above and in my initial ticket were unsuccessful

-- That's all i can think of for now. Advice appreciated.

[anonymous]

Apologies but something i forgot to add in my previous post: Other applications work fine in screen. (eg: shoutcast is responding) and other applications. rtorrent is the only black sheep in this case.

[butwinick]

I had had this problem too on my 2.6.20-gentoo-r8 #9 SMP Tue Jul 8 15:20:16 CEST 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux, since October(-ish) last year. Compiling libtorrent-0.12.2 and rtorrent-0.8.2 from source with the --without-epoll flag, as the second poster recommended, fixed the problem.

[anonymous]

I've made a patch that allows disabling epoll (or kqueue) via an environment variable. Then you don't have to recompile every time to turn it on or off for testing whether it helps.  http://ovh.ttdpatch.net/~jdrexler/rt/env_poll.diff

[redherring]

I'm definitely going to give this without epoll a try, it seems to be the problem. How would i use the .diff file on the previous post by anonymous without having to recompile rtorrent?

Help appreciated.

[anonymous]

You have to recompile it after applying the diff. It just allows you to disable and re-enable epoll without having the recompile yet again later. That makes testing it a bit easier.

It would also possibly be useful to run rtorrent with strace to see if the epoll calls are being done correctly, and to check whether rtorrent forgets to add stdin to epoll or whether the kernel fails to deliver events on it.

strace -e trace=epoll_ctl,epoll_wait,epoll_create rtorrent 2>rtorrent.strace

Just leave it running for a few seconds, try some keypresses and kill it. Then pastebin the rtorrent.strace output or attach it here.

[redherring]

I am still installing using yum. Can i use the diff or the recompile without epoll using yum ?

I guess i will have to recompile manually otherwise.

The strace results were:

epoll_create(100) = 3 epoll_ctl(3, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=4, u64=4}}) = 0 epoll_ctl(3, EPOLL_CTL_MOD, 4, {EPOLLIN|EPOLLERR, {u32=4, u64=4}}) = 0 epoll_wait(3, {}, 1024, 492) = 0 epoll_wait(3, {}, 1024, 144) = 0 epoll_wait(3, {}, 1024, 849) = 0 epoll_wait(3, {}, 1024, 148) = 0 epoll_wait(3, {}, 1024, 849) = 0 epoll_wait(3, {}, 1024, 148) = 0 epoll_wait(3, 812a520, 1024, 849) = -1 EINTR (Interrupted system call) +++ killed by SIGKILL +++

[anonymous]

Replying to redherring:

The strace results were:

epoll_create(100)                       = 3
epoll_ctl(3, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=4, u64=4}}) = 0
epoll_ctl(3, EPOLL_CTL_MOD, 4, {EPOLLIN|EPOLLERR, {u32=4, u64=4}}) = 0
epoll_wait(3, {}, 1024, 492)            = 0
...

Huh, really. The stdin descriptor is not being added to epoll here. But that code is run unconditionally in rtorrent. I don't know what could be the reason it's not added, but that's the cause why keys don't work in rtorrent.

[redherrring]

So is this fixable by installing manually without-epoll flag?

[jross25@yahoo.com]

What I did with my MBWE ,I had those problems when I updates rtorrent from 0.8.0 to 0.8.2 . I discovered that I had not updated the libtorrent. When I also updated the libtorrent , everything went back to normal. I think the versions was 0.12.4

Hope this helps.

[anonymous]

Im also havin this problem using the newest CVS rev 1095.

But it seems that the epoll value has been removed or change latley? configure: WARNING: unrecognized options: --without-epoll

Anyone got any suggestions for me?

[anonymous]

rtorrent 0.8.5 (or svn rev 1088 and up) has the RTORRENT_POLL env var, so you can use select based polling by setting RTORRENT_POLL=select without recompiling.

The --without-epoll is a libtorrent configure option, not rtorrent.

[anonymous]

i have the same problem with the latest SVN.

if i do an strace on the process thats semi-stuck I get this:

epoll_wait(3, {{EPOLLIN, {u32=0, u64=0}}}, 1024, 733) = 1 gettimeofday({1255387301, 268762}, NULL) = 0 gettimeofday({1255387301, 268790}, NULL) = 0 gettimeofday({1255387301, 268818}, NULL) = 0 gettimeofday({1255387301, 268846}, NULL) = 0

It repeats the above over and over and occasionally i get this:

epoll_wait(3, {{EPOLLIN, {u32=0, u64=0}}, {EPOLLOUT, {u32=136, u64=136}}}, 1024, 732) = 2 send(136, "\364\263\36499\5\25\373\200\372\224\4\252\3650\254\235b5\"b0\354\316\347\335\177\224\t\271\324\347\327"..., 889, 0) = 889 epoll_ctl(3, EPOLL_CTL_MOD, 136, {EPOLLIN|EPOLLERR, {u32=136, u64=136}}) = 0

[rakshasa]

Try the latest version, it includes a lot of fixes to these kinds of problems.