[Crash-utility] [PATCH] add a new command: ipcs
Dave Anderson
anderson at redhat.com
Fri Apr 13 21:00:25 UTC 2012
----- Original Message -----
> Hello Dave,
>
> The patch has been changed into an extension module. And the option and
> its related output is changed as well. Please check.
>
Thanks for doing that, as it makes it easier to build/test/debug.
This version looks to cover earlier 2.6 kernels, at a minimum
all RHEL4 2.6.9-era kernels now work OK. Thanks for making that
work as well.
I should note that I only have one 2.6.5-era SLES9 dumpfile -- but it
may be a hybrid that is patched by another company, and it requires a
System.map file, so it may be suspect. Anyway, it fails the shared
memory display because the (first) shmid_kernel address contains
bogus data:
crash> ipcs -m
------ Shared Memory Segments ------
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
ipcs: invalid kernel virtual address: 400108010 type: "file.f_dentry"
crash>
The semaphore command shows suspect data as well:
crash> ipcs -s
------ Semaphore Arrays --------
SEM_ARRAY KEY SEMID UID PERMS NSEMS
10302b127a0 0x00000000 1 0 2 62388694941697
crash>
And the message queue seems to work, but it doesn't show "(none allocated)":
crash> ipcs -q
------ Message Queues --------
MSG_QUEUE KEY MSQID UID PERMS USED-BYTES MESSAGES
crash>
In any case, because it's a somewhat strange/modified SLES9 kernel, I don't
want to say that the command doesn't work with that kernel version. If
any SUSE kernel users on this list can verify it, that would be helpful.
(just go the top-level directory of any crash source tree, copy the ipcs.c
file into the extensions sub-directory, enter "make extensions".)
Anyway, here are my comments with this version.
The basic "ipcs" output looks pretty good -- except for:
(1) Please change the "SHM_KERNEL" header string to "SHMID_KERNEL" so
that it reflects the name of the actual kernel data structure, i.e.,
the same way that "MSG_QUEUE" and "SEM_ARRAY" reflect the kernel's
"msg_queue" and "sem_array" structure names.
(2) Please remove the "0x" from the KEY columns. Continue to display
the key value with a zero-filled 4-byte (integer) hexadecimal value,
which is enough to make it obvious that it's not decimal.
However, I really don't like the "-u" option, either used alone
or in conjunction with "-i". It's confusing, redundant, and in most
cases pretty much useless.
For example:
crash> ipcs -s
------ Semaphore Status --------
emaphore Arrays --------
SEM_ARRAY KEY SEMID UID PERMS NSEMS
1007bc33d90 0x11016565 0 0 644 2
1007bc33b90 0x71014002 32769 0 666 1
100f3348990 0xc9e03647 163842 0 644 3
crash> ipcs -su
------ Semaphore Status --------
used arrays = 3
allocated semaphores = 6
crash>
Is the "-u" option really even necessary for semaphores? I can
easily count the number of arrays and count the NSEMS column if
I actually wanted to know how many allocated semaphores there are.
But who cares?
The same thing applies to the message queues:
crash> ipcs -m
------ Message Queues --------
MSG_QUEUE KEY MSQID UID PERMS USED-BYTES MESSAGES
107f8ef72d0 0x23064010 0 0 600 0 0
107f80113d0 0x5106000d 32769 0 700 1068 1
105f0c43e90 0x000004d2 98306 0 666 0 0
crash> ipcs -mu
------ Messages Status --------
allocated queues = 3
used headers = 1
used space = 1068 bytes
crash>
I can see the USED-BYTES column, or add the USED-BYTES, and can
obviously see the number of queues. But who cares?
So I see nothing gained by implementing "-u" for message queues or
semaphores. And when combined with "-i id", they are even more
useless.
However, perhaps there may be some useful extra information
associated with shared memory:
crash> ipcs -m
------ Shared Memory Segments ------
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
10007b88d90 0x01000007 688128 0 600 512000 2
10007df89d0 0x00000000 360449 0 600 393216 2 dest
10007bad7d0 0x00000000 131074 0 600 393216 2 dest
10007b832d0 0x00000000 163843 0 600 393216 2 dest
1000f6b1dd0 0x00000000 196612 0 600 393216 2 dest
10007baca90 0x00000000 229381 0 600 393216 2 dest
10007b831d0 0x00000000 262150 0 600 393216 2 dest
10007b874d0 0x00000000 294919 0 600 393216 2 dest
10007ba8690 0x00000000 327688 0 600 393216 2 dest
10007df87d0 0x00000000 393225 0 600 393216 2 dest
10007bacc90 0x00000000 425994 0 600 393216 2 dest
10007dfc6d0 0x00000000 458763 0 600 393216 2 dest
1000fbfb9d0 0x00000000 491532 0 600 393216 2 dest
10007b88b90 0x00000000 524301 0 600 393216 2 dest
10007b84990 0xf900c00c 720910 0 600 189 1
crash> ipcs -mu
----- Shared Memroy Status --------
segments allocated 15
pages allocatd 1374
pages resident 1106
pages swapped 994
swap performance attemts 0
swap performance successes 0
crash>
But I note that you insist on dumping the shared memory inode
somewhere, but it certainly looks out of place here:
crash> ipcs -mi 688128
SHMID: 688128
------ Shared Memroy Status --------
segments allocated 15
pages allocatd 125
pages resident 13
pages swapped 35
swap performance attemts 0
swap performance successes 0
vfs_inode 0x10010029da0
crash>
But if you had taken my suggestion, and followed the tradition
of "kmem -s" and "kmem -S" or "kmem -f" and "kmem -F", you could
dump the statistics of each shared memory segment after the
one-liner, i.e., like this:
crash> ipcs -m
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
ffff810036f67490 0x00000000 65536 3369 600 393216 2 dest
ffff810036f67390 0x00000000 98305 3369 600 393216 2 dest
ffff810036f67690 0x00000000 131074 3369 600 393216 2 dest
ffff810036f67190 0x00000000 163843 3369 600 393216 2 dest
ffff8100329184d0 0x00000000 196612 3369 600 393216 2 dest
ffff81003f01d790 0x00000000 229381 3369 600 393216 2 dest
crash>
where -M would do the same thing, but separate and follow each one-liner
above with the statistics associated with it:
crash> ipcs -M
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
ffff810036f67490 0x00000000 65536 3369 600 393216 2 dest
(display segment statistics here)
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
ffff810036f67390 0x00000000 98305 3369 600 393216 2 dest
(display segment statistics here)
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
ffff810036f67690 0x00000000 131074 3369 600 393216 2 dest
(display segment statistics here)
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
ffff810036f67190 0x00000000 163843 3369 600 393216 2 dest
(display segment statistics here)
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
ffff8100329184d0 0x00000000 196612 3369 600 393216 2 dest
(display segment statistics here)
SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS
ffff81003f01d790 0x00000000 229381 3369 600 393216 2 dest
(display segment statistics here)
(display cumulative shared memory statistics here)
crash>
But as I mentioned before, it's hard to conceive of a compelling reason to
have an additional "ipcs -S" or "ipcs -Q" options.
So you could simplify the invocation to allow these options:
ipcs [-s | q | -[mM] ] [-i id | unique-address-of-first-column]
And if by chance the "id" value is used by more than one facility,
then you could dump them both.
Thanks,
Dave
More information about the Crash-utility
mailing list