AddVMOption -Duser.language=en
AddVMOption -Duser.region=US
Wednesday, December 30, 2009
Config language - sqldeveloper
sqldeveloper\sqldeveloper\bin\sqldeveloper.config
Sunday, December 13, 2009
double fork to avoid zombie process
It is a common mistake to fork a child process without calling waitpid() to wait for the termination of the child process. Without a wait() call, the child process will become a zombie process after its termination because its parent process does not cleanup its process information in the system. A zombie process occupies a pid in the system, decrease the available pids in the system. Zombies are mark as "defunct" if you check the process by the "ps" command.
However, sometimes we do not want the parent process to wait for its child process for a long time. There is a way to achieve both "not create zombie process" and "not wait for the child process to its termination", and the way is to do a double fork.
The idea is simple, when a parent process (say A) want to fork a child process to do "something". Process A does not fork a process to do "something" directly. Process A first forks a child process (say B), and process then forks its child process (say C) to do "something" and process B terminates as soon as process C is created. In this way, process A only has to wait for process B for a short time. In the same time, since it has no parent process (process B is dead), the system will "rechild" process C to the init process. The init process calls wait() for its child process, solving the zombie process problem.
The program looks like
However, sometimes we do not want the parent process to wait for its child process for a long time. There is a way to achieve both "not create zombie process" and "not wait for the child process to its termination", and the way is to do a double fork.
The idea is simple, when a parent process (say A) want to fork a child process to do "something". Process A does not fork a process to do "something" directly. Process A first forks a child process (say B), and process then forks its child process (say C) to do "something" and process B terminates as soon as process C is created. In this way, process A only has to wait for process B for a short time. In the same time, since it has no parent process (process B is dead), the system will "rechild" process C to the init process. The init process calls wait() for its child process, solving the zombie process problem.
The program looks like
void func()
{
pit_t pid1;
pit_t pid2;
int status;
if (pid1 = fork()) {
/* parent process A */
waitpid(pid1, &status, NULL);
} else if (!pit1) {
/* child process B */
if (pid2 = fork()) {
exit(0);
} else if (!pid2) {
/* child process C */
execvp("something");
} else {
/* error */
}
} else {
/* error */
}
}
Monday, December 7, 2009
kill all child process
killtree () {
for child in $(ps -o pid= --ppid $1)
do
killtree $child
done
echo "kill -9 $1"
kill -9 $1 2>/dev/null
}
killtree {some pid}
for child in $(ps -o pid= --ppid $1)
do
killtree $child
done
echo "kill -9 $1"
kill -9 $1 2>/dev/null
}
killtree {some pid}
read line in bash script
It is very easy to read "words" in a bash script. But what if you want to read a line in a text file? I have this problem today, After some googling, I found a interesting way to do this.
while read l
do
echo $l
done < xxx.txt
It use the xxx.txt as input, and the read command in bash will read the input line by line.
while read l
do
echo $l
done < xxx.txt
It use the xxx.txt as input, and the read command in bash will read the input line by line.
linux 802.1q support
In the previous article "vlan tag under vmware/virtualbox", I found that the e1000 network driver cannot insert vlan tag to frames. In this article I want to tell you that I WAS WRONG.
After some experiments, I found that the e1000 driver does insert the vlan tag into the frames. The problem is that the e1000 driver automatically remove vlan tags when receiving incoming frames before I was trying to read the incoming frames by tcpdump.
So, we can now use liunx + 802.1q module to communicate with vlan members.
After some experiments, I found that the e1000 driver does insert the vlan tag into the frames. The problem is that the e1000 driver automatically remove vlan tags when receiving incoming frames before I was trying to read the incoming frames by tcpdump.
So, we can now use liunx + 802.1q module to communicate with vlan members.
Subscribe to:
Posts (Atom)