summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar EskildHustvedt <EskildHustvedt@web>2012-10-16 07:58:45 +0000
committerGravatar admin <admin@branchable.com>2012-10-16 07:58:45 +0000
commitec00cc226d7b0ddf61ed6fe535dec4bdf6eed6c4 (patch)
tree8a7b3e130ab1bc5db31241ccb4e26a1456b7515d
parentf0e66921f89459ab97cca060f044aa821e318af7 (diff)
-rw-r--r--doc/bugs/Assistant_enters_eternal_loop_and_eats_up_all_of_RAM_after_X_restart.mdwn18
1 files changed, 18 insertions, 0 deletions
diff --git a/doc/bugs/Assistant_enters_eternal_loop_and_eats_up_all_of_RAM_after_X_restart.mdwn b/doc/bugs/Assistant_enters_eternal_loop_and_eats_up_all_of_RAM_after_X_restart.mdwn
new file mode 100644
index 000000000..bf364370d
--- /dev/null
+++ b/doc/bugs/Assistant_enters_eternal_loop_and_eats_up_all_of_RAM_after_X_restart.mdwn
@@ -0,0 +1,18 @@
+*What steps will reproduce the problem?*
+
+Log in to X, have the DE start the assistant with --autostart. Then kill X with ctrl+alt+backspace and log back in once X comes back up.
+
+*What is the expected output? What do you see instead?*
+
+It enters an eternal loop, quickly using up all of the available RAM as well as 100% of CPU. Initially noticed because the computer became extremely sluggish, at which point the assistant was using up over 7G (of the available 8G) of RAM, and all of the available power on one of the CPU cores.
+
+Killing the assistant and then starting it again results in it working normally again.
+
+*What version of git-annex are you using? On what operating system?*
+
+git-annex version: 3.20121010 on Debian Sid (under GNOME3/Gnome-Shell in case that's relevant).
+I've also seen it happen on another computer in similar circumstances. That one on Debian Testing, with git-annex from sid (so same git-annex version). In this case X was restarted while running with /etc/init.d/gdm3 restart, and again the issue appeared after logging out and then back in.
+
+*Please provide any additional information below.*
+
+Given that the assistant isn't really using X directly, I suppose this could be due to losing its connection to the gpg and ssh agents as a side-effect of X being shut down. I'm not sure if it happens immediately after X being killed, or once I log back in again.