Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> First, I think I know the reason for the problem I had yesterday to
> run all the tests.  There's some problem in the Tramp tests that
> causes almost each test that was run to leave 3 processes on the
> remote system: 2 sshd's and 1 /bin/sh.  AFAICT, these are created by
> the first connection made by each test.  Most tests create additional
> connections, but their processes are all killed or exit when the test
> completes, whereas this one connection is left behind.  And some test
> leave behind more than one such triplet.  So after running enough
> tests, the system is full of these triplets of zombie processes, and
> on a resource-challenged system that could cause additional
> connections to fail due to lack of resources to start another process.
>
> Is it possible to make sure these processes are killed as part of each
> test's cleanup?  For now, I ran the tests one by one, each time
> killing the zombie processes manually on the remote system.  It took
> some time...

Most of the tests start with (skip-unless (tramp--test-enabled)). This
defun calls tramp-cleanup-connection, which shall also kill all related
Tramp processes. Doesn't seem to work on MS Windows.

Hard to debug for me w/o such a machine. Could you write a bug report as
a reminder for me, that I investigate when I have such a machine?

> Anyway, doing this cleanup manually allowed me to run all the tests
> (skipping those which I knew to be "unstable"), and all but one of
> them succeeded.  The one which failed is shown below together with the
> failure description:
>
>   Test tramp-test30-make-process condition:
>       (ert-test-failed
>        ((should
> 	 (string-match
> 	  (if ... "unknown signal
>   \\'" "killed.*
>   \\'")
> 	  (buffer-string)))
> 	:form
> 	(string-match "unknown signal
>   \\'" "killed
>   ")
> 	:value nil))
>      FAILED  1/1  tramp-test30-make-process (39.250000 sec)
>
> Just to be sure, I've ran this test twice, and each time it failed
> with the same error.

Hahh! There is a special case in that test for MS-Windows:

--8<---------------cut here---------------start------------->8---
(should
 (string-match
  (if (eq system-type 'windows-nt)
      "unknown signal\n\\'" "killed.*\n\\'")
  (buffer-string))))
--8<---------------cut here---------------end--------------->8---

IIRC, somebody has reported this different return message. Or maybe I
have seen this on the MS Windows machine I've used for testing.

Maybe we shall simply allow both messages, because the exact wording
doesn't matter. What about the appended patch?

> Thanks.

Best regards, Michael.