Deluge Forum

I don't understand why deluged determines that my system will wait until it is ready to reboot instead of when I am ready (i.e., if I need to reboot my computer, that needs to happen yesterday, not after deluge bittorrent client daemon waits for five minutes). It appears that a solution might be:
```
$ cat deluged.service |grep Time
# Time to wait before forcefully stopped.
#TimeoutStopSec=300 #2021.09.26
TimeoutStopSec=30
```
Is that all that needs to be done? There's a lot of other stuff in this thread, but if this is all that needs to be done, great.

You can find the default settings of the systemd unit here https://deluge.readthedocs.io/en/latest ... rvice.html

This settings sets the maximum amount of time the OS wait prior killing the process if a reboot or shutdown is requested. It doesn't take that long most of the time but the process is allowed to take 300sec so. Why? To save the status of the actual torrent, flush memory, etc).
You can reduce the time to 30s at the price of a corruption if it wasn't enough.

shamael wrote: ↑Mon Sep 27, 2021 10:40 am You can reduce the time to 30s at the price of a corruption if it wasn't enough.

This sounds like a red herring to me: If I hit pause on a torrent, it stops transferring immediately, presumably does whatever it needs to do to wrap up/save to disc, update state file, PID, etc., so where does the [seemingly very arbitrary] 5 minutes come in? Why doesn't, upon receiving `systemctl stop deluged`, deluged simply stop/pause all active transfers so they're halted and then terminate immediately thereafter? What takes 5 minutes instead of 5 seconds to preserve data integrity?

There is more about the way a systemd unit is stopped, consider ExecStop, SIGTERM, SIGKILL and the same for process created. In any way here is doesn't mean you will be stuck 5 min on this unit, never happened to me at least. It's a maximum