LINUX NEWS
Resources & Links From CramSession.com
Thursday, December 13, 2001TABLE OF CONTENTS
1) Sean’s Notes
2) Linux News
2.4 Maintainer Marcelo Tosatti Answers Your Questions
Red Hat Starts Clamping Down
Ximian to Offer Proprietary Exchange Connector
VA Linux is now VA Software3) Linux Resources
DNS For Dummies
Some Linux+ Practice Questions
Bynari Insight 2.6 Free Download
Multicast Video Server
What Are Your Expectations?4) App o’ the Week
~~~~~~~~~~~~~~~~~~~~~~ ADVERTISEMENT ~~~~~~~~~~~~~~~~~~~~~~~
Get your hands on the best training resources available for Win2K certifications. Unmatched quality at an incredibly low price gets you $10,000 worth of training for only $299.
Click below to view a sample clip… http://ad.brainbuzz.com/?RC06&AI$59
For information on how to advertise in this newsletter
please contact mailto:adsales@CramSession.com or visit
http://cramsession.com/marketing/default.asp
-------------------------
1) Sean's Notes
-------------------------
Signals, in the Unix sense, are messages sent between
processes, much like an interrupt is a signal sent from the
hardware to the CPU. I've talked about signals in the past:
http://ertw.com/~sean/newsletter/June+28%2C+2001
With respect to killing off processes, the "kill" command is
used to send a signal (SIGTERM) to a process, in this case,
processid 1234
# kill 1234
Upon receipt of the signal, the process gets the chance to
exit gracefully. If it wasn't expecting the signal, the
operating system just turfs it.
Sometimes, processes misbehave. They either ignore SIGTERM,
or maybe are stuck in IO and can't get time on the CPU to
quit. In this case, we can send a stronger signal, SIGKILL.
There is no ignoring this one, and the kernel will do its
best to get rid of the process.
# kill -9 1234
However, there is a third class of processes that can't be
killed, no matter what signal you send them. These are
called "zombies". While they take up no CPU (because they're
technically dead), they're usually a symptom of another
problem with the application. They also take up resources,
such as process table space. Thus, dealing with zombies is
something a Unix admin will have to do at some point in their
career. Rebooting is not an option, either! You can see
zombies in the ps listing; they are marked with the <defunct>
tag.
At this point, it's probably a good thing if I explain parent
and child processes. If a process wants to create a new
process to handle some work, it does so by calling the fork()
system call. The operating system then creates a new process,
called a child process, which is exactly like the original,
or parent process. Execution of both processes continues after
the fork() call. Depending on the result of the call, the
process knows if it is the parent or the child. A parent can
have many children, but the children can only have one parent.
A more in depth look at fork() can be found in the July 12th
edition of Linux News:
http://ertw.com/~sean/newsletter/July+12%2C+2001
This is commonly used in web servers. The parent process
creates a bunch of children, and farms out the requests to
them. This way, many requests can be handled simultaneously.
If the parent process quits before the child does, this is no
problem. The child gets adopted by process #1, init. However,
if the child dies before the parent, we have a problem. Create
the following file, zombie1.c:
<div class="highlight"><pre><code class="c"><span class="cp">#include &lt;stdlib.h></span>
<span class="kt">void</span> <span class="nf">main</span><span class="p">(</span><span class="kt">void</span><span class="p">)</span> <span class="p">{</span>
<span class="kt">int</span> <span class="n">pid</span><span class="p">;</span>
<span class="n">printf</span><span class="p">(</span><span class="s">"Parent's pid is %d</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">getpid</span><span class="p">());</span>
<span class="k">if</span> <span class="p">((</span><span class="n">pid</span> <span class="o">=</span> <span class="n">fork</span><span class="p">())</span> <span class="o">></span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span> <span class="cm">/* Parent */</span>
<span class="k">while</span> <span class="p">(</span><span class="mi">1</span><span class="p">)</span> <span class="n">sleep</span><span class="p">(</span><span class="mi">10</span><span class="p">);</span> <span class="cm">/* Sit around */</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span> <span class="cm">/* Child */</span>
<span class="n">sleep</span><span class="p">(</span><span class="mi">1</span><span class="p">);</span>
<span class="n">printf</span><span class="p">(</span><span class="s">"Child %d exiting</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">getpid</span><span class="p">());</span>
<span class="n">exit</span><span class="p">;</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre></div>
Now compile, and execute it:
$ gcc zombie1.c -o zombie1
$ ./zombie1
Parent's pid is 24751
Child 24752 exiting
zombie1 basically creates a process, tells you the processid,
then creates a child. The parent then idles, while the child
exits after printing its pid.
In another window, do a "ps -ef":
$ ps -ef
...
sean 24758 24675 0 18:09 pts/2 00:00:00 ./zombie1
sean 24759 24758 0 18:09 pts/2 00:00:00 \[zombie1 <defunct>]
...
There -- process 24752 is a zombie. It was supposed to have
quit, since it called exit(). Now, try to kill it.
$ kill -9 24759
$ ps -ef | grep zombie1
sean 24758 24675 0 18:09 pts/2 00:00:00 ./zombie1
sean 24759 24758 0 18:09 pts/2 00:00:00 \[zombie1 <defunct>]
As many times as you try to kill the child, it isn't going to
go away.
So just how do you kill a zombie?
The answer isn't as exciting as you'd think. To kill a zombie,
kill its parent. The reason for this will shortly be evident.
$ kill 24758
$ ps -ef | grep zombie
$
If a process is creating zombie children, there is a good
chance that it's not operating correctly in the first place.
Left to its own devices, it'll do so until it brings the system
to its knees. I should mention, though, that some applications
do create one or two zombies because of a design oversight, so
you'll have to become familiar with the natural behavior of
your applications.
The reason the zombie gets created is because of a negligent
parent. When a child process dies, the parent process is
notified with the SIGCHLD signal. The parent process must
either explicitly ignore the signal entirely, or install a
signal handler that uses the wait() system call to acknowledge
the child's exit. As in life, there are responsibilities to
becoming a parent. (OK, I'm done with the bad analogies for
this week).
zombie2.c will fix the problem by ignoring the SIGCHLD signal.
<div class="highlight"><pre><code class="c"><span class="cp">#include &lt;stdlib.h></span>
<span class="cp">#include &lt;signal.h></span>
<span class="kt">void</span> <span class="nf">main</span><span class="p">(</span><span class="kt">void</span><span class="p">)</span> <span class="p">{</span>
<span class="kt">int</span> <span class="n">pid</span><span class="p">;</span>
<span class="cm">/* Ignore SIGCHLD to prevent zombies */</span>
<span class="n">signal</span><span class="p">(</span><span class="n">SIGCHLD</span><span class="p">,</span> <span class="n">SIG_IGN</span><span class="p">);</span>
<span class="n">printf</span><span class="p">(</span><span class="s">"Parent's pid is %d</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">getpid</span><span class="p">());</span>
<span class="k">if</span> <span class="p">((</span><span class="n">pid</span> <span class="o">=</span> <span class="n">fork</span><span class="p">())</span> <span class="o">></span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span> <span class="cm">/* parent */</span>
<span class="k">while</span> <span class="p">(</span><span class="mi">1</span><span class="p">)</span> <span class="n">sleep</span><span class="p">(</span><span class="mi">10</span><span class="p">);</span> <span class="cm">/* Sit around */</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="n">sleep</span><span class="p">(</span><span class="mi">1</span><span class="p">);</span>
<span class="n">printf</span><span class="p">(</span><span class="s">"Child %d exiting</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">getpid</span><span class="p">());</span>
<span class="n">exit</span><span class="p">;</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre></div>
$ gcc zombie2.c -o zombie2
$ ./zombie2
Parent's pid is 24847
Child 24848 exiting
In my other window:
$ ps -ef | grep zombie
sean 24847 24675 0 18:19 pts/2 00:00:00 ./zombie2
As you can see, the child (24848) got a clean exit, and the
parent (24847) can idle freely.
The alternative, to handle the SIGCHLD signal, is a bit more
work, but allows the parent to clean up after the child. If
you're interested, check out the man page for wait(2) to see
how to properly acknowledge a child's exit.
Creating zombie processes is the operating system's way of
handling the odd situation where the child dies before the
parent. In a properly designed application, there should not
be any zombie processes. Zombies tend to be indicators of a
misbehaving application. In this case, you can clean up all
the zombie children by killing the parent process (from ps -ef).
Long live the Penguin,
Sean
swalberg@cramsession.com
-------------------------
2) Linux News
-------------------------
-----------------------------------------------------
2.4 Maintainer Marcelo Tosatti Answers Your Questions
-----------------------------------------------------
Now that 2.5 is started, Linus has turned the job of
maintaining the 2.4 tree to Marcelo Tosatti, an 18-year-old
programmer from Brazil. In the latest Slashdot interview,
Marcelo answers some questions on his vision for 2.5, and
of course, questions about his age. The answers are terse
to say the least, but well worth the time to read.
http://slashdot.org/article.pl?sid/12/10/1656226&mode=nocomment
----------------------------
Red Hat Starts Clamping Down
----------------------------
Since it's freely downloadable, there is nothing stopping
someone from selling copies of Red Hat (or other distros, for
that matter) for cheap. Red Hat has started to clamp down on
this activity, insisting that if one redistributes the
software that it not be called Red Hat, since the CDs will
not come with any support. Personally, I think this is a
perfectly fine way of protecting their trademark, though once
you read the comments in this article, you'd think that the
company had committed murder...
http://www.newsforge.com/article.pl?sid/12/10/2014239
----------------------------------------------
Ximian to Offer Proprietary Exchange Connector
----------------------------------------------
Ximian is that company that brings a great GNOME desktop to
your Linux box. They have also put a lot of work into the
Evolution project, which is to create an Outlook-like
mail/calendar/etc. client for Linux. Their latest announcement
is that they'll soon be offering a connector that will let you
use Evolution with an Exchange server. Single user licences
are around $69, a pittance to pay if Outlook is the only
application that's keeping you running Windows.
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,5100241
,00.html
---------------------------
VA Linux is now VA Software
---------------------------
VA Linux used to be a big vendor of Linux-ready hardware.
They're also the parent company of SourceForge and Slashdot,
among many others. To reflect the change of focus to
software, they've changed their name appropriately.
http://www.valinux.com/about/pr/120501.php
-------------------------
3) Linux Resources
-------------------------
---------------
DNS For Dummies
---------------
Here's another look at DNS, this time covering off everything
from the local resolver, to the BIND server itself. It's
written with Solaris in mind, though everything mentioned
is the same under Linux.
http://everythingsolaris.org/articles/dfd/frameset.html
------------------------------
Some Linux+ Practice Questions
------------------------------
Here are 25 Linux+ practice questions, complete with
explanations. What's good about these is that they're
intentionally ambiguous, which should help you get a feel
for what you can expect on the real exam. The assumptions
made are listed with the answer.
http://www.unixreview.com/documents/s81/urm0112b/0112b.htm
--------------------------------
Bynari Insight 2.6 Free Download
--------------------------------
I had to read this offer over a few times to figure out what it
was they were giving away. Version 2.6 of the Insight client
is an Microsoft Exchange compatible mail/calendar client for
Linux. 2.6 is not the latest version, though, as 3.0 is coming
out soon and that won't be free. However, a good thing is a
good thing, so I'll be trying this one out at work next week!
http://www.bynari.net/Products/TradeXCH/body_tradexch.html
----------------------
Multicast Video Server
----------------------
When I was studying for the Cisco Switching exam, I really
could have used some multicast software to test out multicast
network configurations. The software on this page will stream
out MPEG videos using multicasts, which cuts down on the
bandwidth required to serve up multiple clients.
http://www.videolan.org/vlms/
---------------------------
What Are Your Expectations?
---------------------------
One of the driving forces behind Linux's popularity is that
it is free. This means that most of the development of Linux
and its applications, is performed by volunteers. Sometimes
we tend to forget this. The AbiWord project's development
team decided to write down their thoughts on it.
http://www.abisource.com/support/expectations.phtml
-------------------------
4) App o' the week
-------------------------
Long time readers will recognize this link, but given the
latest Goner virus, I thought it fitting to repost.
The Anomy Mailtool filters incoming (and outgoing, if you
want) mail for possible viruses. You can hook in a commercial
virus scanner, but Anomy's strength lies in its ability to
act on filenames using regular expressions. I use it myself,
and it has caught new viruses without even touching the
configuration.
http://mailtools.anomy.net/
-------------------------
(C) 2001 BrainBuzz.com, Inc. All Rights Reserved.
-------------------------
-------------------------
This message is from CramSession.com.
You are currently subscribed to the
Hottest Linux News and Resources
as: sean@ertw.com
To un-subscribe from this newsletter by e-mail:
send a blank email message to:
mailto:leave-linuxnews-3825955Y@list.cramsession.com
-------------------------------------------------------
To Subscribe to this newsletter by e-mail:
send a blank email message to:
mailto:join-linuxnews@list.cramsession.com
-------------------------