From: Dave Jones <davej@redhat.com>
To: "Toralf Förster" <toralf.foerster@gmx.de>
Cc: trinity@vger.kernel.org
Subject: Re: trinity seems not to reap all childs
Date: Wed, 13 Aug 2014 11:02:31 -0400 [thread overview]
Message-ID: <20140813150231.GA11344@redhat.com> (raw)
In-Reply-To: <53E64DE1.1020905@gmx.de>
On Sat, Aug 09, 2014 at 06:35:45PM +0200, Toralf Förster wrote:
> I do observe in the last few days that under a 32 bit Gentoo UML guest sometimes 1 trinity job survives although all of its parents are gone already.
>
>
> The console output at th ehost system is :
>
> [main] Bailing main loop because Completed maximum number of operations..
> [watchdog] [2604] Watchdog exiting because Completed maximum number of operations..
> [init] Ran 100001 syscalls. Successes: 21199 Failures: 78802
>
>
> A ps shows that there's still 1 job running in the guest :
>
> $ ssh tfoerste@trinity "ps fx -eo pid,start_time,command | grep -e trinity -e sleep | grep -v grep"
> 2723 17:55 trinity -C 2 -N 100000 -x mremap -q -V /mnt/ramdisk/victims/v1/v2
If it happens again, grab the output of /proc/2723/stack
(You might need something that enables CONFIG_STACKTRACE in your kernel,
or apply the patch below if nothing does -- I still need to get that
upstream)
> [watchdog] 30087 iterations. [F:23623 S:6463 HI:9706]
> [watchdog] 40138 iterations. [F:31443 S:8694 HI:9706]
> [watchdog] 50215 iterations. [F:39370 S:10844 HI:9706]
> [watchdog] 60221 iterations. [F:47228 S:12992 HI:9706]
> [watchdog] 70225 iterations. [F:55100 S:15124 HI:9706]
> [watchdog] 80278 iterations. [F:63007 S:17270 HI:9706]
> [watchdog] 90287 iterations. [F:71013 S:19273 HI:9706]
> [main] Bailing main loop because Completed maximum number of operations..
> [watchdog] [2604] Watchdog exiting because Completed maximum number of operations..
> [init] Ran 100001 syscalls. Successes: 21199 Failures: 78802
>
> killing the job helped fortunately:
>
>
> $ ssh tfoerste@trinity kill 2723
Puzzling that the watchdog exited while there were still children around.
Something else that might be interesting would be to attach to the
still running pid, and examine shm->running_childs
Dave
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index cb45f59685e6..38133ddb8bb4 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1008,8 +1008,13 @@ config TRACE_IRQFLAGS
either tracing or lock debugging.
config STACKTRACE
- bool
+ bool "Stack backtrace support"
depends on STACKTRACE_SUPPORT
+ help
+ This option causes the kernel to create a /proc/pid/stack for
+ every process, showing its current stack trace.
+ It is also used by various kernel debugging features that require
+ stack trace generation.
config DEBUG_KOBJECT
bool "kobject debugging"
prev parent reply other threads:[~2014-08-13 15:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-09 16:35 trinity seems not to reap all childs Toralf Förster
2014-08-13 15:02 ` Dave Jones [this message]
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=20140813150231.GA11344@redhat.com \
--to=davej@redhat.com \
--cc=toralf.foerster@gmx.de \
--cc=trinity@vger.kernel.org \
/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).