|author||Joey Hess||2016-03-06 14:56:45 -0400|
|committer||Joey Hess||2016-03-06 14:56:45 -0400|
Diffstat (limited to 'doc/forum/Weird_SSH_issue/comment_4_2fbb97cb5bca3a0e2835e7667aff7a00._comment')
1 files changed, 22 insertions, 0 deletions
diff --git a/doc/forum/Weird_SSH_issue/comment_4_2fbb97cb5bca3a0e2835e7667aff7a00._comment b/doc/forum/Weird_SSH_issue/comment_4_2fbb97cb5bca3a0e2835e7667aff7a00._comment
new file mode 100644
@@ -0,0 +1,22 @@
+ subject="""comment 4"""
+Added some debugging, I found that processes run by concurrent-output tend to
+alternate between running foreground and background. So, when the socket
+exists and is old, it will run one more process than otherwise to
+stop ssh on that socket, and this will change which run method is
+used for subsequent processes.
+However, it really shouldn't matter if a process starts in the background;
+concurrent-output shoud notice when the output lock frees up, and start
+displaying the processes's output.
+So, this theory explains why the ssh socket seems to be involved, perhaps,
+but it doesn't really explain what's happening to prevent the remote
+propellor output from being shown.
+Unless some other foreground process is hanging around and keeping
+the output lock. Or some bug in concurrent-output..