Opened 13 years ago

Closed 13 years ago

Last modified 11 years ago

#109 closed bug (Fixed)

gtk client over ssh crashes core

Reported by: deluge-trac@… Owned by: andar
Priority: major Milestone:
Component: GTK UI Version: 0.9.03 (1.0.0_RC3)
Keywords: Cc:

Description

Hi,

thanks for the awesome rework of deluge and the split into core and UI. This is very useful for me, I run deluge on a headless machine. I have found a way to reliably crash deluged (my version is the nightly 2988 on gutsy). Below, I will detail all steps. I assume that some of them are not necessary to reproduce the problem (I assume screen is an example)

1) deluge runs on my headless machine rie. I log in via "ssh -X rie" to enable X forwarding. 2) I run a screen session 3) I start deluged in a window of screen 4) "deluge -u web" 5) "deluge -u gtk" 6) browse the gtk UI. Quit (not close, but quit without shutting down core) deluge. 7) Ctrl+A Ctrl+D to leave screen, ready for reattachment 8) Ctrl+D to log out of ssh session.

I am then not returned to the local console, something is hanging (I assume it has to do with some leftover from the X forward from the gtk ui). deluged then crashes.

Regards

Rolf

Change History (19)

comment:1 Changed 13 years ago by anonymous

well, I always forget about the particular trac formatting. Here are the steps in more readable form.

 1) deluge runs on my headless machine rie.  I log in via "ssh -X rie" to
    enable X forwarding.
 2) I run a screen session
 3) I start deluged in a window of screen
 4) "deluge -u web"
 5) "deluge -u gtk"
 6) browse the gtk UI.  Quit (not close, but quit without shutting down
    core) deluge.
 7) Ctrl+A Ctrl+D to leave screen, ready for reattachment
 8) Ctrl+D to log out of ssh session.

comment:2 Changed 13 years ago by andar

I am not really sure why this is being caused, but the usage of forwarding gtkui over SSH is not really something that would happen often. The idea is that you would run gtkui on your desktop machine and connect to the daemon remotely instead of trying to run the gtkui off the headless machine remotely.

comment:3 Changed 13 years ago by anonymous

I am now running into this problem without forwarding/starting the gtkui. I do have "ssh -X" to forward X over ssh which seems to be sufficient to trigger this problem. Here are the last few lines from the console (same lines are in the log file)

[DEBUG ] torrentmanager:522 on_alert_tracker_reply The application 'deluged' lost its connection to the display localhost:10.0; most likely the X server was shut down or you killed/destroyed the application.

My guess is this is not a gtkui issue after all.

comment:4 Changed 13 years ago by anonymous

and formatting again ;-)

[DEBUG   ] torrentmanager:522 on_alert_tracker_reply
The application 'deluged' lost its connection to the display localhost:10.0;
most likely the X server was shut down or you killed/destroyed
the application.

/me tries to remember to use the preview button more often

comment:5 Changed 13 years ago by durand1@…

same problem here. Just use a deluge gtk client to access the daemon

comment:6 Changed 13 years ago by andar

I can reproduce this with deluge, but I can also reproduce it with gedit.. Could it be a misconfiguration in sshd?

comment:7 Changed 13 years ago by deluge-trac@…

You run gedit remotely and when you close the ssh session deluged dies?

The main problem is not that ssh does not return to the console but that deluged crashes.

comment:8 Changed 13 years ago by andar

deluged does not die.

comment:9 Changed 13 years ago by anonymous

It does for me

comment:10 Changed 13 years ago by andar

Are you using a recent revision? One after I changed deluged to be a true daemon?

comment:11 Changed 13 years ago by anonymous

  • Resolution set to fixed
  • Status changed from new to closed

I was up to the latest nightly from ibiblio which still had this problem. It seems that svn3280 from Launchpad does not have this problem anymore.

Thank you for the great work!

comment:12 Changed 13 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

It is back to crashing. I don't even need to start the gtk ui on the remote machine. I am not yet 100% sure what triggers it, but when closing the ssh connection, I am not returned to the local prompt. When I eventually have to forcefully close the hung ssh connection the deluged process on the remote machine crashes.

reopening.

comment:13 Changed 13 years ago by joose@…

Well, at least i can't reproduce this. Are you running deluged with -d (--do-no-daemonize) ? If yes, why not trying to run it without screen as a daemon.

comment:14 Changed 13 years ago by anonymous

This is plain deluged, running as a daemon. I don't believe the screen step is necessary but I mentioned it here because those are the steps I took. deluged crashed again yesterday (I usually already know when that happens, the ssh connection will not return to the local bash. deluged left the following on the remote console, maybe that gives some kind of clue.

deluged: Fatal IO error 11 (Resource temporarily unavailable) on X server localhost:10.0.

BTW, I probably should have opened a new report. These recent crashes don't involve the gtk ui being forwarded over ssh. deluged runs on the headless machine, the gtk ui connects straight from my laptop (or sometimes with the connection between the two forwarded over ssh)

comment:15 Changed 13 years ago by andar

  • Milestone set to 1.0.0
  • Resolution set to worksforme
  • Status changed from reopened to closed
  • Version changed from 0.6.0svn to 0.9.02 (1.0.0_RC2)

comment:16 Changed 13 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to reopened

reopening because I still frequently see this. I'll try the RC packages and see how that works out.

comment:17 Changed 13 years ago by andar

  • Resolution set to fixed
  • Status changed from reopened to closed
  • Version changed from 0.9.02 (1.0.0_RC2) to 0.9.03 (1.0.0_RC3)

This should be fixed in [3598]

comment:19 Changed 12 years ago by anonymous

  • Milestone 1.0.0 deleted

Milestone 1.0.0 deleted

Note: See TracTickets for help on using tickets.