Re: [Crash-utility] crashdc: problem when running crash in kexec environment for SLES11
----- "Louis Bouchard" <louis.bouchard(a)hp.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everyone,
Bernhard Walle a écrit :
>
> I don't think so. I just tried to reproduce the problem here with
> openSUSE 11.1 (I have no SLES). In my case, I also got the "killed", but
> it was too less memory. I changed the reservation to be 256 MiB for the
> crashkernel, and now it works.
>
For info, I'm doing the dev on an i686 VMware guest for now.
Bernhard found the SLES11 problem : memory was too tight to allow
crash/gdb to run.
I increased the mem reservation with the following :
crashkernel=256M-:128M@16M
and got crash to run my commands. I have a smaller problem now. I'm
issueing the following commands to crash :
> !echo "### Crash Context Information" >>
/var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> !echo "crash> sys" >>
/var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> sys >> /var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> !echo -n `date`;echo "### Preserved Kernel Ring Buffer"
> !echo "### Preserved Kernel Ring Buffer" >>
/var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> !echo "crash> log" >>
/var/crash/2009-09-25-11:31/crash-data-200909251134.txt
> log >> /var/crash/2009-09-25-11:31/crash-data-200909251134.txt
I did include /bin/echo in the KDUMP_REQUIRED_PROGRAMS variable, but
crash still returns :
> crash: cannot open pipe: echo "### Crash Context Information" >>
/root/var/crash/2009-10-01-15:51/crash-data-200910011552.txt
> crash: cannot open pipe: echo "crash> sys" >>
/root/var/crash/2009-10-01-15:51/crash-data-200910011552.txt
> crash: cannot open pipe: echo -n `date`;echo "### Preserved Kernel Ring
Buffer"
> crash: cannot open pipe: echo "### Preserved Kernel Ring Buffer" >>
/root/var/crash/2009-10-01-15:51/crash-data-200910011552.txt
So it looks like the ! to shell out the "echo "... command doesn't work,
most probably because of the limited commands in the kexec environment.
It's probably worth figuring out why the popen() command failed?
The function printing the error message is here in cmdline.c:
int
shell_command(char *cmd)
{
FILE *pipe;
char buf[BUFSIZE];
if ((pipe = popen(cmd, "r")) == NULL) {
error(INFO, "cannot open pipe: %s\n", cmd);
pc->redirect &= ~REDIRECT_SHELL_COMMAND;
pc->redirect |= REDIRECT_FAILURE;
return REDIRECT_FAILURE;
}
I didn't bother to gather/display the errno information in the function above
since it's irrelevant if there's a memory allocation issue. From the popen()
man page:
RETURN VALUE
The popen() function returns NULL if the fork(2) or pipe(2) calls fail,
or if it cannot allocate memory.
The pclose() function returns -1 if wait4() returns an error, or some
other error is detected.
ERRORS
The popen() function does not set errno if memory allocation fails. If
the underlying fork() or pipe() fails, errno is set appropriately. If
the type argument is invalid, and this condition is detected, errno is
set to EINVAL.
Also, does "echo" alone maybe use the shell's built-in echo instead of
/bin/echo?
Did you force it by using "/bin/echo" in the script's comand lines instead
of
just "echo"?
BTW, you can also try removing the ! from in front of the "echo" commands in
the input file, because the crash utility will just pass the remaining string
to system() instead of popen(). But I would guess that system() would fail
for the same reason as popen().
Dave