Meeting 7: Kernel Services and Configuration

Jeremy Portzer Wednesday, May 21, 2003

• The /proc filesystem

See Reference Guide Chapter 5.

The /proc filesystem does not contain files on disk or on a network, but rather a look into the workings of the kernel. Most of the information is read-only, but some of it you can change to alter the behavior of a running kernel. The directories in /proc named with numbers refer to running processes; try "cd /proc/$$" to see information about your current shell. For example, the "cmdline" file shows the command line that started the process, and "cwd" shows the current working directory of the process.

Some files in /proc of interest:

There are many other files in /proc -- play around and have fun looking! But unless you can afford to crash your system, don't edit any files unless you know what you're doing. Especially /proc/kcore. :-)

• /proc/sys configuration with sysctl

You can edit the /proc/sys files directly with things like "echo 1 > /proc/sys/net/ipv4/ip_forward". Or use /sbin/sysctl like this:

To print a value: /sbin/sysctl net.ipv4.ip_forward

To set a value: /sbin/sysctl -w net.ipv4.ip_forward=1

All changes to the various /proc/sys values are temporary. But, you can put them in /etc/sysctl.conf and they'll be re-read at boot-time.

Here's a default /etc/sysctl.conf from one of my systems:

# Disables packet forwarding

net.ipv4.ip_forward = 0

# Enables source route verification

net.ipv4.conf.all.rp_filter = 1

# Disables the magic-sysrq key

kernel.sysrq = 0

You can also use the graphical tool redhat-config-proc (formerly sysctlconfig) to edit this file. Redhat-config-proc has some nice documentation that tells you what the various values do, though it doesn't necessarily support everything that's available in your running kernel.

• The Linux Quota System

Quick and dirty: adding quotas to /home :

Add "usrquota" (and/or "grpquota") to the options in /etc/fstab. Remount (or reboot).

• Understanding /etc/inittab

Pretty straightforward; inittab governs gdm/xdm startup and init default. 3 = text login (no gdm), 5 enables gdm. You can also enable serial terminals here, or modify parameters for "getty" (which listens on the tty1 through tty6 consoles), and modify the behavior when ctrl-alt-del is pressed. Run "kill -HUP 1" to cause init to re-read the file. (init always has PID 1.)

• Managing System V Initialization Scripts

chkconfig, redhat-config-services, /sbin/service

Note that chkconfig <servicename> on will read the default runlevels from the service's initscript, from a special comment near the top.

Chkconfig will enable xinetd.d services by changing the "disable=" line, but you must restart xinetd manually for it to take effect. chkconfig --list is handy; shows which initscript and xinetd services are enabled.

Understand the underlying nature of the System V initscript system: Each service has a shell script in /etc/rc.d/init.d/ . These scripts are then symlinked in directories corresponding to each runlevel; for example /etc/rc.d/rc3.d/ for runlevel 3. The symlinks are named with S or K for start or kill, followed by a priority number, followed by the service name. The services are started/killed in the order specified by the priority. For example:

$ ls /etc/rc.d/rc3.d/*ssh

lrwxrwxrwx 1 root root 14 Oct 29 2002 S55sshd -> ../init.d/sshd

This means that ssh is started in runlevel 3 with priority 55. The actual script that starts sshd is at /etc/rc.d/init.d/sshd. The symlinks are normally managed by chkconfig so you don't have to worry about them yourself. Also, note the "S99local" file which is just a symlink to "../rc.local". You can add custom startup stuff here without having to make a full initscript if you wish.

• Software RAID Configuration

Have not done this myself. Anyone?

[Customatiztion Guide, Chapter 3?]

• Configuring, Compiling and Installing the Linux Kernel

Using pre-built official kernels from Red Hat (recommended)

Customatiztion Guide, section IV, chapter 30: Upgrading the Kernel

Install official kernels with up2date or RPM. Use rpm -i to install the kernel, not rpm -U ! If you use -U, your old one will be removed and you will have nothing to fall back on if the new one doesn't work. Rpm -i will automatically update your GRUB configuration (does it update LILO or not??). Pay attention to the archictecture of the kernel and the SMP flags; you normally use i686 or athlon, not i586 or i386 unless you really do have that old hardware.

All of the official kernels use initrd's, so be sure to include those in your GRUB/LILO setup if you're editing the setup. The initrd's can be made manually with mkinitrd(8) but the RPMs do that automatically. Be sure your /etc/modules.conf is correct so the proper drivers are included in your initrd.

Compiling your own kernel

Customatiztion Guide, Appendix A: Building a Custom Kernel

These are my recommendations, which mostly jibe with Appendix A.

• Install a kernel-source package (NOT kernel-2.4.18-27.8.0.src.rpm, but kernel-source-2.4.18-27.i386.rpm)

• Make a backup copy of .config if one exists.

• Run make mrproper

• Copy the appropriate file from config/ to match your base configuration (ie, i686, smp, bigmem, whatever) to .config

• If you don't need any other changes, run make oldconfig

• Otherwise, make xconfig or make menuconfig to edit configuration. Since you're going to the trouble of editing the configuration, I recommend only including support for hardware that you're using. You still probably want some things as modules for convenience, but stuff needed for bootup can be compiled in (like SCSI host controller drivers). This way you won't need an initrd. Uncheck the bazillion modules you don't care about to save compiling time.

• Edit Makefile to adjust EXTRAVERSION. This is highly recommended to help you keep track of your custom kernels. I ususally append my initials to the extraversion.

• make dep

• make clean

• make bzImage

• make modules

• make modules_install

• make install

• Check bootloader configurations. The "make install" step should have created the initrd for you, but verify that it's correct (if you need one). Rerun lilo if necessary, reboot, and see if it works!

Some reasons you might want to compile your own kernel:

• Tune your system; ie remove use of initrd and modules for your scsi devices

• Enable hardware that's disabled in the stock kernels. (For example, on Red Hat Linux 6.2 I had to recompile to enable RAM over one gigabyte.)

• Add third-party drivers (usually these are compiled as modules and are outside the normal kernel source tree, but some require kernel patches, such as Win4Lin.)

Some reasons not to compile your own kernel:

• Lose support from Red Hat (if you have it anyway)

• Lose the benefit of extensive QA testing from Red Hat

• Lose ability to easily upgrade with RPM.

I do not recommend using "vanilla" kernels from kernel.org. They are missing the large number of patches that Red Hat adds, such as NPTL and other features taken from the 2.6 development tree. They will most likely result in an unstable system unless you really know what you're doing. If you do want to adjust which patches are installed, try the kernl SRPMs (.src.rpm) -- however, the kernel build system is not easy to figure out! (The kernel.spec file in one SRPM that I looked at was 4276 lines long!)

• The LILO Map Installer

If LILO is used, its configuration is stored in /etc/lilo.conf and you must re-run /sbin/lilo (I prefer /sbin/lilo -v) in order for configuration changes to take effect. The biggest mistake people make with LILO is forgetting to re-run it after editing the file! Be sure to include entries in lilo.conf for the initrd (if used) and the root filesystem.

If for some reason you do forget to re-run LILO and an unbootable system results, boot the rescue CD, go to a shell, and run "/mnt/sysimage/sbin/lilo -v -r /mnt/sysimage" . (or just chroot /mnt/sysimage followed by /sbin/lilo) . See lilo(8) and lilo.conf(5).

GRUB is now used by default; GRUB reads the configuration file directly from the / partition on every boot-up, so you don't have to re-run it in most situations. If you're changing the location of the bootloader, however, you may need to run grub-install(8) -- also see grub(8) and the info pages. (I recommend pinfo for easy info page viewing; this is often not installed by default however.)

Note: Red Hat uses /etc/grub.conf as the GRUB configuration files, but if you're reading documentation for other distributions you may see references to "menu.lst". They are the same file; RH changed the name to be more intuitive.