lsb_release -a // ubutu version
From anywhere in the desktop - Cntl + Alt +T to get a terminal.
lspci //pci devices
# display information about the processor/cpu $ sudo dmidecode -t processor # memory/ram information $ sudo dmidecode -t memory # bios details $ sudo dmidecode -t bios
sudo fdisk -l
# cpu information $ cat /proc/cpuinfo # memory information $ cat /proc/meminfo
$ cat /proc/partitions major minor #blocks name 8 0 488386584 sda 8 1 73400953 sda1 8 2 1 sda2 8 5 102406311 sda5 8 6 102406311 sda6 8 7 1998848 sda7 8 8 208171008 sda8 11 0 1048575 sr0ps commands --$ sudo hdparm -i /dev/sda
Use the "u" option or "-f" option to display detailed information about the processes
ps -ef -f
To filter the processes by the owning user use the "-u" option followed by the username.
Multiple usernames can be provided separated by a comma.
$ ps -f -u www-data
To search the processes by their name or command use the "-C" option followed by the search term.
ps -C apache2To display processes by process id, use the "-p" option and provides the process ids separated by comma.$ ps -f -p 3150,7298,6544
Sort process by cpu or memory usage$ ps aux --sort=-pcpu,+pmem
Display the top 5 processes consuming most of the cpu.
$ ps aux --sort=-pcpu | head -5
Display process hierarchy in a tree style
$ ps -f --forest -C apache2
Display child processes of a parent process$ ps -o pid,uname,comm -C apache2
Display threads of a process$ ps -p 3150 -LChange the columns to displayps -e -o pid,uname,pcpu,pmem,comm$ ps -e -o pid,uname=USERNAME,pcpu=CPU_USAGE,pmem,comm
Display elapsed time of processes$ ps -e -o pid,comm,etime
Turn ps into an realtime process viewerwatch -n 1 'ps -e -o pid,uname,cmd,pmem,pcpu --sort=-pmem,-pcpu | head -15'
Being trained in Graph Algorithms, Netwrork optimizations, stochastic calculas including queuing theories, I've been drifting around networking area for almost all my working years. But my own networking ability is immensly poor !
Just about 25 yrs ago, I was dealing with general network design/model to charactrise different metrics to measure certain known user perceptible networking traits. As a result, we were even able to produce some nice parametric results that showed up in conference papers. In particular, back then the micro controller based memory was quite expensive, and a mega bytes costed bit of extra money. So we had to model to comeup with estimated range of memory needed for network components thruout a network.
Without getting into details, we already had a sliding window protocol in place for receiver to advertise what it is capable to take within then next epoch. And sender will adjust itself based on the receiver's indication to sender. At that time I used to talk about how we could make Etiquette being a protocol. Hence the name of this post.
But the wave of high-tech revolutions took me off the track quite a few times, as well as perhaps lack of imagination. By the time we were done, only few companies were actively involved dealing with networking protocols, where as lot of companies were interested in platform areas. So it was hard, if not possible to convince that some of the protocols does not have to be the way it is. The perception was that few companies tried their own protocols but tcp/ip prevailed, so why bother ?
Good question, right? Way too many times we hard the mouthful direction - Don't reinvent the wheel. Even a damn illiterate people would advice you the same !
Now proliferation of IoTs and mobile everywhere things are changing. Once again, lot of bright people thinking and tearing apart our beloved tcp/ip protocol stack to comeup with need based design and implementations. What it means to me ?
Trying to find a wonder drug, so that I can retrieve all the lost temoral-memories! But the good sign is that people are now realizing that a protocol designed in late 1970s was good enough then but now we need to deal with present state of affairs.
Happy to see the movements. Will detail later on couple more posts.
Yeah make Etiquette to Protocol!
Once you setup your remote debugging environment, it is your hard work ( always) to figure out how you debug, when you debug. Assuming that you that you are somewhat familiar with kernel debugging, which includes debugging core operating systems, boot code, code related to device or other system resource frameworks, you would be looking at some basic commands that would work reliably, for example -
*) Breaking into debugger, mapping symbols, looking at sources etc.
*) Run the kernel under your debugger, and probe, steps thru the code etc.
*) Manage your debugger interface like: display feature(s), history, several windows for registers, stacks, memory etc.
OSX started out with GDB debugger, and moved to LLDB. LLDB maps some of the GDB commands (if not all, but I don't know yet), but it is quite verbose to type most of the commands. I read it as Long Long Debugger.
GDB as such is quite old and popular, but when it comes to kernel debugging there are many local shop to shop customized gdb. But one general one is kgdb. It is not a true sense kernel debugger, though.
So what is a true kernel debugger?
A true kernel debugger is one which freez the time when you broke into debugger. So if you leave your debug envrionment overnight, you must see old time, date. Lot of kernel debugger in the open source are really not there. Hence, it is quite difficult to debug some of the hard problems like once in a blue-moon race etc.
Windows kernel debugger outshine in this case. Before it windows softIce was another one. But in GNU open source environment, I'm yet to see a "True kernel debugger".
Last time we talked about how to get a kernel debug session between a natively running debugger machine (a.k.a. Host), and a OSX VM running under VMware Fusion. It was fun, right?
In fact, the fun part(s) is(are) yet to come!. First, my immidiate task is to get a XNU kernel built in a VM, and replace the off the shelf kernel ( named mach_kernel or kernel or kernel.debug ...). Then get a kernel debugging going between that VM and the Host. Building the kernel is fine. I can built the XNU package for 10.10 and 10.9 but running with or without kernel debug configuration is where I'm really challenged. With the same steps, as discussed in part I, I landed on Kernel waiting for Debugger connection, but the ip address as well as the mac address are all 0s with respective format. Clearly there is some problem!
On the otherhand, if I try to run the newly built kernel without debugger configuration, it hangs. And it does not matter if it is RELEASE or DEBUG built. Here comes the KDP, kernel debugging protocol. FreeBSD has basically the same idea. This protocol is based on TTCP over UDP. As far as I know this is not self contained when it comes to configuration side of the interfaces. This is Bridged interface of VMware virtualization feature. This I will tackle later. But what is really the problem ? AFAIK, KDP part initialized few ip related stuff to 0s, and there are outer layers that does not come with XNU source ( but some are in opensource.apple.com ) that keeps configurations in tact when it comes to full OSX buit.
One thing I did not mention in part I is that we need to map the syms and src when we need to debug kext. This is like external driver programming. For that, first thing to find out is what version of OSX you are running. It can be found from Apple icon. Also from tty, uname -a will give you bit more information. Once you know what version you are running, go to Apple site, and download respective "Kernel Debugging Kit" onto your Host. In most versions of Kernel Debugging Kits, installing the dmg file is nothing but mounting the package. Once mounted, you will see Readme xml file. That has information about how to invoke LLDB, and thats it. You have symbolic debugging. Just start the VM with kernel debugging configured as explained in part I, and invoke LLDB, and play with the instructions given in the Readme xml file.
Note that using Kernel Debugging Kit implies, you are still using off the shelf XNU kernel that comes with the OS image. This is a complete build of Mac OSX,not just the XNU kernel code.
Next, we will get to bit more deeper side of Kernel hacking. For now Happy hacking !