all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 26911@debbugs.gnu.org, mattiase@acm.org, eggert@cs.ucla.edu,
	yegortimoshenko@gmail.com
Subject: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP
Date: Sat, 05 Sep 2020 14:18:30 +0300	[thread overview]
Message-ID: <83lfhopj3t.fsf@gnu.org> (raw)
In-Reply-To: <87363wr59c.fsf@gmx.de> (message from Michael Albinus on Sat, 05 Sep 2020 10:34:39 +0200)

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: bug-gnu-emacs@gnu.org,  26911@debbugs.gnu.org,  mattiase@acm.org,
>   eggert@cs.ucla.edu,  yegortimoshenko@gmail.com
> Date: Sat, 05 Sep 2020 10:34:39 +0200
> 
> > I'm talking to sysadmins to see how to overcome this problem, but in
> > case I cannot, how do I run the Tramp suite one test at a time? can
> > you show me an example command for that?
> 
> # make tramp-tests SELECTOR='tramp-test05-expand-file-name'

Thanks.  FTR, this translates into the following invocation from the
shell prompt:

  emacs -Q -batch -l test\lisp\net\tramp-tests.elc --eval "(ert-run-tests-batch-and-exit 'TEST-NAME)"

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...

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.

I think this more or less concludes the testing of the fixes in these
two bugs, so I'm going to close them now.

Thanks.





  reply	other threads:[~2020-09-05 11:18 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-13 16:15 bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP Yegor Timoshenko
2017-05-13 18:25 ` Michael Albinus
2017-05-13 18:30   ` Yegor Timoshenko
2017-05-15 15:53     ` Michael Albinus
2020-08-26 20:39 ` Paul Eggert
2020-08-27 11:46   ` Michael Albinus
2020-08-27 18:31 ` Mattias Engdegård
2020-08-27 18:38   ` Eli Zaretskii
2020-08-27 18:54     ` Stephen Berman
2020-08-27 21:53   ` Paul Eggert
2020-08-28  6:39     ` Eli Zaretskii
2020-08-28  7:01       ` Eli Zaretskii
2020-08-28 10:48         ` Eli Zaretskii
2020-08-29  5:52           ` Paul Eggert
2020-08-29  6:31             ` Eli Zaretskii
2020-08-29 16:46               ` Paul Eggert
2020-08-29 16:59                 ` Michael Albinus
2020-08-29 18:29                   ` Eli Zaretskii
2020-08-29 19:12                     ` Michael Albinus
2020-08-29 19:31                       ` Eli Zaretskii
2020-08-30  9:46                         ` Michael Albinus
2020-08-30 14:14                           ` Eli Zaretskii
2020-08-29 18:26                 ` Eli Zaretskii
2020-08-29 20:42                   ` Paul Eggert
2020-08-30 14:09                     ` Eli Zaretskii
2020-08-30 21:39                       ` Paul Eggert
2020-08-31 14:58                         ` Eli Zaretskii
2020-08-31 18:15                           ` Paul Eggert
2020-08-31 18:56                             ` Eli Zaretskii
2020-08-31 23:36                               ` Paul Eggert
2020-09-01  2:33                                 ` Eli Zaretskii
2020-09-03 17:27                           ` Eli Zaretskii
2020-09-03 17:42                             ` Michael Albinus
2020-09-04 11:55                             ` Michael Albinus
2020-09-04 12:25                               ` Eli Zaretskii
2020-09-04 13:53                                 ` Michael Albinus
2020-09-04 14:40                                   ` Eli Zaretskii
2020-09-04 15:20                                     ` Eli Zaretskii
2020-09-04 15:59                                       ` Michael Albinus
2020-09-04 17:42                                         ` Eli Zaretskii
2020-09-05  8:34                                           ` Michael Albinus
2020-09-05 11:18                                             ` Eli Zaretskii [this message]
2020-09-05 11:32                                               ` Eli Zaretskii
2020-09-05 15:57                                               ` Michael Albinus
2020-09-05 16:33                                                 ` Eli Zaretskii
2020-09-05 17:08                                                   ` Eli Zaretskii
2020-09-05 17:36                                                   ` Michael Albinus
2020-09-05 17:56                                                     ` Eli Zaretskii
2020-09-04 16:09                                     ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83lfhopj3t.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=26911@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=mattiase@acm.org \
    --cc=michael.albinus@gmx.de \
    --cc=yegortimoshenko@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.