Can't delete some torrents from rtorrent

[omgiafs]

• Debian stable
• libtorrent19 0.13.6-1+b1 (testing)
• rtorrent 0.9.6-2 (testing)

Unclear situation. I remove the torrent from rtorrent, no matter with wich tool - rtorrent, pyroscope, RuTorrent, emonoda. Torrents are removed. The session directory not contains any files with hashes of these torrents. After a while, these torrents appear again in rtorrent. If restart rtorrent service, they appear again.

Where is stored information about deleted torrents? Why are these DELETED torrents appear again after restarting the service? It can't be connected with watch_directory folders, because they are empty.

Debug log just informs, that torrent added, etc.

[chros73]

That's interesting, I've never seen this on Ubuntu 14.04 with rtorrent-ps 0.9.6. What happens with data of the removed torrents? (stays on the disk or deleted) Are you sure that there is no such script that adds back those from somewhere? (e.g. via xmlrpc) :) If one is added back that was downloaded fully before: is it finished or does rtorrent start downloading it? Can you upload your rtorrent config somewhere?

[omgiafs]

Okay, i'm completely disabled xmlrpc by disabling RPC section in nginx config and changing network.scgi.open_port to different number. Now i'm using only rtorrent, there is no more pyroscope, emonoda, rutorrent. Restart nginx, restart rtorrent. Open rtorrent - torrents are in rtorrent. Deleting them by ^D. Restart rtorrent. Torrents are in rtorrent :)

So i exclude xmlrpc from the list of suspects.

.rtorrent.rc:

log.open_file = "rtorrent", /var/log/rtorrent/rtorrent.log
log.add_output = "info", "rtorrent"

log.open_file = "connection", /var/log/rtorrent/connection.log
log.add_output = "connection_notice", "connection"

log.open_file = "dht", /var/log/rtorrent/dht.log
log.add_output = "dht_notice", "dht"

log.open_file = "peer", /var/log/rtorrent/peer.log
log.add_output = "peer_notice", "peer"

log.open_file = "storage", /var/log/rtorrent/storage.log
log.add_output = "storage_notice", "storage"
log.open_file = "thread", /var/log/rtorrent/thread.log
log.add_output = "thread_notice", "thread"

log.open_file = "tracker", /var/log/rtorrent/tracker.log
log.add_output = "tracker_notice", "tracker"

log.open_file = "torrent", /var/log/rtorrent/torrent.log
log.add_output = "torrent_info", "torrent"

encoding.add = UTF-8
throttle.min_peers.normal.set = 1 
throttle.max_peers.normal.set = 400 
throttle.min_peers.seed.set = 1
throttle.max_peers.seed.set = 50 
throttle.max_uploads.set = 20
throttle.global_down.max_rate.set_kb = 8192 
throttle.global_up.max_rate.set_kb = 8192 
directory.default.set = /data1/torrent/dl/

session.path.set = /var/www/rutorrent/session/
schedule2 = watch_directory_1,5,5,"load.start=/data1/torrent/autodl/*.torrent,d.directory.set=/data1/torrent/dl"
schedule2 = watch_directory_2,5,5,"load.start=/data1/torrent/autodl/books/*.torrent,d.directory.set=/data1/torrent/dl/books"
schedule2 = watch_directory_3,5,5,"load.start=/data1/torrent/autodl/video/docs/*.torrent,d.directory.set=/data1/torrent/dl/video/documental"
schedule2 = watch_directory_4,5,5,"load.start=/data1/torrent/autodl/video/sport/*.torrent,d.directory.set=/data1/torrent/dl/video/sport"
schedule2 = watch_directory_5,5,5,"load.start=/data1/torrent/autodl/video/mult/*.torrent,d.directory.set=/data1/torrent/dl/video/mult"
schedule2 = watch_directory_10,5,5,"load.start=/data1/torrent/autodl/video/serials/*.torrent,d.directory.set=/data1/torrent/dl/video/serial/"
schedule2 = watch_directory_11,5,5,"load.start=/data1/torrent/autodl/video/other/*.torrent,d.directory.set=/data1/torrent/dl/video/other"
schedule2 = watch_directory_6,5,5,"load.start=/data1/torrent/autodl/video/*.torrent,d.directory.set=/data1/torrent/dl/video/movies"
schedule2 = watch_directory_7,5,5,"load.start=/data1/torrent/autodl/games/*.torrent,d.directory.set=/data1/torrent/dl/games"
schedule2 = watch_directory_8,5,5,"load.start=/data1/torrent/autodl/music/*.torrent,d.directory.set=/data1/torrent/dl/music"
schedule2 = watch_directory_9,5,5,"load.start=/data1/torrent/autodl/soft/*.torrent,d.directory.set=/data1/torrent/dl/soft"

schedule2 = low_diskspace,5,60,close_low_diskspace=400M 
network.local_address.set = xxx.xxx.xxx.xxx

network.port_range.set = 6900-6950
network.port_random.set = yes

pieces.hash.on_completion.set = no
dht.mode.set = auto
dht.port.set = 6899
protocol.pex.set = yes
trackers.use_udp.set = yes
protocol.encryption.set = allow_incoming,try_outgoing,enable_retry,prefer_plaintext

network.max_open_files.set = 128 
network.scgi.open_local = /var/run/rtorrent/rpc.socket

method.set_key = event.download.finished,change_permissions,"execute=/home/www/rtorrent/changeperm.sh,$d.base_path="
execute2 = {sh,-c,/usr/bin/php /var/www/rutorrent/rutorrent/php/initplugins.php www &}

/etc/init.s/rtorrent:

#!/bin/bash
### BEGIN INIT INFO
# Provides:          rtorrent
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start/stop rtorrent daemon
### END INIT INFO

# ------------------------------------------------------------------------------
# /etc/init.d/rtorrent
#
# This script is an init script to run rtorrent in the background, using a
# screen. The script was designed and tested for Debian systems, but may work on
# other systems. On Debian, enable it by moving the script to
# "/etc/init.d/rtorrent" and issuing the command
# "update-rc.d rtorrent defaults 99"
#    ____                _ _
#   / ___|  ___  ___  __| | |__   _____  __
#   \___ \ / _ \/ _ \/ _` | '_ \ / _ \ \/ /
#    ___) |  __/  __/ (_| | |_) | (_) >  <
#   |____/ \___|\___|\__,_|_.__/ \___/_/\_\
#
# @see http://methvin.net/scripts/rtorrent
# @see http://tldp.org/LDP/abs/html/
# ------------------------------------------------------------------------------

## Username to run rtorrent under, make sure you have a .rtorrent.rc in the
## home directory of this user!
USER="www"

## Absolute path to the rtorrent binary.
RTORRENT="/usr/bin/rtorrent"

## Absolute path to the screen binary.
SCREEN="/usr/bin/screen"

## Name of the screen session, you can then "screen -r rtorrent" to get it back
## to the forground and work with it on your shell.
SCREEN_NAME="rtorrent"

## Absolute path to rtorrent's PID file.
PIDFILE="/var/run/rtorrent.pid"

## Absolute path to rtorrent's XMLRPC socket.
SOCKET="/var/run/rtorrent/rpc.socket"

## Check if the socket exists and if it exists delete it.
delete_socket() {
    if [[ -e $SOCKET ]]; then
        rm -f $SOCKET
    fi
}

## Check if the pidfile exists and if it exists delete it.
delete_pidfile() {
    if [[ -e $PIDFILE ]]; then
        rm -f $PIDFILE
    fi
}

case "$1" in
    ## Start rtorrent in the background.
    start)
        echo "Starting rtorrent."
    delete_pidfile
        delete_socket
        start-stop-daemon --start --background --oknodo \
            --pidfile "$PIDFILE" --make-pidfile \
            --chuid $USER \
            --exec $SCREEN -- -DmUS $SCREEN_NAME $RTORRENT
        if [[ $? -ne 0 ]]; then
            echo "Error: rtorrent failed to start."
            exit 1
        fi
        echo "rtorrent started successfully."
        ;;

    ## Stop rtorrent.
    stop)
        echo "Stopping rtorrent."
        start-stop-daemon --stop --oknodo --pidfile "$PIDFILE"
        if [[ $? -ne 0 ]]; then
            echo "Error: failed to stop rtorrent process."
            exit 1
        fi
        delete_socket
    delete_pidfile
        echo "rtorrent stopped successfully."
        ;;

    ## Restart rtorrent.
    restart)
        "$0" stop
        sleep 1
        "$0" start || exit 1
        ;;

    ## Print usage information if the user gives an invalid option.
    *)
        echo "Usage: $0 [start|stop|restart]"
        exit 1
        ;;

esac

[chros73]

changing network.scgi.open_port to different number

There's no network.scgi.open_port in the config but network.scgi.open_local.

Deleting them by ^D.

You meant ^d^d, right? :) According to the config, data is still on the disk after it was removed.

What happens if you execute ^x + session.save= command in rtorrent before quitting? (It should do this automatically but who knows.)

The session directory not contains any files with hashes of these torrents.

Are they back after restart? In which state? Are they 100% finished? Are they hash-checking? Check your watch dirs after quitting rtorrent whether the corresponding torrent files are there or not. If they are there then that's the problem.

[omgiafs]

There's no network.scgi.open_port in the config but network.scgi.open_local.

This is because i tried sockets and ports, but nothing changed.

What happens if you execute ^x + session.save= command in rtorrent before quitting? Are they back after restart?

Nothing changed. After restarting of service this torrents are returned with status CLOSED. Session directory NOT contains files with hashes of these torrents in file names after restarting service.

In which state? Are they 100% finished? Are they hash-checking?

"Screenshot" of one of them:

*  Nintendo - Nintendo Entertainment System
* [CLOSED]     0.0 /  274.4 MB Rate:   0.0 /   0.0 KB Uploaded:     0.0 MB
* Inactive:

So thy are closed, inactive, stopped. Some of torrents have more that 2000 files, some have only 10-20 files.

For example, i trying to remove this torrent since February :) :

                     *** Nintendo - Nintendo Entertainment System ***
Name:             Nintendo - Nintendo Entertainment System
Local id:         -lt0D60-%96%3E%D9%83%AD%AC%D6%BD%B7%FFG3
Info hash:        29FF176B61A5248DB61A2495123B09AB37124D88
Created:          11/01/2016  0:52:46

Directory:        /data1/torrent/dl/Nintendo - Nintendo Entertainment Syste
Base Path:
Tied to file:
File stats:       multi 2690 files
Chunks:           0 / 549 * 524288 (549)
Priority:         2
Peer exchange:    enabled active (0/8)
State changed:     0:11:36

Memory usage:         79.0 MB
Max memory usage:   3276.8 MB
Free diskspace:        0.0 MB
Safe diskspace:      591.0 MB

Connection type:  leech
Choke heuristic:  upload_leech, download_leech, 0
Safe sync:        no
Send buffer:        0.0 KB
Receive buffer:     0.0 KB
Throttle:         global

Upload:             0.0 KB /   0.0 KB
Download:           0.0 KB /   0.0 KB
Skipped:            0.0 KB /   0.0 KB
Preload:          0 / 0 / 0

[CLOSED]     0.0 /  274.4 MB Rate:   0.0 /   0.0 KB Uploaded:     0.0 MB
Peers: 0(0) Min/Max: 1/400 Slots: U:0/20 D:0/50 U/I/C/A: 17/17/0/0 Unchoked: 0/0 Failed
[ :0] Inactive:

Check your watch dirs after quitting rtorrent whether the corresponding torrent files are there or not. If they are there then that's the problem.

I'm already deleted all files from watch dirs, so they are empty.

Nice bug ,huh?

[chros73]

Interesting :) Give a try with rtorrent-ps : compile it from source (it's easy, max 10 minutes), then try it out with the same config, let's see if the problem remains.

[omgiafs]

Give a try with rtorrent-ps

Ok, i installed rtorrent-ps. Tried it with the my original config. Connected to rtorrent-ps screen, deleted problem torrents, ^x +session.save= , rtorrent-ps closed. Restarted rtorrent-ps. My deleted torrents are still in rtorrent-ps :)

Later i'll try to change some dirs in config, one by one (session dir, another dirs) to detect dir, from which rtorrent reading information about these torrents.

P.S. Sorry for my bad English. English tenses - my Achilles' heel.

[omgiafs]

Oh, now i know why rtorrent couldn't delete those torrents. It's because rtorrent thinks that torrent info hash is 29FF176B61A5248DB61A2495123B09AB37124D88, but in session dir this torrent sored as BADE9B518284DFAA4BBF25477927DB1781B3E0F4.torrent! Damn thing!

I think it's somehow linked with fact of updating torrents at forums, from where they are been downloaded and have been updated automatically through RuTorrent.

This is focking weird bug, pardon my Klatchian. Problem solved.

[chros73]

Cool, and don't forget to close this issue.

[omgiafs]

Problem solved, but there is a strange bug: When torrent updated (info hash changed from %1 to %2), rtorrent don't change torrent file name in session dir, so now torrent with info hash %2 stored in session dir as %1.torrent. But when you trying to delete updated torrent (with info hash %2) from rtorrent, rtorrent trying to search %2.torrent file in session dir, but there is no file with such name. As result, torrent will not be deleted from rtorrent and after restarting rtorrent this updated torrent appears again in rtorrent (added automatically by reading all .torrent files in session dir).

[chros73]

When torrent updated (info hash changed from %1 to %2)

How can this happen?

[omgiafs]

How can this happen?

I don't know how, but it's a fact. RuTorrent have plugin Rutracker_check (sorry, only Russian language), that can check for torrent updates, maybe it was a bug in plugin. Maybe it was when migrated from version 0.9.4 (from source) to 0.9.6 (from Debian testing package). Just don't know.

I must add, that there are other torrents which been updated, but without bugs like this.

[chros73]

torrents which been updated

I don't know what this means (I never used ruTorrent and any of their plugins).

But changing the hash of a torrent? I don't think that it should ever happen. If a hash is changed that means it became a completely new/different torrent and that plugin shouldn't hack on purpose/by-mistake an existing torrent. You should contact the author(s) and let them know about this bug.

[omgiafs]

How plugin works (google translate):

An attempt is made to download the torrent. With luck (tracker issued 200 and gave the OK torrent) torrent hash is compared to the existing. If they are the same - all right, no additional action is required. If not - Plugin makes an attempt to replace the current distribution (=torrent) by the new.

So, plugin must replace torrent. I think the source of bug is not this plugin.

I had situation, when torrent with info hash AAAA was stored in session dir as BBBB.torrrent instead of AAAA.torrrent, because torrent was updated to info hash BBBB in forum topic, from where torrent was downloaded first time with info hash AAAA.

[chros73]

I get it now, thanks. But I still think that instead of changing this crucial attribute of a torrent it would be way better to delete the old one and adding a new one. Or not to even add one until it's confirmed as OK ? :)

[omgiafs]

But I still think that instead of changing this crucial attribute of a torrent it would be way better to delete the old one and adding a new one

Plugin Rutracker_check makes exactly this thing. Deleting the old one and adding a new one. In any case, for this moment :)

[chros73]

Errr.... So does it try to delete the old one first, then add the new one back? Because it's not updating :) And while it does this does rtorrent mix up somehow the old and new hashes?

Edit: but the latter can't happen either since it's a completely new hash. Anyway, try to talk to the authors.

[omgiafs]

I don't know how it was. For now all works fine and torrents updates(okay, replaces) correctly.

I remind you, i started this issue because I could not understand how these torrents appear in rtorrent.