no tcp sockets are being bound on mipsel; no error message

[fkrueger]

In the environment of a linux 2.6.13 ( see ​http://www.freetz.org/ ) that needs mipsel-4kc as the processor the 1.40 version of transmission won't bind any ports.

I'm going to attach an strace and an lsof log when this happens.

Reproducible: Everytime, just start transmission-daemon.

[fkrueger]

Trac is a piece of s... ok, just my personal opinion. When a link has "filename.log" in it I want the fine .log file in original format, not a html-ized output. Could be just me though.

And why can't you just delete accidental attachments in your own tickets? What's the point in there? Annoy users? Trac got me there :)

In either case, the latter two attachments are the correct ones, the first one is the html-ized version I tried to delete, but couldn't ;)

Frederic

[livings124]

Trac has their own trac - report those issues there, not here.

[jhujhiti]

Please run the strace with daemon option -f to prevent it from daemonizing.

[fkrueger]

livings124, ye ye, I know. Sorry, I just had to vent a little at the time :)

jhujhiti, when you add the -f it suddenly starts binding both ports, the rcpport and the peerport.

Is there any reason for this behaviour other than "Let's save resources so other apps can block our ports" ? ;)

In either case, an attachment of the working strace with exactly the same options as before and the additional -f, i.e. transmission-daemon -f -u transmission -v freetz -p 9091 -g /var/media/ftp/uStor01/bittorrent has been added.

[fkrueger]

Thinking of which, I kinda wonder how you can get started with the transmission-daemon application (using transmission-remote), when the server doesn't bind a port when it doesn't have something to do.

Can anyone chime in here? Or is this the case of a well hidden RTFM ? :)

[charles]

It's probably a case of our implemention of ​daemon() not working correctly on mipsel for some reason.

Could you check and see

• does it *repeatedly* work correctly when you run with -f ?
• is HAVE_DAEMON is defined when building Transmission?
• are any of those "Error daemonizing" messages displayed?

[charles]

I think this was a bug in our fallback daemon() function, and think that it's been fixed in r7503. WorksForMe? now, at least.

Please try an svn build and see how it goes. Feel free to reopen this ticket if r7503 or higher still fail to work on mipsel.

[er13]

Tested [7503], no changes in the behavior when started without -f.

Regarding your questions:

• it does repeatedly work as expected when started with -f.
• HAVE_DAEMON is defined while building, so it seems your implementation is not used at all. The daemon-function-declaration used is contained in toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc/include/unistd.h. No clue where the definition comes from.
• No message at all is displayed.

Written one make call later... behold, it works when I force the usage of your implementation. So the solution seems to be something like this (within the implementation of tr_daemon-function)

#if defined(HAVE_DAEMON) && !defined(WIN32) && !defined(SOME_SYMBOL_DEFINED_ON_MIPSEL_ONLY)

[er13]

Seems __MIPSEL__ does the job, i.e.

#if defined(HAVE_DAEMON) && !defined(WIN32) && !defined(__MIPSEL__)

[charles]

er13: thanks for the quick feedback, and the MIPSEL suggestion. Does r7507 work for you?

[er13]

Replying to charles:

er13: thanks for the quick feedback, and the MIPSEL suggestion. Does r7507 work for you?

Yes, it does.

[charles]

From IRC:

00:07 -!- Whoopie [i=Whoopie@unaffiliated/whoopie] has joined #transmission
00:08 < Whoopie> charles_: Hi, regarding bug 1619, it's a known problem with uclibc 0.9.29 and 
                 pthreads, so the problem is not with the mipsel platform, but with uclibc. Perhaps, 
                 it's better to replace __MIPSEL__ with __UCLIBC__
00:10 < Whoopie> charles_: asterisk has the same problem, see 
https://dev.openwrt.org/browser/packages/net/asterisk-1.4.x/patches/035-main-asterisk-uclibc-daemon.patch?rev=13712

[charles]

Revised in r7556.

[er13]

@Charles: I've been pointed out (by Whoopie) that this issue hat nothing to do with the mipsel platform itself but with the uClibc library usually used on it. As one could take out of this ​thread and this ​patch the bug exists first since version 0.9.29. It is known to the uClibc developers but has not been fixed yet (unfortunately I could not provide the corresponding bug-id since the uClibc developers are switching to another bug tracking system right now and the new one doesn't contain old bugs yet). Until it is fixed the correct transmission-fix seems to be provided by the following expression (patch attached)

(defined(__UCLIBC__) && __UCLIBC_MAJOR__ == 0 && __UCLIBC_MINOR__ == 9 && __UCLIBC_SUBLEVEL__ >= 29)

[charles]

I don't like this patch -- If the bug still exists in uClibc versions 0.30.0 or 1.0.0, Transmission will re-break.

[charles]

or 0.10.0, even. :)

[er13]

Replying to charles:

I don't like this patch -- If the bug still exists in uClibc versions 0.30.0 or 1.0.0, Transmission will re-break.

ok, but could you at least remove defined(__MIPSEL__), since it turned out to be a uClibc issue and not a mipsel one.

[charles]

done.

r7689

r7690