Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1619 closed Bug (fixed)

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

Reported by: fkrueger Owned by: charles
Priority: Normal Milestone: 1.50
Component: Daemon Version: 1.40
Severity: Blocker Keywords:
Cc:

Description

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.

Attachments (5)

Change History (25)

Changed 12 years ago by fkrueger

comment:1 Changed 12 years ago by fkrueger

  • Component changed from Transmission to Daemon
  • Owner set to charles

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

comment:2 Changed 12 years ago by livings124

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

comment:3 Changed 12 years ago by jhujhiti

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

comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by 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 ? :)

comment:6 Changed 12 years ago by 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?

comment:7 Changed 12 years ago by charles

  • Milestone changed from None Set to 1.50
  • Status changed from new to assigned

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.

comment:8 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:9 Changed 12 years ago by er13

  • Resolution fixed deleted
  • Status changed from closed to reopened

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)

comment:10 Changed 12 years ago by er13

Seems __MIPSEL__ does the job, i.e.

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

comment:11 follow-up: Changed 12 years ago by charles

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

comment:12 in reply to: ↑ 11 Changed 12 years ago by er13

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to charles:

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

Yes, it does.

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

comment:14 Changed 12 years ago by charles

  • Keywords backport-candidate added

Revised in r7556.

comment:15 Changed 12 years ago by er13

  • Resolution fixed deleted
  • Status changed from closed to reopened

@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)

comment:16 follow-up: Changed 12 years ago by charles

  • Keywords backport-candidate removed
  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:17 Changed 12 years ago by charles

or 0.10.0, even. :)

comment:18 in reply to: ↑ 16 Changed 12 years ago by er13

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:19 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

done.

r7689

r7690

comment:20 Changed 12 years ago by charles

  • Summary changed from tm-daemon: no tcp sockets are being bound on mipsel and no error given either to no tcp sockets are being bound on mipsel; no error message
Note: See TracTickets for help on using tickets.