Opened 11 years ago

Closed 11 years ago

#3514 closed Bug (worksforme)

transmission-daemon sometimes stops responding 5-10 minutes after startup

Reported by: brgnm Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 2.04
Severity: Normal Keywords:


One rather large transmission-daemon session will, as often as not, become hung during startup. I have seen this since at least 2.0.

After 5-10 minutes, the cpu usage of the daemon will drop to 0, it no longer responds to any request, and must be restarted. On some occasions I have left it in this state for over an hour, with no change. It starts successfully after an indeterminate number of attempts, with no pattern I can discern.

Once started, it runs great. Other instances on the same machine never have this problem, though this one is several times larger than the rest combined.

I avoid restarting the daemon, I post this so I might have some idea how to diagnose it next time.

Change History (6)

comment:1 Changed 11 years ago by charles

  • Summary changed from transmission-daemon sometimes stalls while starting. to transmission-daemon sometimes stops responding 5-10 minutes after startup

comment:2 Changed 11 years ago by charles

brgnm: when transmission-daemon stops responding, are does the daemon allow incoming RPC connections at all, or do you get a "connection refused" error?

One easy way to test this would be to paste the output of something like "transmission-remote --debug -U"

Last edited 11 years ago by charles (previous) (diff)

comment:3 Changed 11 years ago by brgnm

Today I restarted this daemon for the 2nd time since making this report. In fact I had to restart the machine twice today, so I took the opportunity to observe this in more detail on the freshly booted, and unloaded system. I have just now seen your comment, and so, did not try '--debug', but I know transmission-remote and qtr time out in that state.

I did observe a more consistent pattern between these last 2 startups though. Each time, it successfully started on the 3rd trial, with this pattern:

  • first start: moderate cpu usage (20-40%) for 5-10 min, then stuck as described.
  • second start: high cpu usage (100-150%) for a short time, then daemon dies. On the fist boot today, qtr was attatched at this point, when the daemon died, it was displaying a 'total torrents' # that is somewhat less than 1/2 of the actual number, and one torrent was in midst of verification. Second time, no RPC connection was made before daemon died.
  • third start: after some 'normal' minutes, daemon becomes responsive after several minutes of low cpu usage (1-4%). This definitely differs from the 'stuck' state, as I have left it for some time in that state, and there is no cpu or i/o activity at all.

each time, the daemon shows no problem once it has fully started. on an average day this daemon uses 15-35% cpu in normal operation.

I notice no logs are produced until the daemon is 'fully started', and I have avoided making RPC connections when startup is in progress, but let me know if there is possibly some information I could get from transmission-remote next time before the daemon gets 'stuck'. I am not sure if it responds at that point or not. Also I cannot say that the above pattern is consistant, I can only say that it does seem to start after the 3rd try or so. I do not remember the daemon vanishing previously though, as it did on 2nd try each time today.

comment:4 Changed 11 years ago by charles

Is this still happening in Transmission 2.12?

comment:5 Changed 11 years ago by jordan

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

comment:6 Changed 11 years ago by livings124

  • Resolution set to worksforme
  • Status changed from new to closed

There are no reports of this happening with the current daemon. Please reopen if this is still an issue.

Note: See TracTickets for help on using tickets.