8:30 a.m.
Long after I stopped tinkering with the LKCD code in crash,
changes were contributed to support physical memory zones
in the LKCD dumpfile format. Specifically there is this
piece of save_offset() in lkcd_common.c:
/* find the zone */
for (ii=0; ii < lkcd->num_zones; ii++) {
if (lkcd->zones[ii].start == zone) {
if (lkcd->zones[ii].pages[page].offset != 0) {
if (lkcd->zones[ii].pages[page].offset != off) {
error(INFO, "conflicting page: zone %lld, "
"page %lld: %lld, %lld != %lld\n",
(unsigned long long)zone,
(unsigned long long)page,
(unsigned long long)paddr,
(unsigned long long)off,
(unsigned long long) \
lkcd->zones[ii].pages[page].offset);
abort();
}
ret = 0;
} else {
lkcd->zones[ii].pages[page].offset = off;
ret = 1;
}
break;
}
}
The call to abort() above kills the crash session, which is both
annoying and unnecessary.
I am seeing it in a customer dumpfile, who have their own dumping scheme
that is based upon LKCD version 7. I understand that this may be a
problem with their LKCD port, but nonetheless, it's the only place in
the crash utility that doesn't recover gracefully from dumpfile access
errors.
Anyway, I would like to either:
1. change the error(INFO...) to error(FATAL...) so that run-time
commands encountering this error will just fail, and the session
will return to the crash> prompt, or
2. return 0, so that a "seek error" can be subsequently displayed
by the readmem() command.
Number 2 is preferable, because it yields more clues as to where the
readmem() came from, but since I don't know much about the LKCD
physical memory zones stuff, is there any reason that shouldn't
be done?
Thanks,
Dave
7:17 p.m.
New subject: Question for LKCD maintainers - How about adding a debug flag to crash and only calling abort() if crash is started with '-d' flag provided?
Dave Anderson wrote:
Long after I stopped tinkering with the LKCD code in crash,
changes were contributed to support physical memory zones
in the LKCD dumpfile format.
Hi Dave:
That could easily have been me. I added zone support to the
LKCD kernel and lcrash code and then updated your crash code
to support zones. I kinda recall LKCD not dumping in monotonically
increasing order and my modifying your crash code to live with this
new feature in the LKCD dumps. I was trying to get the LKCD folks into
supporting crash in addition to lcrash but failed to get any support from
Tom Morano or Matt Robinson. I didn't realize that I had broken crash
with the zone changes and felt responsible to fix crash to deal with this
change that I had made. I also like the crash interface over the lcrash
interface. I proposed to Tom using the elf format like KEXEC uses but
he didn't go for it. I don't know why we can't hid additional crash info
into ELF files and maintain as much compatibility as possible.
Specifically there is this
piece of save_offset() in lkcd_common.c:
/* find the zone */
for (ii=0; ii < lkcd->num_zones; ii++) {
if (lkcd->zones[ii].start == zone) {
if (lkcd->zones[ii].pages[page].offset != 0) {
if (lkcd->zones[ii].pages[page].offset !=
off) {
error(INFO, "conflicting page: zone
%lld, "
"page %lld: %lld, %lld !=
%lld\n",
(unsigned long long)zone,
(unsigned long long)page,
(unsigned long long)paddr,
(unsigned long long)off,
(unsigned long long) \
lkcd->zones[ii].pages[page].offset);
abort();
}
ret = 0;
} else {
lkcd->zones[ii].pages[page].offset = off;
ret = 1;
}
break;
}
}
The printf looks a bit like my coding style, though I don't know
why (I ?) decided to abort() in this case. I suppose the idea is
to look at the situation with gdb on the resulting core file.
The call to abort() above kills the crash session, which is both
annoying and unnecessary.
Isn't it worth while to look at the core file to
understand the reason
for the abort() being called for?
I am seeing it in a customer dumpfile, who have their own dumping scheme
that is based upon LKCD version 7. I understand that this may be a
problem with their LKCD port, but nonetheless, it's the only place in
the crash utility that doesn't recover gracefully from dumpfile access
errors.
Anyway, I would like to either:
1. change the error(INFO...) to error(FATAL...) so that run-time
commands encountering this error will just fail, and the session
will return to the crash> prompt, or
2. return 0, so that a "seek error" can be subsequently displayed
by the readmem() command.
Number 2 is preferable, because it yields more clues as to where the
readmem() came from, but since I don't know much about the LKCD
physical memory zones stuff, is there any reason that shouldn't
be done?
How about having a crash debug flag and only calling abort if the
debug flag is set. You might print in the error message that the
user can force a core dump by adding a '-d' flag on invocation of
crash and sending you the core file.
While I've got your attention. I'm upgrading our 2.6.12-stable kernel to
2.6.16-stable and want to start supporting core dumps. Ideally I'd like to
have core dumps that are compatible with gdb and crash. Can crash
handle the elf core files generated by KEXEC/KCORE. Last I thought
about this I recall there being incompatibilities and it getting worse
with kernels being compiled to be relocatable and kgdb having a problem
because it wasn't aware of the relocation.
When you have some free time could you let me know your current opinion
of the state of these computability issues and where it's going?
-piet
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
9:29 a.m.
New subject: Question for LKCD maintainers - How about adding a debug flag to crash and only calling abort() if crash is started with '-d' flag provided?
Piet Delaney wrote:
Dave Anderson wrote:
>Long after I stopped tinkering with the LKCD code in crash,
>changes were contributed to support physical memory zones
>in the LKCD dumpfile format.
Hi Dave:
That could easily have been me. I added zone support to the
LKCD kernel and lcrash code and then updated your crash code
to support zones. I kinda recall LKCD not dumping in monotonically
increasing order and my modifying your crash code to live with this
new feature in the LKCD dumps. I was trying to get the LKCD folks into
supporting crash in addition to lcrash but failed to get any support from
Tom Morano or Matt Robinson. I didn't realize that I had broken crash
with the zone changes and felt responsible to fix crash to deal with this
change that I had made. I also like the crash interface over the lcrash
interface. I proposed to Tom using the elf format like KEXEC uses but
he didn't go for it. I don't know why we can't hid additional crash info
into ELF files and maintain as much compatibility as possible.
> Specifically there is this
>piece of save_offset() in lkcd_common.c:
>
> /* find the zone */
> for (ii=0; ii < lkcd->num_zones; ii++) {
> if (lkcd->zones[ii].start == zone) {
> if (lkcd->zones[ii].pages[page].offset != 0) {
> if (lkcd->zones[ii].pages[page].offset !=
>off) {
> error(INFO, "conflicting page: zone
>%lld, "
> "page %lld: %lld, %lld !=
>%lld\n",
> (unsigned long long)zone,
> (unsigned long long)page,
> (unsigned long long)paddr,
> (unsigned long long)off,
> (unsigned long long) \
>
>lkcd->zones[ii].pages[page].offset);
> abort();
> }
> ret = 0;
> } else {
> lkcd->zones[ii].pages[page].offset = off;
> ret = 1;
> }
> break;
> }
> }
The printf looks a bit like my coding style, though I don't know
why (I ?) decided to abort() in this case. I suppose the idea is
to look at the situation with gdb on the resulting core file.
>The call to abort() above kills the crash session, which is both
>annoying and unnecessary.
Isn't it worth while to look at the core file to understand the reason
for the abort() being called for?
I would think so, but not by me -- the developers of this LKCD
off-shoot can debug their own stuff.
>I am seeing it in a customer dumpfile, who have their own dumping scheme
>that is based upon LKCD version 7. I understand that this may be a
>problem with their LKCD port, but nonetheless, it's the only place in
>the crash utility that doesn't recover gracefully from dumpfile access
>errors.
>
>Anyway, I would like to either:
>
> 1. change the error(INFO...) to error(FATAL...) so that run-time
> commands encountering this error will just fail, and the session
> will return to the crash> prompt, or
> 2. return 0, so that a "seek error" can be subsequently displayed
> by the readmem() command.
>
>Number 2 is preferable, because it yields more clues as to where the
>readmem() came from, but since I don't know much about the LKCD
>physical memory zones stuff, is there any reason that shouldn't
>be done?
How about having a crash debug flag and only calling abort if the
debug flag is set. You might print in the error message that the
user can force a core dump by adding a '-d' flag on invocation of
crash and sending you the core file.
Regardless of the reason behind it, the whole point is that there
was no need to abort the crash session. If the "missing" page was
crucial to the crash session being able to run, then crash would
die on its own terms. There are no other abort() calls in the
crash sources.
But in this case, the page was unnecessary for analysis of
the problem. But when some commands (I forget which -- certainly
"search" for example) bumped into the page, the session would
abort() and had to be started up again.
Anyway, the abort() call was removed in version 4.0-4.9:
- Fix for LKCD dumpfile access failures that abort() the crash session
after displaying an error message indicating a problem with physical
memory zones in the dumpfile. Without the patch, the crash session
would end immediately after displaying an error message of the sort:
"conflicting page: zone 0, page 0: 0, 177160130 != 65536". That
error message will now only be displayed if the crash debug mode is 1
or more, a readmem() "seek error" will be displayed instead, and the
session will return to the "crash>" prompt. (anderson(a)redhat.com)
This was the patch:
--- lkcd_common.c 15 Nov 2007 15:44:38 -0000 1.29
+++ lkcd_common.c 19 Nov 2007 15:48:18 -0000 1.30
@@ -708,14 +708,15 @@
if (lkcd->zones[ii].start == zone) {
if (lkcd->zones[ii].pages[page].offset != 0) {
if (lkcd->zones[ii].pages[page].offset != off) {
- error(INFO, "conflicting page: zone %lld, "
+ if (CRASHDEBUG(1))
+ error(INFO, "LKCD: conflicting page: zone
%lld, "
"page %lld: %lld, %lld != %lld\n",
(unsigned long long)zone,
(unsigned long long)page,
(unsigned long long)paddr,
(unsigned long long)off,
(unsigned long
long)lkcd->zones[ii].pages[page].offset);
- abort();
+ return -1;
}
ret = 0;
} else {
With respect to the -d flag suggestion, if you want to drop core
then you can set the internal crash "core" variable to "on", which
which will force a segmentation violation after printing the next
error message:
crash> set core
core: off (do NOT drop core on error message)
crash> set core on
core: on (drop core on error message)
crash>
And then run the command that generates the error, say for
example, reading a non-existent physical address:
crash> rd -p deadbeef
[./crash] error trace: 8095503 => 8095799 => 8096ab4 => 808879c
rd: read error: physical address: deadbeef type: "32-bit PHYSADDR"
808879c: __error+108
8096ab4: readmem+1328
8095799: display_memory+657
8095503: cmd_rd+1558
DROP_CORE flag set: forcing a segmentation fault
Segmentation fault (core dumped)
$
While I've got your attention. I'm upgrading our 2.6.12-stable kernel to
2.6.16-stable and want to start supporting core dumps. Ideally I'd like to
have core dumps that are compatible with gdb and crash. Can crash
handle the elf core files generated by KEXEC/KCORE. Last I thought
about this I recall there being incompatibilities and it getting worse
with kernels being compiled to be relocatable and kgdb having a problem
because it wasn't aware of the relocation.
By "KEXEC/KCORE" I'm presuming you mean "kexec/kdump", but
I'm
not sure what incompatibility you're referring to?
Maybe the workaround for x86 kernels whose CONFIG_PHYSICAL_START
contains a value that is greater then CONFIG_PHYSICAL_ALIGN:
http://people.redhat.com/anderson/crash.changelog.html#4_0_4_5
Or maybe you're talking about 32-bit gdb not being able to handle
kdump-generated 64-bit ELF core files for 32-bit kernels?
Dave
12:40 a.m.
New subject: Patch to include -f option to display commadline args with ps command of crash.
Hi Dave,
I am here with submitting the patch to incorporate -f option to carsh ps
command. Which will display as same as ps command with command line
arguments.
Sample output of normal ps in crash
crash> ps
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 33a4c8 RU 0.0 0 0 [swapper]
0 1 1 f85a718 RU 0.0 0 0 [swapper]
2357 1 0 e8575c8 IN 0.1 11320 344 dbus-daemon
2358 1 1 ede30f0 IN 0.1 11320 344 dbus-daemon
2394 1 0 e87aa18 IN 0.2 75280 496 automount
2395 1 0 eea2718 IN 0.2 75280 496 automount
2396 1 1 fa4d7c8 IN 0.2 75280 496 automount
2399 1 0 eec6ff0 IN 0.2 75280 496 automount
2402 1 1 ee3b7c8 IN 0.2 75280 496 automount
2415 1 0 e9a6818 IN 0.0 7200 44 sshd
2425 1 0 eea0a18 IN 0.5 94944 1396
setroubleshootd
2426 1 1 ede2340 IN 0.5 94944 1396
setroubleshootd
2427 1 0 ee06140 IN 0.0 64452 28 cupsd
2446 1 0 fa336c8 IN 0.2 10464 476 sendmail
2456 1 0 ee3b0f0 IN 0.2 9320 416 sendmail
2468 1 0 ee5f5c8 IN 0.1 58628 188 crond
2491 1 1 ef417c8 IN 0.0 4516 80 xfs
2513 1 0 e8fe340 IN 0.1 2548 200 atd
2525 1 1 e982340 IN 2.7 87636 7112 yum-updatesd
Sample output of ps -f in crash
crash> ps -f
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 33a4c8 RU 0.0 0 0 [swapper]
0 1 1 f85a718 RU 0.0 0 0 [swapper]
1914 2 0 ee054c8 IN 0.0 0 0 [kjournald]
2210 1 1 fab4040 IN 0.1 10300 280 auditd
2211 1 0 e8ff7c8 IN 0.1 10300 280 auditd
2212 2210 1 eea34c8 IN 0.4 65244 992 python
/sbin/audispd
2213 2 1 ee5cdf0 IN 0.0 0 0 [kauditd]
2227 1 0 e878ff0 IN 0.0 15544 84
/usr/sbin/restorecond
2237 1 1 fa26140 IN 0.1 1976 188 syslogd -m 0
2240 1 1 eec55c8 IN 0.0 1908 16 klogd -x
2255 1 0 ef434c8 IN 0.1 2468 248 mcstransd
2267 1 0 f980818 IN 0.0 2088 12 portmap
2282 1 1 e854718 IN 0.5 94944 1396
/usr/bin/python -E /usr/sbin/setroubleshootd
2302 1 0 e9e90f0 IN 0.0 2096 16 rpc.statd
2332 2 0 f96e718 IN 0.0 0 0 [rpciod/0]
2333 2 1 ee5e818 IN 0.0 0 0 [rpciod/1]
2340 1 1 ef40340 IN 0.0 6256 52 rpc.idmapd
2357 1 0 e8575c8 IN 0.1 11320 344 dbus-daemon
--system
2358 1 1 ede30f0 IN 0.1 11320 344 dbus-daemon
--system
2394 1 0 e87aa18 IN 0.2 75280 496 automount
2395 1 0 eea2718 IN 0.2 75280 496 automount
2396 1 1 fa4d7c8 IN 0.2 75280 496 automount
2399 1 1 eec6ff0 IN 0.2 75280 496 automount
2402 1 1 ee3b7c8 IN 0.2 75280 496 automount
2415 1 0 e9a6818 IN 0.0 7200 44
/usr/sbin/sshd
2425 1 0 eea0a18 IN 0.5 94944 1396
/usr/bin/python -E /usr/sbin/setroubleshootd
2426 1 1 ede2340 IN 0.5 94944 1396
/usr/bin/python -E /usr/sbin/setroubleshootd
2427 1 0 ee06140 IN 0.0 64452 28 cupsd
2446 1 0 fa336c8 IN 0.2 10464 476 sendmail:
accepting connecti
2456 1 0 ee3b0f0 IN 0.2 9320 416 sendmail:
Queue runner@01:00:00 for /var/spo
2468 1 0 ee5f5c8 IN 0.1 58628 188 crond
2491 1 1 ef417c8 IN 0.0 4516 80 xfs
-droppriv -daemon
2513 1 0 e8fe340 IN 0.1 2548 200
/usr/sbin/atd
2525 1 1 e982340 IN 2.7 87636 7112
/usr/bin/python /usr/sbin/yum-updatesd
COMM will be with command line arguments.
Patch : (See attached file: crash-ps-f-opt.patch)
Regards
Hariharan T.S.
System Software Engineer,
zSeries - Red Hat Enterprise Linux,
India Software Lab - IBM Systems & Technology Group,
Embassy Golf Links Business Park, Bangalore, INDIA
Direct +91-80-4177-7545
e-mail: hariharan.ts(a)in.ibm.com
India Software Lab
9:58 a.m.
New subject: Patch to include -f option to display commadline args with ps command of crash.
Hariharan S Reddy wrote:
Hi Dave,
I am here with submitting the patch to incorporate -f option to carsh ps
command. Which will display as same as ps command with command line
arguments.
...and which basically duplicates the current capability of the "ps -a" option,
which does its best to gather the full command line along with the task's
environment variables.
The problem is that it depends upon accessing user-space memory which may
not be available, i.e., either swapped out or configured out of the dumpfile
entirely. That makes the output really ugly -- for example on the live
system that I'm running on:
crash> ps -f
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 c066d3c0 RU 0.0 0 0 [swapper]
0 1 1 c148e550 RU 0.0 0 0 [swapper]
1 0 1 c148eaa0 IN 0.1 2040 564 init [5]
2 1 0 c148e000 IN 0.0 0 0 [migration/0]
3 1 0 c14a0aa0 IN 0.0 0 0 [ksoftirqd/0]
4 1 0 c14a0550 IN 0.0 0 0 [watchdog/0]
5 1 1 c14a0000 IN 0.0 0 0 [migration/1]
6 1 1 c14adaa0 IN 0.0 0 0 [ksoftirqd/1]
7 1 1 c14ad550 IN 0.0 0 0 [watchdog/1]
8 1 0 c14ad000 IN 0.0 0 0 [events/0]
9 1 1 dff63aa0 IN 0.0 0 0 [events/1]
10 1 1 dff63550 IN 0.0 0 0 [khelper]
11 1 0 dff63000 IN 0.0 0 0 [kthread]
15 11 0 dff31aa0 IN 0.0 0 0 [kblockd/0]
16 11 1 dff31550 IN 0.0 0 0 [kblockd/1]
17 11 1 dff31000 IN 0.0 0 0 [kacpid]
96 11 0 dff4b550 IN 0.0 0 0 [cqueue/0]
97 11 1 dff4b000 IN 0.0 0 0 [cqueue/1]
100 11 0 dff09550 IN 0.0 0 0 [khubd]
102 11 0 dff13550 IN 0.0 0 0 [kseriod]
163 11 0 dfe0a550 IN 0.0 0 0 [pdflush]
164 11 1 dfe0a000 IN 0.0 0 0 [pdflush]
165 11 0 dfe0daa0 IN 0.0 0 0 [kswapd0]
166 11 0 dfe0d550 IN 0.0 0 0 [aio/0]
167 11 1 dfe0d000 IN 0.0 0 0 [aio/1]
331 11 0 dfe02aa0 IN 0.0 0 0 [kpsmoused]
362 11 0 dfeb8000 IN 0.0 0 0 [ata/0]
363 11 1 dfeb8550 IN 0.0 0 0 [ata/1]
364 11 0 dfeb8aa0 IN 0.0 0 0 [ata_aux]
380 11 0 dfea4550 IN 0.0 0 0 [ksnapd]
383 11 0 dfbf1550 IN 0.0 0 0 [kjournald]
416 11 1 dfe53aa0 IN 0.0 0 0 [kauditd]
450 1 1 dff03000 IN 0.1 2944 404 /sbin/udevd -d
896 11 0 df2ae000 IN 0.0 0 0 [kedac]
1558 11 0 dde7faa0 IN 0.0 0 0 [kmpathd/0]
1559 11 1 ddccd000 IN 0.0 0 0 [kmpathd/1]
1583 11 0 de2f9000 IN 0.0 0 0 [kjournald]
1970 1 0 dfbfbaa0 IN 0.1 2288 528 /sbin/dhclient -1 -q -lf
/var/lib/dhclient/dhclient-eth0.l
eases -pf /var/run/dhclient-eth0.pid eth0
2022 1 0 dd42daa0 IN 0.1 12076 552 ps: cannot access user
stack address: bfc30ec5
2023 1 0 dddfe000 IN 0.1 12076 552 ps: cannot access user
stack address: bfc30ec5
2024 2022 0 ddfc8000 IN 0.4 10096 2096 python /sbin/audispd
2039 1 1 ddd52000 IN 0.1 10080 372 ps: cannot access user
stack address: bfb0eeff
2050 1 1 de788000 IN 0.1 1700 532 ps: cannot access user
stack address: bf877f11
2053 1 0 de1ba000 IN 0.1 1656 388 klogd -x
2065 1 1 df1ef000 IN 0.1 2412 332 irqbalance
2081 1 0 de15b000 IN 0.1 2136 440 mcstransd
2094 1 0 dfe64550 IN 0.1 1788 572 portmap
2107 1 1 ddb6aaa0 RU 1.1 41628 5576 ps: cannot access user
stack address: bff97ee0
2128 1 1 dfebd000 IN 0.1 1940 712 ps: cannot access user
stack address: bf8b4f10
2165 1 1 dddfeaa0 IN 0.1 5400 380 ps: cannot access user
stack address: bfd6ef05
2184 1 1 dddfe550 IN 0.2 13216 1300 dbus-daemon --system
2185 1 0 dfea4aa0 IN 0.2 13216 1300 dbus-daemon --system
2223 1 0 ddb0aaa0 IN 0.2 53728 940 pcscd
2238 1 1 de1ba550 IN 0.2 53728 940 pcscd
2255 1 1 dfbf5550 IN 0.1 1888 344 ps: cannot access user
stack address: bfa6ff07
2274 1 1 ddaf4550 IN 1.1 41628 5576 ps: cannot access user
stack address: bff97ee0
2275 1 1 dd79baa0 IN 1.1 41628 5576 ps: cannot access user
stack address: bff97ee0
2281 1 0 dfbf1aa0 IN 0.1 24376 380 ps: cannot access user
stack address: bfea7f19
2282 1 1 dd629550 IN 0.1 24376 380 ps: cannot access user
stack address: bfea7f19
2284 1 0 ddb6a550 IN 0.1 24376 380 ps: cannot access user
stack address: bfea7f19
2305 1 0 de1baaa0 IN 0.2 18948 1296 automount
2306 1 0 dd9ad550 IN 0.2 18948 1296 automount
2307 1 1 dece8000 IN 0.2 18948 1296 automount
2310 1 0 ddb6a000 IN 0.2 18948 1296 automount
2313 1 0 df2ae550 IN 0.2 18948 1296 automount
2314 1 1 de75d550 IN 0.2 18948 1296 automount
2315 1 0 dfebdaa0 IN 0.2 18948 1296 automount
2316 1 0 df2aeaa0 IN 0.2 18948 1296 automount
2327 1 0 de07b000 IN 0.1 1652 424 ps: cannot access user
stack address: bf806f0a
2338 1 0 de21d550 IN 0.1 5068 300 ps: cannot access user
stack address: bf94af1a
2343 1 1 dfbf5000 IN 0.2 13192 1224 ps: cannot access user
stack address: bfd07efe
2358 1 1 dff09000 IN 0.1 6148 576 ps: cannot access user
stack address: bfc57f0d
2369 1 1 dd79b550 IN 0.3 9880 1628 ps: cannot access user
stack address: bfd7df14
2383 1 0 ddaf4000 IN 0.8 4448 4448 ntpd -u ntp:ntp -p
/var/run/ntpd.pid -g
2404 1 1 df1efaa0 IN 0.2 9032 968 sendmail: accepting connecti
2413 1 1 dfbf5aa0 IN 0.1 8084 724 ps: cannot access user
stack address: bf990ee8
2425 1 1 dff13aa0 IN 0.1 1876 276 ps: cannot access user
stack address: bf9fbefe
2436 1 0 de21d000 IN 0.1 5240 708 crond
2467 1 0 de07baa0 IN 0.2 4044 960 xfs -droppriv -daemon
2488 1 0 dd414000 IN 0.1 2220 340 ps: cannot access user
stack address: bfc30f10
...
Not to mention that it violates the 80-column output that I try to
enforce with most commands.
Dave
Sample output of normal ps in crash
crash> ps
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 33a4c8 RU 0.0 0 0 [swapper]
0 1 1 f85a718 RU 0.0 0 0 [swapper]
2357 1 0 e8575c8 IN 0.1 11320 344 dbus-daemon
2358 1 1 ede30f0 IN 0.1 11320 344 dbus-daemon
2394 1 0 e87aa18 IN 0.2 75280 496 automount
2395 1 0 eea2718 IN 0.2 75280 496 automount
2396 1 1 fa4d7c8 IN 0.2 75280 496 automount
2399 1 0 eec6ff0 IN 0.2 75280 496 automount
2402 1 1 ee3b7c8 IN 0.2 75280 496 automount
2415 1 0 e9a6818 IN 0.0 7200 44 sshd
2425 1 0 eea0a18 IN 0.5 94944 1396
setroubleshootd
2426 1 1 ede2340 IN 0.5 94944 1396
setroubleshootd
2427 1 0 ee06140 IN 0.0 64452 28 cupsd
2446 1 0 fa336c8 IN 0.2 10464 476 sendmail
2456 1 0 ee3b0f0 IN 0.2 9320 416 sendmail
2468 1 0 ee5f5c8 IN 0.1 58628 188 crond
2491 1 1 ef417c8 IN 0.0 4516 80 xfs
2513 1 0 e8fe340 IN 0.1 2548 200 atd
2525 1 1 e982340 IN 2.7 87636 7112 yum-updatesd
Sample output of ps -f in crash
crash> ps -f
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 33a4c8 RU 0.0 0 0 [swapper]
0 1 1 f85a718 RU 0.0 0 0 [swapper]
1914 2 0 ee054c8 IN 0.0 0 0 [kjournald]
2210 1 1 fab4040 IN 0.1 10300 280 auditd
2211 1 0 e8ff7c8 IN 0.1 10300 280 auditd
2212 2210 1 eea34c8 IN 0.4 65244 992 python
/sbin/audispd
2213 2 1 ee5cdf0 IN 0.0 0 0 [kauditd]
2227 1 0 e878ff0 IN 0.0 15544 84
/usr/sbin/restorecond
2237 1 1 fa26140 IN 0.1 1976 188 syslogd -m 0
2240 1 1 eec55c8 IN 0.0 1908 16 klogd -x
2255 1 0 ef434c8 IN 0.1 2468 248 mcstransd
2267 1 0 f980818 IN 0.0 2088 12 portmap
2282 1 1 e854718 IN 0.5 94944 1396
/usr/bin/python -E /usr/sbin/setroubleshootd
2302 1 0 e9e90f0 IN 0.0 2096 16 rpc.statd
2332 2 0 f96e718 IN 0.0 0 0 [rpciod/0]
2333 2 1 ee5e818 IN 0.0 0 0 [rpciod/1]
2340 1 1 ef40340 IN 0.0 6256 52 rpc.idmapd
2357 1 0 e8575c8 IN 0.1 11320 344 dbus-daemon
--system
2358 1 1 ede30f0 IN 0.1 11320 344 dbus-daemon
--system
2394 1 0 e87aa18 IN 0.2 75280 496 automount
2395 1 0 eea2718 IN 0.2 75280 496 automount
2396 1 1 fa4d7c8 IN 0.2 75280 496 automount
2399 1 1 eec6ff0 IN 0.2 75280 496 automount
2402 1 1 ee3b7c8 IN 0.2 75280 496 automount
2415 1 0 e9a6818 IN 0.0 7200 44
/usr/sbin/sshd
2425 1 0 eea0a18 IN 0.5 94944 1396
/usr/bin/python -E /usr/sbin/setroubleshootd
2426 1 1 ede2340 IN 0.5 94944 1396
/usr/bin/python -E /usr/sbin/setroubleshootd
2427 1 0 ee06140 IN 0.0 64452 28 cupsd
2446 1 0 fa336c8 IN 0.2 10464 476 sendmail:
accepting connecti
2456 1 0 ee3b0f0 IN 0.2 9320 416 sendmail:
Queue runner@01:00:00 for /var/spo
2468 1 0 ee5f5c8 IN 0.1 58628 188 crond
2491 1 1 ef417c8 IN 0.0 4516 80 xfs
-droppriv -daemon
2513 1 0 e8fe340 IN 0.1 2548 200
/usr/sbin/atd
2525 1 1 e982340 IN 2.7 87636 7112
/usr/bin/python /usr/sbin/yum-updatesd
COMM will be with command line arguments.
Patch : (See attached file: crash-ps-f-opt.patch)
Regards
Hariharan T.S.
System Software Engineer,
zSeries - Red Hat Enterprise Linux,
India Software Lab - IBM Systems & Technology Group,
Embassy Golf Links Business Park, Bangalore, INDIA
Direct +91-80-4177-7545
e-mail: hariharan.ts(a)in.ibm.com
India Software Lab
6018
days inactive
6070
days old
devel@lists.crash-utility.osci.io
4 comments
3 participants
participants (3)
-
Dave Anderson -
Hariharan S Reddy -
Piet Delaney