[SOLVED] daemon hangs; doesn't run without -f

[awk]

Hi everyone,

I have now compiled transmission on Nexenta (Open Solaris clone) successfully, and installed it successfully.

I have a problem getting to the web interface or actually making transmission-daemon do anything.

I get it to start with -f so I should be getting something but all I am seeing on that window is

Transmission 1.41b4 (7408) started

And if I for example try to list active torrents with :

transmission-remote 9091 -l

It just hangs there until I press CTRL-C (is that normal ? )

If I try to add a torrent or start downloading a torrent, nothing happens, it just sits there and does nothing. No cpu hike, nothing.


I am running on

SunOS 5.11
AMD 64 bit cpu
4 GB memory and plenty of disk
I have PHP installed

PHP 5.2.8 (cli) (built: Dec 21 2008 02:30:44)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

and curl and everything else, otherwise nothing would run.
Here is my settings file :

Code: Select all

   
{   
    "blocklist-enabled": 1, 
    "download-dir": "\/export\/home\/torrents", 
    "download-limit": 100, 
    "download-limit-enabled": 0, 
    "encryption": 1, 
    "max-peers-global": 200, 
    "peer-port": 51413, 
    "pex-enabled": 1, 
    "port-forwarding-enabled": 0, 
    "rpc-authentication-required": 0, 
    "rpc-password": "", 
    "rpc-port": 9091, 
    "rpc-username": "", 
    "rpc-whitelist": "127.0.0.1, 10.0.1.*", 
    "upload-limit": 100, 
    "upload-limit-enabled": 0
}

Mind you I get no errors anywhere, is there a log anywhere ?
When I do transmission-remote with -b for debugging, I get this info :

Code: Select all

/usr/local/bin/transmission-remote 9091  -b -l
posting:
--------
{
    "arguments": {
        "fields": [
            "eta", 
            "id", 
            "leftUntilDone", 
            "name", 
            "peersGettingFromUs", 
            "peersSendingToUs", 
            "rateDownload", 
            "rateUpload", 
            "sizeWhenDone", 
            "status", 
            "uploadRatio"
        ]
    }, 
    "method": "torrent-get", 
    "tag": 0
}

--------
* 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.41b4 (7408)
Host: localhost:9091
Accept: */*
Content-Length: 396
Content-Type: application/x-www-form-urlencoded

And nothing else happens.

When I try to open up a browser with the url http://<ip>:9091/
It just hangs there, no error what so ever.

I have tried a few version like 1.40 release and 1.41b4 without any luck.


Best regards,

Trausti

Any help would be appreciated. Hope someone can help.

[rb07]

You probably have something else listening to port 9091, and I don't know why transmission-daemon doesn't show an error saying "unable to bind to port 9091", could be a bug.

Try to see what it is, or if it really is transmission-daemon: 'netstat -an | grep LISTEN | grep 9091' Solaris doesn't show the info about the program, you'll have to use lsof for that (if you have it installed) or just test with and w/o transmission-daemon running.

Also check with 'ldd /usr/local/bin/transmission-daemon' to see if it was linked with the correct libraries (i.e. you may have different versions of the same library, one in /usr/lib another in /usr/local/lib or any other place used, in Solaris /usr/sfw/lib was the open source path).

BTW, transmission 1.41beta4 won't let you connect using transmission-remote until you hack the configuration... but it shows a message to the effect. I would test with one of the stable versions.

[awk]

Hi and thanks for the reply.

There is nothing running on port 9091

netstat -an | grep LISTEN | grep 9091

returns nothing, but when transmission is running, it does return :

# netstat -an | grep LISTEN | grep 9091
*.9091 *.* 0 0 49152 0 LISTEN

But I still can't get to the web interface, that is what I am hoping to accomplish, to get the web interface and be able to use transmission that way.


If there is any information you want from the machine please ask, I really want this fixed. I also have 1.4 release compiled, and a few other versions, all show the exact same results. It looks like it work, but no web interface.

Unless I am missing something, with the b1 version, what is the url to the web interface ? I am running the machine on 10.0.1.94 ip

[rb07]

But I still can't get to the web interface, that is what I am hoping to accomplish, to get the web interface and be able to use transmission that way.

If there is any information you want from the machine please ask, I really want this fixed. I also have 1.4 release compiled, and a few other versions, all show the exact same results. It looks like it work, but no web interface.

Unless I am missing something, with the b1 version, what is the url to the web interface ? I am running the machine on 10.0.1.94 ip

The Web client is at http://10.0.1.94:9091/, just like you describe.

You could be running into a couple of problems, so first you have to find out which one it is:

• Is the daemon running fine? Try again your 'transmission-remote -l' test, no need to put the port since it is the default. Does this test still hang? If it does, check what I said 'ldd <path-to>/transmission-daemon' and also 'ldd <path-to>transmission-remote';
• With version 1.4x (x > 0) the whitelist is mandatory (intended or not is another discussion), so by default only your server has authorized access, if you want to test from another computer you have to add it (or the LAN) to the whitelist. So I would do a local test using http, either curl or 'wget http://127.0.0.1:9091/', if you get "HTTP request sent, awaiting response... 401 Unauthorized" that means you have a user/password defined, which is different from the response that says you're (computer is) not on the whitelist.

[awk]

Thank you so much for a quick reply.

Everything just hangs, and this is the parameter I run the daemon

transmission-daemon -a 127.0.0*,10.*

and curl just keeps connecting and same with wget, both localhost and same lan.

As for ldd

$ ldd /usr/local/bin/transmission-daemon
librt.so.1 => /lib/librt.so.1
libresolv.so.2 => /lib/libresolv.so.2
libintl.so.3 => /lib/libintl.so.3
libiconv.so.2 => /lib/libiconv.so.2
libc.so.1 => /lib/libc.so.1
libcurl.so.4 => /usr/local/lib/libcurl.so.4
libnsl.so.1 => /lib/libnsl.so.1
libz.so.1 => /usr/lib/libz.so.1
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
libm.so.2 => /lib/libm.so.2
libsocket.so.1 => /lib/libsocket.so.1
libpthread.so.1 => /lib/libpthread.so.1
libgcc_s.so.1 => /lib/libgcc_s.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libdl.so.1 => /lib/libdl.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1

and

$ ldd /usr/local/bin/transmission-remote
librt.so.1 => /lib/librt.so.1
libresolv.so.2 => /lib/libresolv.so.2
libintl.so.3 => /lib/libintl.so.3
libiconv.so.2 => /lib/libiconv.so.2
libc.so.1 => /lib/libc.so.1
libcurl.so.4 => /usr/local/lib/libcurl.so.4
libnsl.so.1 => /lib/libnsl.so.1
libz.so.1 => /usr/lib/libz.so.1
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
libm.so.2 => /lib/libm.so.2
libsocket.so.1 => /lib/libsocket.so.1
libpthread.so.1 => /lib/libpthread.so.1
libgcc_s.so.1 => /lib/libgcc_s.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libdl.so.1 => /lib/libdl.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1

There is no firewall on this machine or on the local lan. A simple netscan says port 9091 is open, and telnet to port 9091 just accepts connections.
I feel like there is just some simple stuff preventing this, unfortunately it doesn't seem like transmission can log connections and such, that would really be helpful.

[rb07]

I feel like there is just some simple stuff preventing this, unfortunately it doesn't seem like transmission can log connections and such, that would really be helpful.

But there is! Run your daemon in the foreground:

Code: Select all

# transmission-daemon -a 127.0.0* -f
Transmission 1.42 (7495) started
RPC Server: Adding address to whitelist: 127.0.0*
RPC Server: Serving RPC and Web requests on port 9091
RPC Server: Whitelist enabled
Port Forwarding: Opened port 51413 to listen for incoming peer connections

I just did to check what happens when you use "127.0.0*" as you did... not a problem. OK, it doesn't quite log all connections, much less those that didn't make it, but at least it shows that the daemon is working.

So, it must be something else... have you tried network sniffing? Does Nexenta has snoop? an alternative I sometimes install is tcpflow (which depends on libpcap).

[awk]

transmission-daemon -a 127.0.0* -f
Transmission 1.41b4 (7408) started

This is all I get, not all the extra text

[rb07]

transmission-daemon -a 127.0.0* -f
Transmission 1.41b4 (7408) started

This is all I get, not all the extra text

OK, it seems that the problem is the daemon, it still binds the 9091 port but never shows the message about it... what about the other port, 51413? is it binded?

Forget about network sniffing, useless idea since the daemon seems to be stuck. Usual suspects (under Solaris) are libz, the whole gcc/binutils suite (never use a .0 version); but I still think one of the libraries is the problem, but nothing seemed out of the ordinary in the ldd output (they're just in a different place compared to Solaris 10).

There's 2 ways I would go about solving this: debugging/tracing, but first a build log would be helpful. If you can change to version 1.42 it would be better, something like:

Code: Select all

$ wget http://download.m0k.org/transmission/files/transmission-1.42.tar.bz2
$ tar xvf transmission-1.42.tar.bz2
$ cd transmission-1.42
$ script build.log
$ ./configure
...
^D

The last Ctrl-D closes the log; the ellipsis means the usual "make, make check, make install" cycle, there will be lots of interesting bits on that log, don't forget to do a 'make check' so we can see if those few tests passed.

[Jordan]

Try a build from svn trunk or one of the nightly tarballs... Ticket #1619, which is fixed in trunk for 1.50, may be related to this issue.

[qwerty0987654321]

I have the same problem too.

OS: Solaris 11 (solaris express: community edition build 105)

Tried versions: 1.34, 1.42

here is stack of running daemon: it is rather weird

Code: Select all

bash-3.2# pstack 1050
1050:   /opt/transmission1.42/bin/transmission-daemon
-----------------  lwp# 1 / thread# 1  --------------------
 d16a0975 nanosleep (8047c08, 0)
 d168caea usleep   (f4240, 0, 0, 1) + 42
 0805ea78 main     (1, 8047da0, 8047da8) + 590
 0805e380 _start   (1, 8047e5c, 0, 8047e8a, 8047e8e, 8047ea6) + 80
-----------------  lwp# 2 / thread# 2  --------------------
 08064ba0 ThreadFunc(), exit value = 0x00000000
        ** zombie (exited, not detached, not yet joined) **

[Jordan]

I have the same problem too.

OS: Solaris 11 (solaris express: community edition build 105)

Tried versions: 1.34, 1.42

Well, now is the time to try out 1.50 beta 1 and let me know if it's still broken there.

The second thing to try, if 1.50 beta 1 is still broken, is to comment out the #ifdef checks in daemon/daemon.c lines 94-100, and just set "#define USE_TR_DAEMON", rebuild, and let me know if that works.

[luzz]

Hello
I have similar problem on my uClibc box.
Upgrading Transmission to 1.50b1 doesn't fix it.
Rebuilding with #define USE_TR_DAEMON added - still nothing
The only fix that works for me was posted here but it is far from perfect.

[qwerty0987654321]

The only fix that works for me was posted here but it is far from perfect.

It doesn't work on Solaris11, I've already tried it.

[qwerty0987654321]

Well, now is the time to try out 1.50 beta 1 and let me know if it's still broken there.

Here is how to I've managed to build it in first place:

Code: Select all

 ./configure  --prefix=/opt/transmission1.50b --enable-daemon --disable-cli --disable-gtk --disable-wx
make 
...
gcc -DPACKAGE_NAME=\"transmission\" -DPACKAGE_TARNAME=\"transmission\" -DPACKAGE_VERSION=\"1.50b1\" -DPACKAGE_STRING=\"transmission\ 1.50b1\" -DPACKAGE_BUGREPORT=\"http://trac.transmissionbt.com/newticket\" -DPACKAGE=\"transmission\" -DVERSION=\"1.50b1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STRLCPY=1 -DHAVE_DIRNAME=1 -DHAVE_BASENAME=1 -DHAVE_STRCASECMP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_POSIX_FALLOCATE=1 -DHAVE_PTHREAD=1 -DHAVE__TMP_DUMMY1_ZLIB_H=1 -DHAVE_ZLIB=1 -D_FILE_OFFSET_BITS=64 -DHAVE_LIBINTL_H=1 -DGETTEXT_PACKAGE=\"transmission\" -DHAVE_LOCALE_H=1 -DHAVE_LC_MESSAGES=1 -DHAVE_BIND_TEXTDOMAIN_CODESET=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1 -DENABLE_NLS=1 -I.  -I. -I.. -I../third-party/ -D__TRANSMISSION__ -I../third-party/libevent -DPACKAGE_DATA_DIR=\""/opt/transmission1.50b/share"\"  -I/usr/include/curl    -D_REENTRANT -pthreads  -std=gnu99 -ggdb3 -Wall -Wextra -Wredundant-decls -Wpointer-arith -Wformat-security -W -Wmissing-declarations -Wdeclaration-after-statement -Wcast-align -Winline -Winit-self -Wundef -Wnested-externs -Wmissing-format-attribute -g -O3 -funroll-loops -DNDEBUG  -MT platform.o -MD -MP -MF .deps/platform.Tpo -c -o platform.o platform.c
In file included from /usr/include/pthread.h:30,
                 from platform.c:25:
/usr/include/sys/feature_tests.h:353:2: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications         and pre-2001 POSIX applications"
make[2]: *** [platform.o] Error 1

to fix error I've used following command:

Code: Select all

find . -name Makefile | xargs -i sh -c "sed s/-std=gnu99// {} > /tmp/tmp.file; mv -f /tmp/tmp.file {}"
make clean
make

now I had daemon binary.
Result the same: 1 main thread and 1 zombie thread, socket on port 9091 is created according to pfiles

The second thing to try, if 1.50 beta 1 is still broken, is to comment out the #ifdef checks in daemon/daemon.c lines 94-100, and just set "#define USE_TR_DAEMON", rebuild, and let me know if that works.

Tried it. It doesn't help.
I think we do not have any problem with demonizing. It work as it it should. The problem exists in the foreground mode as well.
We have a problem with whatever handles a socket for IPC port 9091, it exits its thread prematurely and main thread just waits a signal for closing.
Here is gdb output:

Code: Select all

bash-3.2# cd transmission-1.50b1/
bash-3.2# gdb ./daemon/transmission-daemon 
GNU gdb 6.3.50_2004-11-23-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.11"...
(gdb) set args -f
(gdb) run
Starting program: /root/transmission-1.50b1/daemon/transmission-daemon -f
warning: Lowest section in /lib/librt.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
warning: Lowest section in /lib/libthread.so.1 is .dynamic at 00000074
[New LWP 1]
[New LWP 2]
Transmission 1.50b1 (7681) started
RPC Server: Adding address to whitelist: 127.0.0.1
RPC Server: Serving RPC and Web requests on port 9091
RPC Server: Whitelist enabled
[LWP 2 exited]
[New LWP 2]
^C
Program received signal SIGINT, Interrupt.
0xfee908d7 in __nanosleep () from /lib/libc.so.1
(gdb) bt
#0  0xfee908d7 in __nanosleep () from /lib/libc.so.1
#1  0xfee7c738 in nanosleep () from /lib/libc.so.1
#2  0xfee7cada in usleep () from /lib/libc.so.1
#3  0x0805e806 in main (argc=134511876, argv=0x8047d68) at daemon.c:275
(gdb) 

[qwerty0987654321]

It would be much easier, for a developer how knows the product, to catch the problem on an alive system,
but for this one needs to setup Solaris11 (x86).
It installs from 1 DVD and uses ~9Gb of disk space. (I installed it in vmware)
If you wish, I could give you detailed instructions how to setup the thing.
it takes about 1-2 hours for a complete install (i.e. ready for building transmission).

PS:
I don't have much time to dig in transmission internals,
but I can useful in helping to test it out on Solaris11. (7+ years expr. in c, c++, gdb and e.t.c.)