Back to Hoki's page

As in certain cults it is possible to kill a process if you know its true name.

Ken Thompson and Dennis M. Ritchie

First, I wish to thank Deja News. Without their help, I probably wouldn't never have managed to write all this, as I don't save every message. (No, I'm not sponsored by them...)

[Typist's note just for realism: SIGCAKE is not a real signal, at least according to signal(7) manpage. When I really tried it, it got Bad signal spec error. And no, Sendmail won't respawn if I SIGKILL it. The only reason Sendmail didn't worked in first place was that I hadn't enabled local mailer when I ran sendmailconfig first time. Now it works, and it hasn't eaten my mail since I reconfigured it.]

[Another Typist's Note: That picture is, see, ancient. Really really old. As you can probably see. But the point isn't the picture; It's what it represents.]

"Know your enemy and his good sides before judging him"

Sendmail is a mail delivery agent for UNIX systems. I usually think that Sendmail is really, really nice program, with two conditions. Sendmail is good if it works as expected, which means that

• I don't have to diddle with sendmail.cf configuration file (i.e. sendmailconfig script rrrrrocks!)
• It doesn't eat my mail, and delivers it to correct recipients.

In general, I expect sendmail to do its work. (Nice daemon. Come here. Take this letter. Nice daemon... Gogogogogo deliver it! Nownownow...) It usually does, but not always.

Nemesis. Not just for Zork anymore.™

Okay. But has The Almighty Mailer Daemon erred, then? Yes it has, twice. And both times it has lost our precious E-mail, or delivered it to wrong address. (Well, the good side is that spam is usually delivered to root@wwwwolf.pp.fi, our BOFH, and he knows what to do with spam... right?)

Ways to get rid of Sendmail

When I get annoyed at something, I usually keep my eye on it. Wrong move, and *boom*, end of it. I must punish those who do wrong, and Sendmail is number one on my list.

The canonical way of getting rid of sendmail is just removing it. Nice and simple solution. ("Sendmail is declared guilty of losing three e-mail messages, and will be executed with dselect this evening, 18.00 hours. Until then, have a nice day.") Unfortunately, Sendmail is our only mail delivery daemon, so deleting it would mean that I can't send or receive mail. (Yes, we know about QMail. So what?)

Deleting is a bit harsh way of treating the thing. More elegant approach is to send a signal at it. This may make Sendmail terminate itself, and it may be respawned when it is working again. I have sudoed (runs with super-user priviledges) kill program... the crossbow thingy. I use it to, well, send signals.

UNIX kernels (including our Linux kernel) control processes (running programs, in effect) by sending them various signals. For example, if program tries to access invalid part of memory, kernel sends SIGSEGV signal to process, and the last thing the process knows is that the pointer bugs can be such a pain in the... Well, there are other signals, like SIGHUP (Hangup) and SIGILL (Illegal instruction... well, "Belch", as Larry Wall commented this). There are lots and lots and lots of different signals (30 in my system), but only a fraction of them are usually invoked by users.

Well, users can send signals to processes, too. Most common signal used is SIGINT, or keyboard interruption (Usually control-C). If that doesn't work, the best thing to do is to send process SIGTERM signal (termination). Process can trap this ("SIGTERM caught. I will save and quit..."), so it isn't a great weapon against Sendmail.

The other option was the SIGKILL signal (non-catchable, non-ignorable kill signal). But that censored sendmail won't go down! It keeps respawning. It must have some hideous way to trap SIGKILL!

Solution

In 18th April 1997, we finally found a solution for this problem. Rasha made... well... impressive comeback to the Alfandra in laaaarge cake. I noticed something happening, when the cake shaked a bit and some roses fell off.

Airkanstryll Shadowblade commented it: "AAH! Haunted cake! Or localized seismic phenomenon! Or haunted cake exhibiting seismic properties! Or haunted geological fault! Or localized cakequake!"

Then, I noticed what had happened: Rasha's cake was probably re-generated to network environment by previously unknown UNIX signal. I spied on TTY and noticed the strange words: "Segmentation fault (cake dumped)".

I did a quick listing of available signals, and found a new signal, called SIGCAKE.

Because SIGCAKE is a previously unknown signal, no program can trap it. Neither can Sendmail. As I took my sudoed kill program, set it to SIGCAKE, pointed it at Sendmail and pulled trigger, Sendmail died, left a horrible-smelling cakedump and left, and it didn't respawned until my typist noticed a bug in sendmail.cf, fixed it and respawned it manually.

What Happened After That

I noticed that all cakedumps are stored to /var/spool/cakes into invidual files. I also noticed that I can turn cakedumps into cakes by adding water. The problem is, self-generated cakedumps won't usually be good-tasting cakes, because there is a certain amount of hair in parameters and really much randomness involved.

I began working on cakedumpd daemon that would generate cakedumps controlledly from Sendmail (or other programs, if I need smaller cakes...) and automatically process all cakedumps to generate all sorts of cakes from them. Infortunately, I have had little success.

Kirath made the first controlled cakedump in 18th May 1997 with new wondrous machine. I was totally perplexed by the haque and decided to work harder on cakedumpd.

Kirath's invention is able to control Cakeballs™ in FoodFight threads and elsewhere, making it a terrible weapon. In long-term plans, this invention has already revolutionarized the Server Daemon Warfare. I connected the device to my cakedumpd and made more and more cakedumps correctly. This. Is. Awesome.

With this wondrous new invention, I was finally able to conquer sendmail. I whacked it with SIGCAKEs long enough (and I generated huuuuge loads of yummy cakes), and my typist fixed config files with sendmailconf.

I have now completed the design of cakedumpd, so it works almost reliably.

cakedumpd became a part of a wide implementation of different cake-handling tools. The whole scheme is now controlled by a cakedump library - a shared object that can be loaded by any program that needs powerful cake handling.

News flash: Sun Microsystems apparently has ported the library to Java. As a result, I believe, a cakeful future is coming to a.f.d. Still, I disagree with Java folks - it should be 'Throw Once, Splut Anywhere' - but I guess that Java is mostly web-based technology, so Usenet jargon might not be as clear to the Sun marketroids.