Backing Up E-mail,

I would like to be able to save copies of all my inbound e-mail for backup purposes. How can I do this?


I would like to be able to save copies of all my inbound e-mail for backup purposes. How can I do this?

This is easily accomplished with a program named procmail. I won’t go into the installation and setup of procmailitself, since most package systems (RPM, DEB) now do this quite nicely for you. If you already have an account on a Linux system (or your own system), chances are good that procmail is already setup and configured. If not, contact your system administrator or try installation via your distribution’s package manager.

To quickly find out if procmail is already installed on your system, issue the following command:

# which procmail

A successful installation should display the location of procmail on your system (probably /usr/bin/procmail).

If procmail is installed, the rest is easy. If there isn’t one already, create a .procmailrc file in your home directory with permissions 0700.

# touch ~/.procmailrc
# chmod 0700 ~/.procmailrc

There are many options for procmail ‘recipes’ (the configuration sections that determine what to do with different kinds of e-mail). Some of these are explained in the man page for procmailrc.

# man procmailrc

For a simple start though, try the following in the .procmailrc file, substituting your own information where it is appropriate.


:0 c:

:0 c:
* ^FROMdtype@dtype.org

* ^Sender: owner-linux-kernel

The LOGFILE entry specifies a file for procmail to log all activity to. This should be the first place you check if there are any problems.

There are three different entries in this .procmailrc file. The first entry specifies a file to save all mail for backup purposes (in this case, /home/dtype/ Mail/backup). The c: part tells procmail to save the mail and to continue with normal mail processing, including the rest of the configuration file. Without this, all of your mail would be saved to the backup file and nowhere else.

If you would like to save your outbound mail for tracking purposes, another entry for outbound mail is also included.

The last entry is an example of using procmail to sort inbound mail for a particular mailing list, in this case the linux-kernel mailing list. Procmail will look for the text owner-linux-kernel in the Sender: header of the mail. Note that the c: is missing here because we want the mail to be delivered to this mailbox and not to the Inbox as well.

Try sending yourself some mail to verify the proper operation of procmail. You should see at least a procmail log entry and a copy of the mail in the backup folder.

If you do not see this, then you will need to verify the procmail installation. /var/log/maillog is a pretty good place to start.

This should get you started. You can do a lot with procmail, and it is worth learning if you need to manage a great deal of mail. At the very least, it is very useful for the backup purposes described above.


I would like to share data between operating systems on a dual-boot system. What is the recommended way to do this?

If there’s one thing that Linux is good at, it’s sharing. There are a lot of ways to share files from different filesystems. Some people recommend creating a separate FAT partition for sharing between operating systems, but a more elegant solution is to allow each OS to mount the other’s filesystem.

Until fairly recently, there weren’t any good utilities for mounting an ext2 (Linux) filesystem under Windows. However, Linux has always been able to easily read and write to Windows/ DOS FAT filesystems. Many Windows tools for reading and writing to ext2filesystems have emerged recently, but by and large these are far less trustworthy than the existing Linux tools for sharing filesystems.

In order to mount the FAT filesystem under Linux, your kernel will need to contain the appropriate support. Most default kernels already include this support, but if you are compiling your own kernel, be sure to include FAT and VFAT filesystem support. If you’d prefer not to compile it into your kernel, FAT and VFAT support are also available as loadable modules.

In any case, to start sharing filesystems you’ll need to first create a mount point under Linux. This can be any directory in the filesystem that you want, but it’s helpful to use a name that makes sense(such as /mnt/msdos for this example).

# mkdir /mnt/msdos

You will then need to add a line to your /etc/fstab for the FAT filesystem. If your kernel contains VFAT support, you’ll be able to view and edit the long filenames used by modern versions of Windows.

Try adding the following line to /etc/ fstab (note that in this example, we used the third partition /hda2 on our hard disk — you will, of course, need to substitute the proper partition for your system):

/dev/hda2/mnt/msdosvfat defaults 0 1

If you don’t want this filesystem to be automatically mounted at boot time, you can add a ,noauto after the defaults option. You should now be able to mount the Windows partition as the root user.

# mount /mnt/msdos

If you get any errors about a bad filesystem, then you have likely specified the wrong partition. At this point, you should probably verify the partition and retry.

If you get an error regarding kernel support for the vfat filesystem, try changing the /etc/fstab entry from vfat to msdos. If this works, then your kernel doesn’t have support for Windows’ long filenames. If this does not work, your kernel does not have the proper filesystem support for any DOS or Windows filesystems.

Assuming that everything did work, however, you should now be able to access your Windows data from Linux under the /mnt/msdos mount point (or whatever mount point you created). If you set this up as shown above, only root will be able to write to these files. Keep in mind that the FAT filesystem does not include user permissions support.


I’m trying to service a lot of connections via Apache. I have hard configured the number of Apache children to 1000 in order to minimize process spinup time. The box performance is bad and occasionally even refuses connections. Any ideas?

You’re likely running into a problem often referred to as the “thundering herd.” It is well documented with Apache and Linux, and there are several ways to work around it.

In Linux, this condition usually stems from the process “wake semantics.” When a new connection arrives to be serviced in Apache/Linux, all of the sleeping processes are notified. All of these processes will then all try to take control of the new connection. However, only one of them will succeed, and the others will fail and return to their sleeping state. This is referred to as wake all semantics. Linux 2.2 and older kernels operate in this manner.

When there are only a few sleeping Apache processes, this isn’t a problem. Apache normally will scale the number of sleeping processes using the MinSpareServers and MaxSpareServers configuration variables from httpd. conf. Setting the MaxSpareServers to an abnormally high value, however, can potentially cause performance problems. I usually set it to between five and ten percent of the MaxClients value.

If you are setting the MaxSpareServers value abnormally high, tuning it down may result in an immediate performance gain.

Some kernels don’t suffer from this problem because of an ability to utilize ‘wake one’ semantics, which allow a single process to be awakened for each inbound connection. The BSDs are capable of this, as is the Linux 2.4 kernel.

In order to take advantage of these semantics, Apache must be compiled with a particular option. When configuring Apache for the 2.4 kernel, try issuing the command that is shown in Figure One before compiling. This may improve performance on kernels capable of wake one semantics.

Figure One: Configuring Apache for Wake One Semantics


There are a variety of tuning parameters for servicing high numbers of network connections. Apache has a built-in hard limit for the maximum number of connections allowed, requiring a recompile to set this higher than 256.

Linux will also require some /procfilesystem tuning in order to accommodate high-capacity servers. You will also want to look at Linux’s compiled-in process, system-wide, and per-user limits.

In short, there are a lot of things to be aware of when tuning for high numbers of Apache processes/connections. The “thundering herd” condition is perhaps one of the most overlooked problems, but there are a variety of other factors to consider.

More information about tuning Apache for high numbers of connections can be found at http://linuxperf.nl.linux.org/webserving.

Drew Streib is a coder, admin, and writer with VA Linux Systems. He can be reached at tech@linux-mag.com.

Comments are closed.