Opened 13 years ago

Closed 13 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)

kdump.txt (253.4 KB) - added by mezz 13 years ago.
Ran transmission-daemon with ktrace.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 13 years ago by spry

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 *:*

tcp4 10.2.0.84:9091 192.168.1.20:8929 tcp4 *:16050 *:* tcp4 10.2.0.84:9091 192.168.1.20:8927 tcp4 10.2.0.84:9091 192.168.1.20:8928

and a lot of this:

tcp4 10.2.0.84:60972 82.207.101.141:13978 tcp4 10.2.0.84:9091 192.168.1.20:8931 tcp4 10.2.0.84:60975 217.66.102.222:80

comment:2 Changed 13 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 13 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 13 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 13 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 13 years ago by charles

spry: I can't tell from your context in comment #5, did the behavior you saw in comment #5 occur while running 1.34 or trunk?

comment:7 Changed 13 years ago by spry

#5 mentions Transmission 1.34 installed from FreeBSD ports collection, so it should be release 1.34.

comment:8 Changed 13 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 13 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 13 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 13 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 13 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 13 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 13 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). ;-)

Changed 13 years ago by mezz

Ran transmission-daemon with ktrace.

comment:15 follow-up: Changed 13 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 13 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: Changed 13 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 13 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!

Note: See TracTickets for help on using tickets.