Today's mindupload will be a citation because I don't think I'd be able to write up a better explanation on CPU load average than this guy, check it out: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
The wikipedia entry is pretty good too.
Tuesday, August 10, 2010
Monday, August 9, 2010
MindUpload: kill command
If you've used a Unix or Unix-like operating system, you've probably heard of (even used) the kill command.
The kill command is basically a cli interface to the kill() system call, and it basically sends a signal to a running process. The types of signals are defined on the signal header file (signal.h) under the linux operating system (in Fedora I found it under /usr/include/asm/signal.h instead of /usr/include/linux/signal.h as part of the kernel-headers RPM) or you can list them by running kill -l.
Since I can remember using Linux, I've used the kill command in 3 different ways:
kill SOME_PID
SIGTERM is the default signal if you don't pass the signal number to the command, it will send signal 15, which requests the process to terminate, if the process doesn't terminate, than we usually have to force it with:
kill -9 SOME_PID
The above sends the SIGKILL signal that forces the application to terminate right now.
kill -1 SOME_PID
The -1, aka SIGHUP, is a signal sent to an application when a terminal closes, but if the application does "not require a controlling terminal, such as daemons, would re-purpose SIGHUP as a signal to re-read configuration files, or reinitialize. This convention survives to this day in packages such as Apache and Sendmail." Source: http://en.wikipedia.org/wiki/SIGHUP -- Being that reloading config files was the main reason I've used -1 for.
The interesting part about all this is that one can write an application to intercept theses signals from the kill command when sent to it and do different things with it other than actually 'killing' the process. The only 2 signals that cannot be intercepted are: SIGTERM (15) and SIGKILL (9).
The kill command is basically a cli interface to the kill() system call, and it basically sends a signal to a running process. The types of signals are defined on the signal header file (signal.h) under the linux operating system (in Fedora I found it under /usr/include/asm/signal.h instead of /usr/include/linux/signal.h as part of the kernel-headers RPM) or you can list them by running kill -l.
[ansilva@carioca ~]$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
...
Since I can remember using Linux, I've used the kill command in 3 different ways:
kill SOME_PID
SIGTERM is the default signal if you don't pass the signal number to the command, it will send signal 15, which requests the process to terminate, if the process doesn't terminate, than we usually have to force it with:
kill -9 SOME_PID
The above sends the SIGKILL signal that forces the application to terminate right now.
kill -1 SOME_PID
The -1, aka SIGHUP, is a signal sent to an application when a terminal closes, but if the application does "not require a controlling terminal, such as daemons, would re-purpose SIGHUP as a signal to re-read configuration files, or reinitialize. This convention survives to this day in packages such as Apache and Sendmail." Source: http://en.wikipedia.org/wiki/SIGHUP -- Being that reloading config files was the main reason I've used -1 for.
The interesting part about all this is that one can write an application to intercept theses signals from the kill command when sent to it and do different things with it other than actually 'killing' the process. The only 2 signals that cannot be intercepted are: SIGTERM (15) and SIGKILL (9).
Labels:
kill,
linux,
mindupload
Sunday, August 8, 2010
MindUpload: Hubs vs Switches
Yes... embarrassing. Hubs and Switches. Someone asked me what the difference was between the two network devices, and the only thing that went through my mind was: "A dumb device." The second thought was: "Don't ask me, just Google for it..."
That's when it hit me: Yes, using Google to look up information is great, but should I be so dependent on it that I am unable to answer such a basic networking question?"
And that is why I decided to start writing 'mindupload' notes to myself... So, here's what I learned (re-learned, actually, since I learned this in College, and eventually forgot).
A hub takes data (aka packets) arriving at the incoming port, and transmits it to all outgoing ports with a connected device to it. If more than one computer receives the data and try to respond, it could generate network collisions because they are responding to the same data at the same time, this could slow down your network due to processing of the collision and re-transmission of the data. Related to this same issue, the network devices connected to the hub will be running in half-duplex mode because they have to be constantly listening for data collisions, which means, they can't send and receive data at the same time. Think of it like a walkie-talkie where one person can either talk or listen at a time, instead of full-duplex, which is like a telephone. And the reason for the devices to be running in half-duplex mode is because they have to be listening for collisions on the network.
A network switch on the other hand, uses an internal table that keeps track of the connected network devices addresses and its ports, and by reading the headers of the incoming data it creates temporary connections between the source and destination ports eliminating collisions on the network, and decreasing traffic overhead, therefore allowing network devices to work in full-duplex mode, since they don't have to listen for collisions any longer... Giving you a more efficient (faster) network.
That's when it hit me: Yes, using Google to look up information is great, but should I be so dependent on it that I am unable to answer such a basic networking question?"
And that is why I decided to start writing 'mindupload' notes to myself... So, here's what I learned (re-learned, actually, since I learned this in College, and eventually forgot).
A hub takes data (aka packets) arriving at the incoming port, and transmits it to all outgoing ports with a connected device to it. If more than one computer receives the data and try to respond, it could generate network collisions because they are responding to the same data at the same time, this could slow down your network due to processing of the collision and re-transmission of the data. Related to this same issue, the network devices connected to the hub will be running in half-duplex mode because they have to be constantly listening for data collisions, which means, they can't send and receive data at the same time. Think of it like a walkie-talkie where one person can either talk or listen at a time, instead of full-duplex, which is like a telephone. And the reason for the devices to be running in half-duplex mode is because they have to be listening for collisions on the network.
A network switch on the other hand, uses an internal table that keeps track of the connected network devices addresses and its ports, and by reading the headers of the incoming data it creates temporary connections between the source and destination ports eliminating collisions on the network, and decreasing traffic overhead, therefore allowing network devices to work in full-duplex mode, since they don't have to listen for collisions any longer... Giving you a more efficient (faster) network.
Labels:
mindupload,
networking
Introducing MindUpload
During the past few weeks, I've found myself in 2 or 3 situations where someone asked me a somewhat technical question, and I struggled so hard trying to answer and even having to admit that I couldn't recall the answer.
I was ashamed of myself.
Unlike riding a bike, information sometimes can be easily forgotten specially if you don't use it often enough. So, I've decided to start writing up technical notes to myself on this blog.
I will not discriminate between complex or trivial notes. I will try to keep them short, and I will always read up about the subject before writing about it, but I will always write using my own words. If I quote, I will cite sources. If I make I mistake, I expect you to leave a comment.
All posts related to this idea will be tagged as: mindupload.
I was ashamed of myself.
Unlike riding a bike, information sometimes can be easily forgotten specially if you don't use it often enough. So, I've decided to start writing up technical notes to myself on this blog.
I will not discriminate between complex or trivial notes. I will try to keep them short, and I will always read up about the subject before writing about it, but I will always write using my own words. If I quote, I will cite sources. If I make I mistake, I expect you to leave a comment.
All posts related to this idea will be tagged as: mindupload.
Labels:
mindupload
Sunday, August 1, 2010
Subscribe to:
Posts (Atom)