Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#598 closed bug (Fixed)

deluged does not stop or kill

Reported by: anonymous Owned by: andar
Priority: major Milestone:
Component: Core Version: 1.0.5
Keywords: deluged daemon kill Cc: ijanos@…

Description

Description: Deluge daemon does not respond to kill command.

Additional info: deluge 1.0.5 and Arch Linux

Steps to reproduce:

  1. Run deluge in daemon mode (classic mode is off under preferences). Start using 'deluged'.
  2. Have about 4 torrents in the queue. 2 torrents actively downloading.
  3. Let the daemon run until the torrents begin downloading.
  4. Run 'killall deluged'.( Even tried 'sudo killall deluged')
  5. deluged won't stop or kill and download continues

[Over time I have noticed mutliple deluged process by running 'top' command, hogging CPU and network]

Attachments (1)

deluged.log (13.0 KB) - added by hellknight.ludo@… 13 years ago.
deluged.log

Download all attachments as: .zip

Change History (12)

comment:1 Changed 13 years ago by arvid@…

Does anything show up in the log, suggesting that it received the kill signal?

comment:2 Changed 13 years ago by andar

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

Yes, please check the deluged.log.. But I can confirm that it works for me and that deluged is catching the TERM signal properly.

Changed 13 years ago by hellknight.ludo@…

deluged.log

comment:3 Changed 13 years ago by hellknight.ludo@…

  • Component changed from other to core
  • Keywords deluged daemon kill added
  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 1.0.4 to 1.0.5

The log file doesn't show anything, neither does the output from running deluged in foreground (although both have a warning). As you can see, the log stops at "Shutting down component Core..", but it stops there and doesn't shutdown the daemon. I do wait a while (10 min max) but the daemon still appears on top or system monitor. The only way to shut it down is to send a KILL signal. There's no problem with the TERM signal, because it catches it.

This bug started after I upgraded python to version 2.6 and also occurs in classic mode.

comment:4 Changed 13 years ago by ijanos@…

  • Cc ijanos@… added

Same here, deluged can only be killed with kill -9 After "Quit & Shutdown daemon" the deluged stucks in, and not responds. ArchLinux?, deluge 1.0.5

comment:5 Changed 13 years ago by Keerthi

I'm the Person who opened the bug report in ArchLinux?. See http://bugs.archlinux.org/task/11984 I found a FIX.


In component.py, changed the shutdown function from

    def shutdown(self):
        """Shuts down all components.  This should be called when the program
        exits so that components can do any necessary clean-up."""
        # Stop all components first
        self.stop()
        for component in self.components.keys():
            log.debug("Shutting down component %s..", component)
            try:
                self.components[component].shutdown()
            except Exception, e:
                log.debug("Unable to call shutdown(): %s", e)

to

                
    def shutdown(self):
        """Shuts down all components.  This should be called when the program
        exits so that components can do any necessary clean-up."""
        # Stop all components first
        self.stop()
        for component in self.components.keys():
            log.debug("Shutting down component %s..", component)
            try:
                if self.components[component].get_state() != COMPONENT_STATE.index("Stopped"):
                    self.components[component].shutdown()
            except Exception, e:
                log.debug("Unable to call shutdown(): %s", e)

That fixed the issue.

The fix is to shutdown a component only if is NOT already Stopped.

comment:6 Changed 13 years ago by andar

This is not a valid fix. See #377 for comments.

A component should be stopped prior to being shutdown.

Since this issue only occurs on Arch, I would suspect it has something to do with the boost libraries that is causing the libtorrent session deconsutructor to hang. It would be handy to have a full thread backtrace to see what is hanging at the time of shutdown.

comment:7 follow-up: Changed 13 years ago by arvid@…

So, logging should be added so that this can be confirmed to be the case.

The reason why this change fixed the issue for Keerthi is because the session destructor is not called at all? (is that even possible?)

comment:8 in reply to: ↑ 7 Changed 13 years ago by andar

Replying to arvid@cs.umu.se:

So, logging should be added so that this can be confirmed to be the case.

The reason why this change fixed the issue for Keerthi is because the session destructor is not called at all? (is that even possible?)

You're right, this may not be an issue with the libtorrent session, and it is suspicious why this change to component would fix the issue. The last line in the log posted shows that it is shutting down Core, which means that it's calling Core's shutdown() method. Since Core does not implement a shutdown() method it is inherited from Component and it is simply a pass.

I would be curious if you added a log.debug() just after component.shutdown() is called around line 339 of core.py just to show that indeed component.shutdown() has completed and is not hung. Perhaps adding another log print just after 'del self.session' line 345 would be good to.

comment:9 Changed 13 years ago by andar

  • Milestone changed from 1.0.6 to 1.0.7
  • Resolution set to fixed
  • Status changed from reopened to closed

Ok, I have found the issue. It has to do with Python 2.6's SocketServer?.BaseServer? which now implements a shutdown() method that waits on a thread.

This has been fixed in [4337]

Unfortunately this was not fixed in time for 1.0.6, but you can manually patch it in your PKGBUILD.

comment:10 Changed 13 years ago by Keerthi

Thanks for the 'official' fix.

comment:11 Changed 13 years ago by anonymous

  • Milestone 1.0.7 deleted

Milestone 1.0.7 deleted

Note: See TracTickets for help on using tickets.