From: Dave Jones <davej@codemonkey.org.uk>
To: Dai Xiang <xiangx.dai@intel.com>
Cc: trinity@vger.kernel.org
Subject: Re: test processes are not all killed
Date: Tue, 1 Aug 2017 11:38:23 -0400 [thread overview]
Message-ID: <20170801153823.4z6nloqtnwnd3fe7@codemonkey.org.uk> (raw)
In-Reply-To: <20170801093813.nw3zj4nqb2jqpdtx@linux>
On Tue, Aug 01, 2017 at 05:38:13PM +0800, Dai Xiang wrote:
> Hi!
> I use below cmds(with root permission) include trinity to test and find an interesting issue:
>
> cmd="trinity -q -q -l off -s $seed -x get_robust_list -x remap_file_pages -N 999999999"
> cd /tmp
> chroot --userspec nobody:nogroup / $cmd 2>&1 &
> pid=$!
> sleep 300s
> kill -9 $pid
>
> Then after run finish, i use pgrep and find test process do not kill
> while i think the test logic is right:
>
> 5292 trinity -q -q -l off -s 3648957937 -x get_robust_list -x remap_file_pages -N 999999999
> 5293 trinity-watchdo
> 5294 trinity -q -q -l off -s 3648957937 -x get_robust_list -x remap_file_pages -N 999999999
> 70558 trinity -q -q -l off -s 3648957937 -x get_robust_list -x remap_file_pages -N 999999999
>
> I do some simple tests and all processes can be killed.
>
> Does trinity suppress kill or it run at background can not use this
> way to kill?
It doesn't do anything special to mask signals (unless it happened to
call some of the signal syscalls with the right random arguments, which
is unlikely - the sanitize routines for the signal syscalls are pretty
dumb, or missing entirely)
More likely is you've found a kernel bug, or the processes are blocked
on something.
Looking at /proc/<pid>/stack can sometimes give clues as to where a
process is stuck.
Also a script like this is useful for tracing stuck pids
cd /sys/kernel/debug/tracing/
echo $1 >> set_ftrace_pid
echo function_graph >> current_tracer
echo 1 >> tracing_on
sleep 5
echo 0 >> tracing_on
cat /sys/kernel/debug/tracing/trace
Actually looking again, I see you have a trinity-watchdog process, which
current versions don't have, so maybe try updating to 1.7, (or better, the git
version) and seeing if it's reproducable there. I don't even remember
what bugs got fixed that long ago.
Dave
next prev parent reply other threads:[~2017-08-01 15:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-01 9:38 test processes are not all killed Dai Xiang
2017-08-01 15:38 ` Dave Jones [this message]
2017-08-02 3:09 ` Dai Xiang
2017-08-02 12:37 ` Dave Jones
2017-08-03 3:17 ` Dai Xiang
2017-08-03 3:22 ` Dave Jones
2017-08-02 14:57 ` Tommi Rantala
2017-08-02 16:41 ` Dave Jones
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=20170801153823.4z6nloqtnwnd3fe7@codemonkey.org.uk \
--to=davej@codemonkey.org.uk \
--cc=trinity@vger.kernel.org \
--cc=xiangx.dai@intel.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).