Monthly Columns
 

What It's All About

Copyright © 1999 Todd Whitesel

Welcome to the July issue!

I missed my last two columns (see the first question for details), so let's dive right in.

List of Topics






Q: Where'd you disappear to four months ago?

A:

Just as I finished up the supplementary material for the January column I came down with a nasty case of GERD (AKA acid reflux disease), caused by many months of frequent overeating at the local Chevy's restaurant (not their fault; I ate plain food, just way too much of it). I was on prescription antacids for three months to give my digestive system a chance to recover. While I haven't needed any special treatment for a while, a lot of damaged tissue has been healing itself and this is no fun, trust me.

Much of the time I have felt like I was coming down with a cold, but it didn't act like a cold; and a few times every month something big has peeled off and made eating a scary prospect for a few days because the newly exposed esophagus skin is really sensitive. I'm not joking here, people; if it weren't for the fact that I'm still in my late twenties I'd swear I was having a prelude to a heart attack or something. As you might imagine, my free-time activities have been in disarray for months.

Moral of the story is: don't get heartburn. It's bad.

We now return you to your regularly scheduled AnswerMan...



Q: Didn't you make up a little bit of history (specifically, the death of the DEC 'Tulip' chips) in your January column?

A:

Um, yeah, it looks like I did. I received a couple of e-mails in January setting me straight.

  1. Intel didn't acquire the Tulip ethernet chips, Cabletron did. However, the fab plant for Tulips was acquired by Intel. In any case, everyone selling Tulip-based PCI ethernet cards has switched to another chip or begun using a clone of the Tulip, which usually is just different enough to require device driver tweaks. This turn of events kicked off a project within NetBSD to completely rewrite the de driver, cleaning it up and adding support for all the various clones. (This is still in progress, I don't think it's available in netbsd-current yet.)
  2. Intel didn't acquire the rights to the Alpha architecture -- those went to Compaq. What Intel got were the fabrication plants, and a legal obligation to continue manufacturing Alpha chips for some amount of time. There is at least one other Alpha licensee (Samsung, I believe), so when the Intel obligation runs out it won't mean immediate death for Alpha CPUs.




Q: Why does my script work on commercial unixes but not on free unixes? After the "do" loop is over, the variables that are set inside the loop revert to their previous before-the-loop values.
#!/bin/ksh

ps -ax | while read PID TT STAT TIME COMMAND ARGS
do
  case $COMMAND in
    syslogd  ) SYSLOGD=$PID ;;
    portmap  ) PORTMAP=$PID ;;
    update   ) UPDATE=$PID ;;
  esac
  echo syslogd=$SYSLOGD portmap=$PORTMAP update=$UPDATE
done

echo FINAL syslogd=$SYSLOGD portmap=$PORTMAP update=$UPDATE

A:

Believe it or not, it's the fact that you're piping something into the while construct. One of the gray areas of unix shell scripting is which operations occur within subshells. Subshells are normally requested explicitly by using parentheses:

(cd path/to/my/dir ; make something)

To implement I/O redirection for complex shell commands, a unix shell will typically fork copies of itself so that it can redirect the output of the subshell thus created. This always happens with command substitution, but in your case (a loop) there is no clear need for it. However, the shell decides to do it anyway. You could argue (with some basis) that this is a bug in the shell, but the better solution is to make your script more bulletproof:

#!/bin/ksh

ps -ax | 
{
while read PID TT STAT TIME COMMAND ARGS
do
  case $COMMAND in
    syslogd  ) SYSLOGD=$PID ;;
    portmap  ) PORTMAP=$PID ;;
    update   ) UPDATE=$PID ;;
  esac
  echo syslogd=$SYSLOGD portmap=$PORTMAP update=$UPDATE
done

echo FINAL syslogd=$SYSLOGD portmap=$PORTMAP update=$UPDATE
}
If you ever wondered what the heck a shell does with curly braces, now you know. Everything inside the curly braces is forced into its own subshell, and once there the while loop executes as expected. It is still possible for additional subshells to be created, if the operations inside the curly braces are complex enough to require it.

Admittedly, this is one of the yuckier areas of unix shell scripting. Once a construct gets complex enough, you lose the ability to change variable values in the "top level" shell. If anyone has a good general technique for combatting this, I'd love to hear it.



Q: Is there any automatic method for creating the device special files in the /dev directory?

A:

Yes, there is. Go to /dev and look at the MAKEDEV script.



Q: My /var partition is starting to overflow, help!

A:

Well, there's a program called FIPS for splitting partitions, but I don't know of any programs that will extend partitions. Here's a list of options in order of increasing effort:

  • You can move specific directories in /var to a different partition and replace them with a symbolic link to their new location.
  • You can replace a specific directory in /var with a whole other partition, by moving the directory's contents to the partition and mounting the partition over the directory in your /etc/fstab file.
  • You can move /var to a bigger partition, usually on another disk.
  • You can repartition the disk that /var is currently on, now that you know how much space it really needs.

Obviously none of these solutions is perfect, but partition overflows are a fact of life. Experienced sysadmins can wrack their brains planning to avoid it, but it will still happen. At some point you just have to face the prospect of moving things around, or get familiar with the quota system and enable it on your critical partitions. This forces users to deal with their own overflow problems. (And now a confession: I've never learned how to enable quotas on any of my systems. Someday my innocence will be destroyed, I'm sure of it.)



Q: Why do my signal-using programs "lose" signals?

A:

This is almost always because unix does not actually guarantee that you will "see" every single signal that is sent to your process. No count of signals is kept, only a flag (one for each type of signal). This flag is set whenever a signal of its type is sent to the process, and it is cleared whenever the process receives that signal type and starts to execute its signal handler.

Since scheduling delays can easily prevent a process from running for substantial fractions of a second, the same signal may be sent more than once without being handled again, and some of those signals to appear to be "lost". In actuality the system is only keeping track of the fact that at least one signal was sent since the last time the process' signal handler was run.

Most of the time this surfaces in SIGCHLD handlers for "reaping" dead child processes using some variant of wait(2). Most network server programs have to do this somewhere. The signal handler loops, checking for more terminated processes until the error return indicates that there are no more dead children at the moment. After this point, a new child termination that sends another SIGCHLD will cause the flag for SIGCHLD to be set again, and the signal handler will get called again at the earliest available opportunity.



Q: Those Alpha boxes looked cute, have you found any other weird hardware to run BSD on lately?

A:

Heck, yeah.

Check out these used 110 Mhz Sparcstation 5 class laptops. NetBSD/sparc installs on them fine, but is limited to a text console until XFree86 can be ported over. Fortunately, the manufacturer of the laptops has released tech info, so we may see more drivers soon. Until then, I'm stuck with Slowlaris whenever I want graphics on it.

I also scored some Mac IIci's at a swap meet a week before I wrote this, and so I haven't had the time to get them running NetBSD/mac68k yet. (Trust me, they were really cheap or I wouldn't have bought them.)



Q: Do you have any questions sitting around that some of us could take a crack at helping you answer?

A:

Certainly. Here are the five oldest unanswered questions sitting in my mailbox.

  1. How do I set up a machine with two ethernet cards to act as a router?
  2. How do I set up a machine with one ethernet card and a serial modem to act as a PPP gateway?
  3. How do I configure my machine to use a proxy server (Winproxy by Ositis if it matters)?
  4. How do I configure the print system to deal intelligently with PCL and Postscript printers?
  5. I installed FreeBSD from an MS-DOS partition but forgot to install the man pages, and now I can't get /stand/sysinstall to find the MS-DOS partition so I can't install my man pages! Now what do I do?





Do you have questions for the BSD Answer Man? Send them to bsd-answerman@toddpw.org.
Any email sent to this address is assumed intended for publication and will become the property of Dæmonnews.

That's all for this month, folks. Until next time, remember: there's no shame in asking RTFM questions any more, because these days, there is just too much FM to R.

Todd P. Whitesel, toddpw@toddpw.org