Opened 12 years ago
Closed 12 years ago
#1288 closed Bug (fixed)
Daemon 1.34+ (6793) not responding via RPC at all on FreeBSD7.0
Reported by: | spry | Owned by: | charles |
---|---|---|---|
Priority: | Normal | Milestone: | None Set |
Component: | Daemon | Version: | 1.34 |
Severity: | Normal | Keywords: | daemon json rpc freebsd |
Cc: |
Description
Not via transmission-remote, not via web control, but 1.33 works great on same server. Output of transmission-daemon startup Transmission 1.34+ (6793) started Searching for web interface file "/home/downloader/.local/share/transmission/web/javascript/transmission.js" Searching for web interface file "/usr/local/share/transmission/web/javascript/transmission.js" Serving the web interface files from "/usr/local/share/transmission/web" Port Forwarding: Opened port 16050 to listen for incoming peer connections ..... list of 27 torrents .....
I've seen same and described it prior to #1270 (transmisson goes to core during json query). I do understand that I could be mistaken, or missed something etc.etc.etc..
Attachments (1)
Change History (19)
comment:1 Changed 12 years ago by spry
comment:2 Changed 12 years ago by charles
it sounds like this might be a firewall issue on your end. I haven't had any reports from other users about this issue?
comment:3 Changed 12 years ago by spry
- Resolution set to invalid
- Status changed from new to closed
No, its not a firewall. Built from tarball on FreeBSD 7.0 does not work at all, like I've described. Built from ports (with patches that are supplied with port to original makefiles) works great. So, I think that it's not your issue. But it's real pain to build head revision on PCBSD/FreeBSD system :(
comment:4 Changed 12 years ago by mezz
Does it makes any difference if you remove "-O3 -funroll-loops" from configure or replace it to "-O2 -fno-strict-aliasing -pipe"? I have built Transmission by via tarball a few times and I don't see any issue. I usually tweak the CFLAGS before I build it.
As for the patches in FreeBSD ports that you have pointed, I don't see much changes other than tweak CFLAGS and _pthread_flags. By the way, I am maintaining transmission ports and you can contact me via email (mezz_@_FreeBSD_org).
comment:5 Changed 12 years ago by spry
- Resolution invalid deleted
- Status changed from closed to reopened
Well. Some hours ago another "error" occurred. Transmission 1.34 from ports was working great, but at some moment any responses from via RPC (-remote or www interface) disappeared. So, I'll reopen the bug. Unfortunately I can not reproduce it. But I think it was connected with tracker responses. One of trackers I'm using gone down responding Tracker error: "[tracker specific info like UA-IX file empty]". I've restarted transmission in foreground mode, and while these messages appeared, daemon as usual after restart started to verity not finished torrents but was not responding to any RPC queries. Seems like embedded HTTP server hang up. As soon as that tracker gone up again, and I've restarted transmission daemon again, everything was back to normal again. I think it's not connected with original bug I've posted, but in any case...
comment:6 Changed 12 years ago by charles
comment:7 Changed 12 years ago by spry
#5 mentions Transmission 1.34 installed from FreeBSD ports collection, so it should be release 1.34.
comment:8 Changed 12 years ago by charles
I'd be interested to hear whether or not the problem persists in trunk. We've recently replaced the embedded http server software from shttpd with evhttp.
comment:9 Changed 12 years ago by spry
Ok. Please, can you advise me, how to build correctly trunk revision in debug mode of transmission-daemon under FreeBSD 7.0, since I've met a lot of troubles described above. Also, I'll use that for testing my win32 remote control for transmission, due to sometimes it crashes due to my requests, and I don't understand why, due to I'm not so familiar with *NIX systems to debug programs for them from server console :)
comment:10 Changed 12 years ago by mezz
To build it on FreeBSD, it's pretty much same with this:
http://trac.transmissionbt.com/wiki/Building
As for the with debug mode, add -g in CPPFLAGS by export it before run ./autogen.sh and gmake. But that -g is only useful for crash to collect the backtraces. If you want to figure why program isn't running correct then you can try to play with ktrace(1).
comment:11 Changed 12 years ago by spry
So, here is what I did (under BASH): export CPPFLAGS="-g" ./autogen.sh --disable-gtk gmake (previously I've used make) sudo gmake install
and restarted transmission daemon. It said: Transmission 1.34+ (6811) started rpc-server.c:403 in startServer; current context is 0x0 rpc-server.c:409 in startServer; new context is 0x28406190 evhttp_bind_socket returned 0 Port Forwarding: Opened port 16050 to listen for incoming peer connections ... bla-bla-bla.... torrents.. peers etc....
And thats all. No responses via web, no responses via -remote. Not a single byte from it via telnet on localhost 9091 even with +127.0.0.1. All normal if to build from ports tree
comment:12 Changed 12 years ago by mezz
I have not play with SVN version for new evhttp stuff yet. I just need to find the time to do that.
comment:13 Changed 12 years ago by spry
Seems to me that is not connected with replacing one internal server to other, as the problem was even on 6793, so that means that some Makefile changes from patches should be the problem/solution.
comment:14 Changed 12 years ago by mezz
I have tried SVN 6817 and evhttp does not work on FreeBSD. I don't know why yet. Here are what infos I have at the moment.
% transmission-daemon -f Transmission 1.34+ (6817) started rpc-server.c:403 in startServer; current context is 0x0 rpc-server.c:409 in startServer; new context is 0x8106190 evhttp_bind_socket returned 0 Port Forwarding: Opened port 51413 to listen for incoming peer connections
% transmission-remote -b -l * About to connect() to localhost port 9091 (#0) * Trying 127.0.0.1... * connected * Connected to localhost (127.0.0.1) port 9091 (#0) > POST /transmission/rpc HTTP/1.1 User-Agent: transmission-remote/1.34+ (6817) Host: localhost:9091 Accept: */* Content-Length: 360 Content-Type: application/x-www-form-urlencoded
I have tried to ran http://127.0.0.1:9091/transmission/web/ in browser and it just does nothing (hangs forever). I have ran it with ktrace, so maybe it will helping or not so I am going to attach in here.
I have no problem with shttpd, it works perfect. I think Transmission is a default BitTorrent? client in FreeNAS (probably from ports). ;-)
comment:15 follow-up: ↓ 17 Changed 12 years ago by spry
As I've told at the beginning, I've seen this already on 6793. Could you try on that revision?
comment:16 Changed 12 years ago by spry
I've tried rev 6819. Well, RPCs does work, but old entry for ACL of RPC like +0.0.0.0 does not work.
comment:17 in reply to: ↑ 15 ; follow-up: ↓ 18 Changed 12 years ago by mezz
Replying to spry:
As I've told at the beginning, I've seen this already on 6793. Could you try on that revision?
There is no point for me to try 6793 (as 1.34 works fine), since Transmission uses evhttp now. It's why I only try on evhttp version.
comment:18 in reply to: ↑ 17 Changed 12 years ago by spry
- Resolution set to fixed
- Status changed from reopened to closed
Replying to mezz:
Replying to spry:
As I've told at the beginning, I've seen this already on 6793. Could you try on that revision?
There is no point for me to try 6793 (as 1.34 works fine), since Transmission uses evhttp now. It's why I only try on evhttp version.
Yes, agree with that :) Dumb me :) Well, it now responses even from svn build, so I'm closing the bug. The bug is fixed :) Thanks!
Well.. I don't know how to prove this to you. Even telnet won't work locally, even from root 06:47:08 root[p0]taburetka:/home/spry/transmission/Transmission telnet 127.0.0.1 9091 Trying 127.0.0.1... Connected to localhost. Escape character is ']'. GET / HTTP/1.1
And thats it. I can wait forever, but sockstat gives ... tcp4 *:9091 *:*
and a lot of this: