ryran / xsos Goto Github PK

View Code? Open in Web Editor NEW

335.0 335.0 122.0 1002 KB

sosreport examiner - instantly summarize system info from a sosreport or a running system

Shell 100.00%

xsos's People

Contributors

Stargazers

Watchers

Forkers

ranjithruban wgd3 gangelop aftermath codificat alexandrujuncu wdv4758h mrcetinel ayerlock nixjobin msekletar mikedawg bossjones edsonlara wjkennedy sjanulonoks girishgk9 ptalbert kissingwolf ygemici zenteric bjmingyang isnuryusuf ptyagii fredide bryanquigley antopj superjamie schabrolles awmyhr chenlizhong akurach irule dosaboy rjhowe 831jsh tool-who-must-not-be-named oritwas adisheshsm markstinson snobalfyte rsable simonflower vbendel csyfek johanburati klaas- waldirio darthmoul18 wedgetaileagle uyefe chaerin16 sonaarora m4d3bug pjhwa harpsichord pornchaitaw kyle-walker 4n3i5v74 ilushechkin rhn-jaeshin code-with-amitk rhdojun dotyjim-work sivanamurugesan rht-tasinha ltgrp oops1st clebertsuconic rommy-prawirasatya mhanief juanmasg qerosi tmichett bharathrajb superrrpear guruonlinea vivekyoganand jaskarannarula lewisdenny angpa claf rfc1459 dpinyol cheetahbf tarikkilic norlan86 ghkibria mmorency2021 sssyam romesh92 nanox mengling2012 kokoriyadi juliobarreto melghub chazzrobbz wiyin dmitrii-git mlolenga2

xsos's Issues

xsos --lspci showing extra blank line

Odd extra blank line showed up with v0.0.8b. Blank line wasn't there in earlier versions.

LSPCI
  Net:
    1 Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)

  VGA:
    VMware SVGA II Adapter

running xsos --os on a sosreport doesn't show hostname or kernel version

Seen on a sosreport:

OS
/usr/local/bin/xsos: line 526: ./proc/sys/kernel/hostname: No such file or directory
  Hostname:  
  Distro:    Red Hat Enterprise Linux Server release 5.6 (Tikanga)
/usr/local/bin/xsos: line 528: ./proc/sys/kernel/osrelease: No such file or directory
  Kernel:    
  SELinux:   status unknown (default: unknown)
  Sys time:  Tue Oct 23 16:54:46 EDT 2012
  Boot time: Mon Oct 22 18:01:27 EDT 2012 (1350928887)
  Uptime:    1 day,  2:53,  6 users
  LoadAvg:   0.16 (0%), 0.03 (0%), 0.01 (0%)
  Cpu time since boot:
    us 0%, ni 0%, sys 0%, idle 100%, iowait 0%, irq 0%, sftirq 0%, steal 0%
  procs_running (procs_blocked):
    2 (0)
  Kernel taint-check: 64 16 2 1 
    Userspace-defined naughtiness
    System experienced a machine check exception
    Module has been forcibly loaded
    Proprietary module has been loaded
  Kernel cmdline:
    ro root=/dev/rootvg/rootvol crashkernel=128M@16M
  Kernel version/build:
    Linux version 2.6.18-238.12.1.el5 ([email protected]) 
    (gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)) #1 SMP Sat May 7 20:18:50 
    EDT 2011
-------------------------------------------------------------------------------

Need moar configurable settings

How about some environment variables, i.e. variables for:

width for all content modules
changing the default header colors
changing the default view
disabling color by default
setting --mb/--kb by default
changing the default content separator

This will make it so that people that want to customize the default behavior don't have to use aliases (or worse) edit the code and can more easily take advantage of new updates.

RFE: Have OS detect stuff on grub2 systems

$ xsos -o | egrep -iA1 'distro|grub'
  Distro:    Fedora release 17 (Beefy Miracle)
  Kernel:    3.6.6-1.fc17.x86_64
--
  GRUB default kernel line:
    Unable to detect

sos sestatus file can contain "/bin/sh: /usr/sbin/sestatus: No such file or directory"

Need to make a quick fix to SELinux detection to accommodate this. At the moment, it causes:

SELinux:    (default: )

rsar RFE: add -m option for sar's power management stats

Yes.

Possible RFE: a module for /proc/slabinfo?

If there's demand. Speak up -- what would you like to see?

ps top users of CPU & MEM rss broken since adding XSOS_PS_UNIT

Tis true.

Intel Xeon E7-8837 reported improperly by --cpu?

Found something crazy in a sosreport. 640 logical CPUs.

DMIDECODE
  BIOS:
    SGI.COM, version 2.12 UEFI2.10 PI1.0 X64, 2011-10-04
  System:
    Mfr:  Intel Corp.
    Prod: Stoutland Platform
    Vers: 1.0
    Ser:  Unknown
    UUID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  CPU:
    8 of 8 CPU sockets populated, 0 cores/0 threads per CPU
    0 total cores, 0 total threads
    Mfr:  Intel(R) Corporation
    Fam:  Pentium 4
    Freq: 2667 MHz
    Vers: Intel(R) Xeon(R) CPU E7- 8837 @ 2.67GHz
  Memory:
    0 MB (0 GB) total
    0 of 0 DIMMs populated (system max capacity 1024 GB)

CPU
  640 logical processors (640 CPU cores)
  80 Intel Xeon CPU E7- 8837 @ 2.67GHz (flags: constant_tsc,ht,lm,pae,vmx) 
  └─8 threads / 8 cores each

MEMORY
  RAM:
    5048.7g total [305.5g (6%) used]
    298.2g (6%) used excluding buffers/cache
    0.88g (0%) dirty
  HugePages:
    ZERO ram pre-allocated to HugePages
  LowMem/Slab/PageTables/Shmem:
    2.73g (0%) of total ram used for Slab
    0.73g (0%) of total ram used for PageTables
    0.06g (0%) of total ram used for Shmem
  Swap:
    0.0g (0%) used of 8.0g total

Insaaaaane.

Here's the first and last "processors" from /proc/cpuinfo:

processor       : 0                                                                                        
vendor_id       : GenuineIntel
cpu family      : 6
model           : 47
model name      : Intel(R) Xeon(R) CPU E7- 8837  @ 2.67GHz
stepping        : 2
cpu MHz         : 2666.847
cache size      : 24576 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt lahf_lm ida arat epb dts tpr_shadow vnmi flexpriority ept vpid
bogomips        : 5333.69
clflush size    : 64
cache_alignment : 64
address sizes   : 44 bits physical, 48 bits virtual
power management:

processor       : 639
vendor_id       : GenuineIntel
cpu family      : 6
model           : 47
model name      : Intel(R) Xeon(R) CPU E7- 8837  @ 2.67GHz
stepping        : 2
cpu MHz         : 2666.847
cache size      : 24576 KB
physical id     : 79
siblings        : 8
core id         : 25
cpu cores       : 8
apicid          : 5106
initial apicid  : 114
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt lahf_lm ida arat epb dts tpr_shadow vnmi flexpriority ept vpid
bogomips        : 5334.24
clflush size    : 64
cache_alignment : 64
address sizes   : 44 bits physical, 48 bits virtual
power management:

How to tell what architecture a system is?

In Fedora the kernel version has the architecture (e.g. x86_64) in it, but not so in earlier versions of RHEL. Why can't xsos tell us this?

RFE: Add option to make osinfo less RHEL-centric and less focused on support issues

Basically, this means adding an environment variable and possibly an easy-access cmdline toggle to switch between rhel-centric support-concerns and normal linux mode. This will only affect the osinfo output.

When in rhel-centric mode:

Special treatment for /etc/redhat-release
- It's always shown, regardless of whether the file is there (glaring (missing) tag)
- Special colorization for oddities in redhat-release
RHN field always shown, with special colorization for a few oddities
Colorization for kernel build version not being from a RHT build-server
Some checks for RHEL-hybrids are automatically run -- i.e., to see if system has suse, oracle, centos packages installed

When in general linux mode, none of the above happens. Simple enough.

--disks option not properly-handling mutlipath output on rhel6.3?

Turns out that xsos doesn't handle multipath command output from rhel6. Whoops. Hadn't noticed. Thanks so much to Mr. Markovic for pointing it out!!

After he brought it to my attention, this is what I noticed..

xsos could parse multipath from rhel5 just fine, at least when there were friendly names, e.g. this:

mpath9 (00000000000000000blahblahblah00000000) dm-11 IBM,2145
[size=50G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=50][active]
 \_ 3:0:6:1 sdy 65:128 [active][ready]
\_ round-robin 0 [prio=20][enabled]
 \_ 3:0:4:1 sdq 65:0   [active][ready]
 \_ 3:0:5:1 sdu 65:64  [active][ready]

And there were a few allowances in there for the differences with rhel4 as well.

However, rhel6 output like this was not taken into account:

123456787012812blahblahblah dm-2 NETAPP,LUN
size=250G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=4 status=active
| |- 4:0:0:2 sdc 8:32  active ready running
| |- 4:0:2:2 sdg 8:96  active ready running
| |- 5:0:0:2 sdk 8:160 active ready running
| `- 5:0:3:2 sdq 65:0  active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  |- 4:0:3:2 sdi 8:128 active ready running
  |- 4:0:1:2 sde 8:64  active ready running
  |- 5:0:1:2 sdm 8:192 active ready running
  `- 5:0:2:2 sdo 8:224 active ready running

RFE: Add asci-art/graph for meminfo-display

Skywalker suggested this and now I can't get it out of my head. Ahhhhh.

I suspect I will make it just be one horizontal bar where the total represents total memory and the break-downs are: hugepages, buffers&cache, and completely free mem.

Not using the -x or --nocolor options, but there's still no color

As above ^^ ... using xsos on RHEL 5 and not seeing any of the colors seen in RHEL 6.

RFE: Why not also check rhn serverURL?

Good question. Not sure why I never bothered to add it sooner.

RFE: make --ps pay any attention to --unit

xsos --ps doesn't currently do anything to VSZ or RSS

I'll see about adding a new env var for ps, e.g. XSOS_PS_UNIT and prolly setting it to MiB by default.

rescue mode is not taken into account

The xsos --os output looks for kernel args in /proc/cmdline and so if you gather a sosreport from rescue, well... the kernel args reflect rescue, not the kernel args as they'd be if the system booted up. grub.conf should be checked.

The same goes for the selinux check.

Even more worrisome is that xsos doesn't grab the proper hostname -- perhaps it could grab the hostname from the sosreport's /etc/sysconfig/network file?

There should at least be a warning that the sosreport was run from rescue mode.

Possible RFE: Log file examination?

Another one of my plans: begin building a database of error messages to search for in log files. Might end up being a separate tool though. Speak up if you've got suggestions.

What about interface macaddrs, ipaddr/nm, etc?

Sure. Totally plan to do that.

RFE: Add bash completion file for xsos

Haven't had the time to even look into it, but totally is near the top of my todo for xsos.

Possible RFE: More detailed bonding information?

Like parsing of /proc/net/bonding/*

Possible RFE: RPM version inspection a la checksysreport?

Unlikely. More likely that would be a completely separate tool. Will make a definitive declaration eventually. Stay tuned.

--disks doesn't take into account EMC/Veritas/Hitachi multipath

Yep. That's true.

Let's say you have 65 scsi disks (i.e. /dev/sdaf) on your system -- 64 of which are multipathed devices ...

If the Linux native multipathd is managing all those, xsos will be able to detect the mpath devices (and display info on them) and will hide all the child paths (i.e. the scsi disk paths) from the regular disk printout, leaving the regular disk printout to only show the one local scsi disk.

On the other hand, if all those multipathed disks are provided by some other multipath service like EMC's powerpath, xsos --disks isn't going to know anything about them and the regular disk printout is going to show 65 scsi disks.

I'd obviously like to do something about this but haven't started digging around in any emc/veritas/hdlm sosreports.

RFE: Add --S option to make it possible to read in `sysctl -a` dumps

Should be very easy to do, after the awesome changes made in v0.1.1beta.

CPU info detection doesn't report cores for some multi-core cpus

Various multicore cpus aren't detected properly by xsos!
xsos --cpu or xsos --C shows the proper number of logical cpus, but shows no information about cores or threads like it does with other cpus!?!? OMG WTF BBQ!!?!?!?!!

$ xsos -C cpuinfo
CPU
  6 logical processors
  1 Six-Core AMD Opteron(tm) Processor 8435 (flags: lm,pae)
-------------------------------------------------------------------------------

$ cat cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5252.41
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5203.20
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 2
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5203.98
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 3
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5204.36
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 4
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5202.95
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 5
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5202.73
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

Here's another EXAMPLE!@^%$(()!!!!!

$ xsos --C cpuinfo
CPU
  2 logical processors
  1 Dual-Core AMD Opteron(tm) Processor 8218 (flags: lm,pae)
-------------------------------------------------------------------------------

$ cat cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model       : 65
model name  : Dual-Core AMD Opteron(tm) Processor 8218
stepping    : 2
cpu MHz     : 2612.037
cache size  : 1024 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 1
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm extapic
bogomips    : 5224.07
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 15
model       : 65
model name  : Dual-Core AMD Opteron(tm) Processor 8218
stepping    : 2
cpu MHz     : 2612.037
cache size  : 1024 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 1
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm extapic
bogomips    : 5224.07
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

RFE: short way to tell --width not to wrap at all

i.e. something shorter than typing -w999999999

Yes. I agree with myself. Will do.

rsar RFE / BUG: -n opt only shows dev; what about sock, nfs, nfsd, etc?

Sar has multiple options for -n ... we need to take that into account.

-n { <keyword> [,...] | ALL }
    Network statistics
    Keywords are:
    DEV Network interfaces
    EDEV    Network interfaces (errors)
    NFS NFS client
    NFSD    NFS server
    SOCK    Sockets (v4)
    IP  IP traffic  (v4)
    EIP IP traffic  (v4) (errors)
    ICMP    ICMP traffic    (v4)
    EICMP   ICMP traffic    (v4) (errors)
    TCP TCP traffic (v4)
    ETCP    TCP traffic (v4) (errors)
    UDP UDP traffic (v4)
    SOCK6   Sockets (v6)
    IP6 IP traffic  (v6)
    EIP6    IP traffic  (v6) (errors)
    ICMP6   ICMP traffic    (v6)
    EICMP6  ICMP traffic    (v6) (errors)
    UDP6    UDP traffic (v6)

rsar RFE: add -S and -H for swap and hugepages

Yep.

rsar bug: rsar chokes on sar data with AM/PM

rsar works great when the input data is in 24-hour time format, but what about when it's not?

rsar: -P ALL doesn't work

Self-explanatory.

xsos --ip doesn't handle new-style multiple addrs per interface

Tis true.

Until today it never occurred to me to add support for multiple non-aliased addresses on an interface. Working on it.

WTFBBQ-BUG: ps function completely ignoring certain processes

By far the biggest and most embarrassing bug I've ever had in xsos....

lspci reports 1 nic, but 3 nics available when looking at ip addr, ethtool

Output from xsos -lei:

LSPCI
  Net:
    1 Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
  VGA:
    XGI Technology Inc. (eXtreme Graphics Innovation) Z7/Z9 (XG20 core)
-------------------------------------------------------------------------------
ETHTOOL
  eth0  link=UP 1000Mb/s full (autoneg=Y)  drv forcedeth v0.64
  eth1  link=DOWN                          drv forcedeth v0.64
  eth2  link=DOWN                          drv e1000 v7.3.21-k6-1-NAPI / fw N/A
-------------------------------------------------------------------------------
IP
  Interface  Slave Of  MAC Address        State  IPv4 Address
  =========  ========  =================  =====  ==================
  lo         -         -                  up     127.0.0.1/8
  eth0       -         00:e0:81:b1:a7:6f  up     128.231.13.176/23
  eth1       -         00:e0:81:b1:a7:70  up     -
  eth2       -         00:e0:81:b1:a7:71  up     -
-------------------------------------------------------------------------------

WTH?

Possible RFE: what about lvm & dm-crypt? what about filesystem level?

"The output from xsos -p is pretty useless. Is that all the love you've got for storage?"

I'm open to ideas on what info to present. It's so easy to look at /etc/fstab, /etc/crypttab, and use thelvm tools .. I'm not really sure what to do.

I might make use of the lsblk command but it's only in rhel6 and above. Not sure what to do with it other than print it out straight. Suggestions welcome.

--cpu/-c/--C reporting improper number physical cpus for some multicore procs that don't report "core id" or "cpu cores"

$ xsos --C cpuinfo
CPU
  6 logical processors
  6 Six-Core AMD Opteron(tm) Processor 8435 (flags: lm,pae)
-------------------------------------------------------------------------------
$ cat cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5252.41
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5203.20
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 2
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5203.98
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 3
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5204.36
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 4
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5202.95
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

processor   : 5
vendor_id   : AuthenticAMD
cpu family  : 16
model       : 8
model name  : Six-Core AMD Opteron(tm) Processor 8435
stepping    : 0
cpu MHz     : 2599.942
cache size  : 512 KB
fpu     : yes
fpu_exception   : yes
cpuid level : 5
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 popcnt lahf_lm extapic altmovcr8 abm sse4a misalignsse
bogomips    : 5202.73
TLB size    : 1104 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: <NULL>

rsar RFE: add -I option (for interrupts)

Subject says it all.

sys time & boot time are formatted differently depending whether reading sosreport or localhost

This will be trivial to fix. Just putting a note here so that I can remember to fix it when I'm not at work.

Needfix on localhost-run:

timezone isn't highlighted
day of month isn't right-aligned

rsar: File-handling is crappy (slow, can't always open compressed files, errors out if any 1 of multiple files are bad or missing)

Problems we need to fix:

Why is rsar slow to get started? Not crazy slow, but it takes a split second before it starts displaying things, especially when tons of files are passed all at once.
Sometimes rsar can't read compressed files -- errors out with something about "ASCII text, with very long lines".
When passing rsar multiple files, every single one must be good or else rsar fails out.

Disk code should make use of /proc/scsi/scsi for something cool

Not doing anything at all with it yet and don't have any ideas. Seems pretty useless since sosreports don't also capture data from /sys. Honestly I think it's crazy that lsscsi isn't on every linux system by default. If that was included in sosreports it'd be great.

If you have ideas what to do with /proc/scsi/scsi, considering that we don't have info from /sys ... well, speak up.

RFE: Improve SELinux detection in sosreports by looking at dmesg

Currently, xsos --os tries to detect the current enforcing mode as well as what the config-default mode is.

With sosreports, this checks for the output of sestatus as well as from /etc/selinux/config. Often this file is missing in sosreports, and instead we have a dangling symlink in /etc/sysconfig/selinux. In these cases, /proc/cmdline is checked to see if selinux was disabled/set permissive/enforcing via a kernel arg.

Failing all that, a line like this is printed:

  SELinux:   status unknown  (default unknown)

One more place to check: dmesg.

$ ll etc/sysconfig/selinux etc/selinux/config
ls: cannot access etc/selinux/config: No such file or directory
lrwxrwxrwx. 1 rsaw rsaw 17 Dec  7 18:06 etc/sysconfig/selinux -> ../selinux/config
$ egrep -i 'selinux=.|enforcing=.' proc/cmdline || echo oh noes
oh noes
$ grep -i selinux var/log/dmesg 
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
SELinux:  Registering netfilter hooks
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
type=1404 audit(1338760191.781:2): selinux=0 auid=4294967295 ses=4294967295

Boom. Easy fix.

rsar Possible RFE: built-in updating?

Of course it would be trivial to add this. I might do it.

Running xsos results in "declare: -A: invalid option" error

Running xsos permanently changes the terminal font color to cyan. It also causes the errors mentioned in subject.

[root@58n ~]# ./xsos -o
./xs: line 38: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
./xs: line 196: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
OS
  Hostname:  58n
  Distro:    Red Hat Enterprise Linux Server release 5.8 (Tikanga)
  Kernel:    2.6.18-308.16.1.el5
  Runlevel:  N 5 (default: 5)
  SELinux:   enforcing (default: enforcing)
  Sys time:  Tue Oct 23 21:15:45 EDT 2012
  Boot time: Fri Oct 19 11:09:21 EDT 2012 (1350659361)
  Uptime:    4 days, 10:06,  3 users
  LoadAvg:   0.00 (0%), 0.00 (0%), 0.00 (0%)
  Cpu time since boot:
    us 0%, ni 0%, sys 0%, idle 100%, iowait 0%, irq 0%, sftirq 0%, steal 0%
  procs_running (procs_blocked):
    2 (0)
  Kernel taint-check: 0 (kernel untainted)
  Kernel cmdline:
    ro root=/dev/VolGroup00/LogVol00 enforcing=1
  Kernel build from dmesg:
    Linux version 2.6.18-308.16.1.el5 ([email protected]) 
    (gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)) #1 SMP Tue Sep 18 07:21:07 
    EDT 2012
-------------------------------------------------------------------------------

Furthermore, running xsos with one of the special options (like --C) causes another error (\033[1;36m: syntax error: operand expected (error token is "\033[1;36m")) and does not print the output expected.

[root@58n ~]# ./xs --C /proc/cpuinfo
./xs: line 38: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
./xs: line 196: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
./xs: line 219: \033[1;36m: syntax error: operand expected (error token is "\033[1;36m")
OS
  Hostname:  58n
  Distro:    Red Hat Enterprise Linux Server release 5.8 (Tikanga)
  Kernel:    2.6.18-308.16.1.el5
  Runlevel:  N 5 (default: 5)
  SELinux:   enforcing (default: enforcing)
  Sys time:  Tue Oct 23 21:16:03 EDT 2012
  Boot time: Fri Oct 19 11:09:21 EDT 2012 (1350659361)
  Uptime:    4 days, 10:06,  3 users
  LoadAvg:   0.00 (0%), 0.00 (0%), 0.00 (0%)
  Cpu time since boot:
    us 0%, ni 0%, sys 0%, idle 100%, iowait 0%, irq 0%, sftirq 0%, steal 0%
  procs_running (procs_blocked):
    2 (0)
  Kernel taint-check: 0 (kernel untainted)
  Kernel cmdline:
    ro root=/dev/VolGroup00/LogVol00 enforcing=1
  Kernel build from dmesg:
    Linux version 2.6.18-308.16.1.el5 ([email protected]) 
    (gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)) #1 SMP Tue Sep 18 07:21:07 
    EDT 2012
-------------------------------------------------------------------------------
CPU
  1 logical processors 
  QEMU Virtual CPU version (cpu64-rhel6) (flags: lm,pae) 
-------------------------------------------------------------------------------
MEMORY
  RAM:
    0.5g total [0.4g (87%) used]
    0.2g (37%) used excluding buffers/cache
    0.00g (0%) dirty
  HugePages:
    ZERO ram pre-allocated to HugePages
  LowMem/Slab/PageTables/Shmem:
    0.4g (87%) of 0.5g LowMem in-use
    0.04g (9%) of total ram used for Slab
    0.01g (1%) of total ram used for PageTables
  Swap:
    0.0g (0%) used of 2.5g total
-------------------------------------------------------------------------------

Possible RFE: sar data analysis?

What about some basic sar analysis?

Why don't some sosreports/sysreports from <rhel5 don't show ipaddr information?

Some rhel4 systems have ifconfig output in their sosreports but xsos --ip doesn't work. Why?

--cpu/-c/--C reporting improper number of cores

$ x --C cpuinfo 
CPU
  64 logical cpus (ht,lm,pae,vmx)
  8 Intel Xeon CPU E7- 2830 @ 2.13GHz, 10 cores/ea
$ grep cpu.cores cpuinfo | sort -u
cpu cores   : 8
$ grep core.id cpuinfo | sort | uniq -c
      5 core id     : 0
      8 core id     : 1
      7 core id     : 2
      6 core id     : 3
      6 core id     : 4
      6 core id     : 5
      6 core id     : 6
      7 core id     : 7
      8 core id     : 8
      5 core id     : 9

Why a new tool? Why not add new functionality to sxconsole?

This is a common question when people first hear about xsos -- at least for people that work at Red Hat like I do.

Running xsos --ip on a rhel5 system doesn't work

The following is seen when trying to run xsos on a rhel5 system.

$ ./xs -i
./xs: line 38: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
./xs: line 196: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
./xs: line 987: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
IP
  Interface  Slave Of  MAC Address        State  IPv4 Address
  =========  ========  =================  =====  ==================
  lo         -         -                  up     127.0.0.1/8
  eth0       -         52:54:00:28:57:9b  up     10.12.55.209/22
-------------------------------------------------------------------------------

After upgrading to the latest version, the following is seen:

$ ./xsos --ip
The -i/--ip option requires use of BASH associative arrays
i.e., BASH v4.0 or higher (RHEL6/Fedora11 and above)
-------------------------------------------------------------------------------

What gives?

ability to inspect ps output top/blocked processes

^^subject

--cpu doesn't show thread info for some single-core hyper-threaded cpus

When single-core CPUs have hyper-threading enabled, xsos doesn't break down the thread and core count, unlike with multi-core cpus.

Example of a multicore cpu with hyper-threading:

CPU
  16 logical processors (8 CPU cores)
  2 Intel Xeon CPU E5620 @ 2.40GHz (flags: aes,ht,lm,pae,vmx)
  └─8 threads, 4 cores each
-------------------------------------------------------------------------------

Example of a single-core cpu with ht:

$ xsos --C 13815423
CPU
  4 logical processors
  2 Intel Xeon CPU 3.20GHz (flags: ht,pae)
-------------------------------------------------------------------------------
$ grep physical 13815423
physical id : 0
physical id : 0
physical id : 3
physical id : 3
$ grep core 13815423
$ grep siblings 13815423
siblings    : 2
siblings    : 2
siblings    : 2
siblings    : 2
$ cat 13815423
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model       : 2
model name  : Intel(R) Xeon(TM) CPU 3.20GHz
stepping    : 5
cpu MHz     : 3193.089
cache size  : 512 KB
physical id : 0
siblings    : 2
runqueue    : 0
fdiv_bug    : no
hlt_bug     : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 2
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips    : 6370.09

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 15
model       : 2
model name  : Intel(R) Xeon(TM) CPU 3.20GHz
stepping    : 5
cpu MHz     : 3193.089
cache size  : 512 KB
physical id : 0
siblings    : 2
runqueue    : 0
fdiv_bug    : no
hlt_bug     : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 2
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips    : 6383.20

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 15
model       : 2
model name  : Intel(R) Xeon(TM) CPU 3.20GHz
stepping    : 5
cpu MHz     : 3193.089
cache size  : 512 KB
physical id : 3
siblings    : 2
runqueue    : 2
fdiv_bug    : no
hlt_bug     : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 2
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips    : 6383.20

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 15
model       : 2
model name  : Intel(R) Xeon(TM) CPU 3.20GHz
stepping    : 5
cpu MHz     : 3193.089
cache size  : 512 KB
physical id : 3
siblings    : 2
runqueue    : 2
fdiv_bug    : no
hlt_bug     : no
f00f_bug    : no
coma_bug    : no
fpu     : yes
fpu_exception   : yes
cpuid level : 2
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips    : 6383.20

Readme/wiki with screenshots & usage

Yep. That would be a good idea.