client unable to connect to headless server after upgrade

[compul]

Hi,

since one of the last upgrades (didn't pay attention to which release it was at the time, sadly), my deluge frontend is no longer able to connect to the daemon. The daeomon is running on debian wheezy, i.e. deluge 1.3.3, the frontend on jessie, i.e. 1.3.10. I see the packets arriving at the server, but they are never being answered. The same goes for trying to remotely connect through deluge-console. (yes remote connections are allowed in the config).

Is this a bug that is likely to be fixed, or should I just wait until wheezy gets a newer version, and until then grudgingly use the webinterface?

[Cas]

Any logs?

[compul]

Any logs?

/var/log/deluged.conf and ~/.config/deluge/deluged.log are empty on the server, and don't exist on the client desktop. Maybe I'd need to start with certain options? currently the deluge-daemon init script I use uses:

Code: Select all

daemon1_args="-d -p 9093 -c /var/lib/deluge -l /var/log/deluged.log -l warning"

Note that this worked on both my laptop and desktop before. Then at some point, presumably after an upgrade, it stopped working on my laptop. A little later I upgraded my desktop, it also stopped working there. Thus I suspect the problem lies with the upgrade / newer versions.

## EDIT ##

so here are some interesting logs I could produce:

client:

Code: Select all

deluge -L info
[INFO    ] 18:06:23 main:125 Deluge ui 1.3.10
[INFO    ] 18:06:23 main:131 Starting ui..
[INFO    ] 18:06:23 ui:148 Starting GtkUI..
[WARNING ] 18:06:26 gtkui:202 Unable to register a 'die' handler with the GNOME session manager: No module named gnome.ui
/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/listview.py:250: GtkWarning: gtk_tree_model_sort_set_sort_column_id: assertion 'header != NULL' failed
  self.treeview.get_model().set_sort_column_id(column_state.sort, column_state.sort_order)
[INFO    ] 18:06:27 client:217 Connecting to daemon at <URL>:9093..
[INFO    ] 18:06:27 client:121 Connected to daemon at <IP>:9093..
[INFO    ] 18:06:27 client:224 Connection lost to daemon at <URL>:9093 reason: Connection was closed cleanly.
[INFO    ] 18:06:27 client:217 Connecting to daemon at <URL>:9093..
[INFO    ] 18:06:27 client:121 Connected to daemon at <IP>:9093..
[INFO    ] 18:06:27 client:224 Connection lost to daemon at <URL>:9093 reason: Connection was closed cleanly.

server:

Code: Select all

[INFO    ] 18:03:53 daemon:129 Deluge daemon 1.3.3
[INFO    ] 18:03:53 configmanager:70 Setting config directory to: /var/lib/deluge
[INFO    ] 18:03:53 core:80 Starting libtorrent 0.15.10.0 session..
[INFO    ] 18:03:53 rpcserver:366 Starting DelugeRPC server :9093
[...]
[INFO    ] 18:04:34 rpcserver:203 Deluge Client connection made from: <IP>:52378
[INFO    ] 18:04:34 rpcserver:223 Deluge client disconnected: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]
[INFO    ] 18:04:55 rpcserver:203 Deluge Client connection made from: <IP>:52379
[INFO    ] 18:04:55 rpcserver:223 Deluge client disconnected: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]

What would cause the ssl handshake to fail?

## EDIT 2 ##
found this: http://dev.deluge-torrent.org/ticket/2555#no1

## EDIT 3 ##
According to: http://forum.deluge-torrent.org/viewtop ... =7&t=48797 , http://metadata.ftp-master.debian.org/c ... _changelog ,this does indeed seem to be an incompatibility issue between debian stable and testing versions.

[Cas]

http://dev.deluge-torrent.org/wiki/Inst ... ian/Wheezy