deluged does not stop or kill

[anonymous]

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]

[arvid@…]

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

[andar]

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

[hellknight.ludo@…]

deluged.log

[hellknight.ludo@…]

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.

[ijanos@…]

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

[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.

[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.

[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?)

[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.

[andar]

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.

[Keerthi]

Thanks for the 'official' fix.

[anonymous]

Milestone 1.0.7 deleted