Listen to WM_ENDSESSION on Windows

[joeyvh]

Right now, on Windows, when a torrent is downloading and Windows' session ends (Either via shutdown or log off) Deluge is forcedly shutdown and the torrent goes into error state. It needs to force recheck the next time Deluge is started.

Suggest listening to the WM_ENDSESSION message so that Deluge can gracefully exit and not push incomplete torrents into error state.

[Calum]

Could you enable debug logging and look for ctrl_type: entry as it might be missing an event.

[joeyvh]

Attached deluge.log

Test case: Set log level to "Debug". I had already added a torrent to test. After opening and leaving open for a while, I shut down the PC with deluge still running.

There seems to be no mention of "ctrl_type" at all anywhere in the log file.

[Calum]

Hmm ok, thanks. I shall have to look into how to implement WM_ENDSESSION in Python.

You could see if using deluge-debug.exe or switching to Thinclient mode works in the meantime.

[joeyvh]

Alright, thank you. For now I'll simply be extra careful to quit deluge before shutting down the PC when a download is running.

If I can do anything to help test / debug, please let me know.

[Calum]

Collated information for ongoing dev...

​https://github.com/deluge-torrent/deluge/pull/155

• ​Application shutdown documentation
• ​WM_QUERYENDSESSION
• ​WM_ENDSESSION
• ​ShutdownBlockReasonCreate
• ​SO - Process WM_ENDSESSION, WM_QUERYENDSESSION
• ​SO - simulate Windows shutdown for debugging
• ​Blog post about end-session messages

Code to test pid handling messages:

from win32con import WM_QUERYENDSESSION
from win32gui import EnumWindows, GetClassName, IsWindowEnabled, IsWindowVisible
from win32process import GetWindowThreadProcessId

def get_hwnds_for_pid(pid):
    def enumwins_cb(hwnd, hwnds):
        if IsWindowVisible(hwnd) and IsWindowEnabled(hwnd):
            # print(GetClassName(hwnd), GetWindowThreadProcessId(hwnd)[1])
            if pid == GetWindowThreadProcessId(hwnd)[1]:
                hwnds.append(hwnd)
        return True

    hwnds = []
    EnumWindows(enumwins_cb, hwnds)
    return hwnds
    
def shutdown_pid(pid):
    win32api.PostMessage(get_hwnds_for_pid(pid)[0], WM_QUERYENDSESSION)

[Calum]

Ticket retargeted after milestone closed

[DjLegolas]

As I wrote in the ​pull request, I wrote a handler for this in ​my fork.

On WM_QUERYENDSESSION message, Deluge will register itself as a Shutdown-Blocker. Next, when receiving WM_ENDSESSION message, Deluge should have 30 seconds to save all the data - depending on whether critical shutdown or not.

But the lack of a proper tool for testing this makes me feel like the is something wrong with my work.

[Calum]

Have you done any testing of your proposed changes? It's been a while since I touched this code so can't remember exactly where I was but testing was a challenge. I only use Windows on virtualbox VMs which makes it a bit easier for actual OS restarts.

I think it is possible to block shutdown entirely if Deluge doesn't return True at some point.

Also you only really need to do this shutdown blocking in classic/standalone mode and there is a section of unneeded duplicate code from what I can see. In thinclient mode the daemon would get it own shutdown message from the OS and deal with it as it does currently.

[DjLegolas]

Ok, took some time but I finally tested it in a VM, and it halts the shutdown.
But, still need to test this in some real-world env, as I only tested it while creating a torrent to simulate a long operation when the signals are being sent to Deluge by windows.

In addition, It seem as when in thinclient, the daemon does not handles the message at all.
This update can be found in ​this commit.

Notes:

• I removed WM_ENDSESSION handler.
• I removed the duplicate code of the method quit_gtkui.
  • quit_gtkui is now a static method - MainWindow._quit_gtkui(shutdown).
• The new API's ShutdownBlockReasonDestroy function is now being called when the gtkui is shuting down.
• Most important: while testing, I noticed that after 1 minute, Windows shutdown is be cancelled - but Deluge will continue with it's shutdown and eventually close. Therefor, I can use some statistics regarding the amount of time it usually takes to close deluge.