On Fri, Apr 13, 2007 at 05:17:27PM +0100, Alan Cox wrote:
> > > Here's a patch. It just doesn't do any formatting for the pipe case.
>
> I don't see a reaosn for removing the formatting features. There are ways
> that can usefully be used, although not many. It's also messier than the
> patch I
> > Here's a patch. It just doesn't do any formatting for the pipe case.
I don't see a reaosn for removing the formatting features. There are ways
that can usefully be used, although not many. It's also messier than the
patch I posted while less functional IMHO.
Alan
-
To unsubscribe from this
> so either the comment just above lock_kernel() should be removed, or
> it's correct and lock_kernel()/unlock_kernel() should stay.
Ah somehow missed the comment. Ok so it's better to keep it, although
there would be probably better ways to protect the pattern.
-Andi
-
To unsubscribe from this
Andi Kleen wrote:
Alan Cox <[EMAIL PROTECTED]> writes:
I saw that too, and unfortunately I don't know what what that condition
represents, either. It's the only other element in that if statement
that could make it take that path, so I'm assuming that's part of the
problem.
Multiple mm's
Alan Cox wrote:
Looking at the code, it seems to me that format_corename() is appending
.pid, regardless if !core_uses_pid and corename[0]=='|', in which case
it creates an invalid path for call_usermodehelper_pipe().
Bug in the code, or bug in my methods?
This looks somewhat better and
> Looking at the code, it seems to me that format_corename() is appending
> .pid, regardless if !core_uses_pid and corename[0]=='|', in which case
> it creates an invalid path for call_usermodehelper_pipe().
>
> Bug in the code, or bug in my methods?
This looks somewhat better and might do the
Alan Cox <[EMAIL PROTECTED]> writes:
> > I saw that too, and unfortunately I don't know what what that condition
> > represents, either. It's the only other element in that if statement
> > that could make it take that path, so I'm assuming that's part of the
> > problem.
>
> Multiple mm's
> I saw that too, and unfortunately I don't know what what that condition
> represents, either. It's the only other element in that if statement
> that could make it take that path, so I'm assuming that's part of the
> problem.
Multiple mm's mean multiple threads with a different set of
I saw that too, and unfortunately I don't know what what that condition
represents, either. It's the only other element in that if statement
that could make it take that path, so I'm assuming that's part of the
problem.
Multiple mm's mean multiple threads with a different set of mappings,
Alan Cox [EMAIL PROTECTED] writes:
I saw that too, and unfortunately I don't know what what that condition
represents, either. It's the only other element in that if statement
that could make it take that path, so I'm assuming that's part of the
problem.
Multiple mm's mean multiple
Looking at the code, it seems to me that format_corename() is appending
.pid, regardless if !core_uses_pid and corename[0]=='|', in which case
it creates an invalid path for call_usermodehelper_pipe().
Bug in the code, or bug in my methods?
This looks somewhat better and might do the
Alan Cox wrote:
Looking at the code, it seems to me that format_corename() is appending
.pid, regardless if !core_uses_pid and corename[0]=='|', in which case
it creates an invalid path for call_usermodehelper_pipe().
Bug in the code, or bug in my methods?
This looks somewhat better and
Andi Kleen wrote:
Alan Cox [EMAIL PROTECTED] writes:
I saw that too, and unfortunately I don't know what what that condition
represents, either. It's the only other element in that if statement
that could make it take that path, so I'm assuming that's part of the
problem.
Multiple mm's
so either the comment just above lock_kernel() should be removed, or
it's correct and lock_kernel()/unlock_kernel() should stay.
Ah somehow missed the comment. Ok so it's better to keep it, although
there would be probably better ways to protect the pattern.
-Andi
-
To unsubscribe from this
Here's a patch. It just doesn't do any formatting for the pipe case.
I don't see a reaosn for removing the formatting features. There are ways
that can usefully be used, although not many. It's also messier than the
patch I posted while less functional IMHO.
Alan
-
To unsubscribe from this
On Fri, Apr 13, 2007 at 05:17:27PM +0100, Alan Cox wrote:
Here's a patch. It just doesn't do any formatting for the pipe case.
I don't see a reaosn for removing the formatting features. There are ways
that can usefully be used, although not many. It's also messier than the
patch I posted
On Thu, Apr 12, 2007 at 10:57:37PM -0400, Christopher S. Aker wrote:
> The process is a UML instance (skas mode, so at least a kernel,
> userspace, and io thread), which will generate a single, usable, core
> file just fine with a non-pipe core_pattern...
Yeah, but can you get a core file
Randy Dunlap wrote:
On Thu, 12 Apr 2007 22:22:18 -0400 Christopher S. Aker wrote:
Alan Cox wrote:
> Indeed. So useful that in current kernels you can set the core dump
> path to be
>
> "|application"
Cool stuff! However, it's not working (2.6.20.6):
Core dump to
On Thu, 12 Apr 2007 22:22:18 -0400 Christopher S. Aker wrote:
> Alan Cox wrote:
> > Indeed. So useful that in current kernels you can set the core dump
> > path to be
> >
> >"|application"
>
> Cool stuff! However, it's not working (2.6.20.6):
>
> Core dump to
Alan Cox wrote:
> Indeed. So useful that in current kernels you can set the core dump
> path to be
>
>"|application"
Cool stuff! However, it's not working (2.6.20.6):
Core dump to |/home/caker/bin/dumper.pl.4442 pipe failed
even though...
# cat
"Bill Rugolsky Jr." <[EMAIL PROTECTED]> writes:
>
> The current functionality doesn't parse command line arguments into argv,
> nor provide the % variable replacements in the environment, so it is
> somewhat less useful than it could be.
That was intentional because all this information is in
On Thu, Apr 12, 2007 at 11:52:38AM -0400, Christopher S. Aker wrote:
> I've been trying to find a method for compressing process core dumps
> before they hit disk.
>
> I ask because we've got some fairly large UML processes (1GB for some),
> and we're trying to capture dumps to help Jeff debug
On Thu, Apr 12, 2007 at 05:28:45PM +0100, Alan Cox wrote:
> > There are userspace solutions to this problem: allowing the
> > uncompressed core dump to spin out to disk and then coming in afterwards
> > and doing the compression, or maybe even a compressed filesystem where
> > the core dumps
> There are userspace solutions to this problem: allowing the
> uncompressed core dump to spin out to disk and then coming in afterwards
> and doing the compression, or maybe even a compressed filesystem where
> the core dumps land, but I just thought I'd throw this out there since
> it seems
2007/4/12, Christopher S. Aker <[EMAIL PROTECTED]>:
I've been trying to find a method for compressing process core dumps
before they hit disk.
This seems to be a good use of:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d025c9db7f31fc0554ce7fb2dfc78d35a77f3487
I've been trying to find a method for compressing process core dumps
before they hit disk.
I ask because we've got some fairly large UML processes (1GB for some),
and we're trying to capture dumps to help Jeff debug an evasive bug.
Our systems use a small root partition and most of the other
I've been trying to find a method for compressing process core dumps
before they hit disk.
I ask because we've got some fairly large UML processes (1GB for some),
and we're trying to capture dumps to help Jeff debug an evasive bug.
Our systems use a small root partition and most of the other
2007/4/12, Christopher S. Aker [EMAIL PROTECTED]:
I've been trying to find a method for compressing process core dumps
before they hit disk.
This seems to be a good use of:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d025c9db7f31fc0554ce7fb2dfc78d35a77f3487
There are userspace solutions to this problem: allowing the
uncompressed core dump to spin out to disk and then coming in afterwards
and doing the compression, or maybe even a compressed filesystem where
the core dumps land, but I just thought I'd throw this out there since
it seems it
On Thu, Apr 12, 2007 at 11:52:38AM -0400, Christopher S. Aker wrote:
I've been trying to find a method for compressing process core dumps
before they hit disk.
I ask because we've got some fairly large UML processes (1GB for some),
and we're trying to capture dumps to help Jeff debug an
On Thu, Apr 12, 2007 at 05:28:45PM +0100, Alan Cox wrote:
There are userspace solutions to this problem: allowing the
uncompressed core dump to spin out to disk and then coming in afterwards
and doing the compression, or maybe even a compressed filesystem where
the core dumps land, but
Bill Rugolsky Jr. [EMAIL PROTECTED] writes:
The current functionality doesn't parse command line arguments into argv,
nor provide the % variable replacements in the environment, so it is
somewhat less useful than it could be.
That was intentional because all this information is in the core
Alan Cox wrote:
Indeed. So useful that in current kernels you can set the core dump
path to be
|application
Cool stuff! However, it's not working (2.6.20.6):
Core dump to |/home/caker/bin/dumper.pl.4442 pipe failed
even though...
# cat /proc/sys/kernel/core_uses_pid
On Thu, 12 Apr 2007 22:22:18 -0400 Christopher S. Aker wrote:
Alan Cox wrote:
Indeed. So useful that in current kernels you can set the core dump
path to be
|application
Cool stuff! However, it's not working (2.6.20.6):
Core dump to |/home/caker/bin/dumper.pl.4442
Randy Dunlap wrote:
On Thu, 12 Apr 2007 22:22:18 -0400 Christopher S. Aker wrote:
Alan Cox wrote:
Indeed. So useful that in current kernels you can set the core dump
path to be
|application
Cool stuff! However, it's not working (2.6.20.6):
Core dump to
On Thu, Apr 12, 2007 at 10:57:37PM -0400, Christopher S. Aker wrote:
The process is a UML instance (skas mode, so at least a kernel,
userspace, and io thread), which will generate a single, usable, core
file just fine with a non-pipe core_pattern...
Yeah, but can you get a core file without
36 matches
Mail list logo
