Custom kernels

sysctl

sysctl is a relatively new kernel interface that allows access to specific variables in the kernel. Some of these variables are read-only: you can look, but not touch. Others are changeable.

sysctl variables are usually referred to simply as sysctls. Each sysctl has a name in "Management Information Base"(MIB) form, consisting of a hierarchical arrangement of names separated by periods (.). The first component of the name indicates the part of the kernel to which it relates. The following examples give you an idea of how to use the sysctl program:

$ sysctl kern.ostype
FreeBSD
$ sysctl kern                      list all sysctls starting with kern
$ sysctl -a                        list all sysctls
# sysctl net.inet.ip.forwarding=1  turn IP forwarding on
net.inet.ip.forwarding: 0 -> 1

Some of the more interesting sysctls are:

kern.ostype: FreeBSD kern.osrelease: 5.0-RELEASE
kern.version: FreeBSD 5.0-RELEASE #0: Thu Jan 16 15:03:31 CST 2003
grog@freebie.example.org:/usr/src/sys/GENERIC kern.hostname: freebie.example.org
kern.boottime:  { sec = 1007165073, usec = 570637 } Fri Jan 17 10:34:33 2003 
kern.bootfile: /boot/kernel/kernel
kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
kern.module_path: /boot/kernel;/boot/kernel;/boot/modules;/modules 
kern.coredump: 1 
kern.corefile: /var/tmp/%N.core
kern.msgbuf: nreach TCP 213.46.243.23:25370 139.130.136.138:25 in via ppp0
net.inet.ip.fw.enable: 1 hw.machine: i386
hw.model: Pentium II/Pentium II Xeon/Celeron
hw.ncpu: 1
hw.byteorder: 1234
hw.physmem: 129949696
hw.usermem: 100556800
hw.pagesize: 4096
hw.floatingpoint: 1
hw.machine_arch: i386
hw.ata.ata_dma: 1
hw.ata.wc: 1
hw.ata.tags: 0
hw.ata.atapi_dma: 0
compat.linux.osname: Linux
compat.linux.osrelease: 2.2.12
compat.linux.oss_version: 198144

Many of these need no description, but some are less obvious:

• kern.msgbuf shows the contents of the kernel message buffer, which is also listed by the dmesg program.
• kern.corefile specifies a template for the name of the core dump file generated when a process fails. By default the core file ends up in the current working directory—whatever that might be. By specifying an absolute path name, you can ensure that any core file will go into a specific directory. The text %N is replaced by the name of the program.

Living with FreeBSD-CURRENT

Keeping up with FreeBSD-CURRENT requires work on your part. You should be on the FreeBSD-current@FreeBSD.org mailing list, which you can join via majordomo. See page 17 for details of how to use majordomo.

Build kernels with debug symbols

FreeBSD-CURRENT is not as stable as the released releases. To prepare yourself for possible problems, you should build kernels that include debug symbols. The resultant kernel is about 30 MB in size, but it will make debugging with ddb (the kernel debugger) or gdb much easier. Even if you don't intend to do this yourself, the information will be of great use to anybody you may call in to help. We looked at how to build a debug kernel on page 614.

Solving problems in FreeBSD-CURRENT

You will run into problems with FreeBSD-CURRENT. When it happens, please first read the mailing list and possibly the mail archives and see if the problem has been reported. If it hasn't, try to investigate the problem yourself. Then send mail to FreeBSD-current describing the problem and what you have done to solve it.

If you experience a panic, please don't just send a message to FreeBSD-current saying "My kernel panics when I type foo." Remember that you're asking somebody to use their spare time to look at the problem. Make it easy for them:

1. Update to the absolutely latest sources, unless emails have been warning against this.
2. If you have any local patches, back them out.
3. Recompile, from scratch, your kernel with ddb and with complete symbols (see above).
4. Report all details from the panic. At an absolute minimum, give all information from
5. show reg and trace.
6. Try to dump the system.
7. If you're successful, follow the procedure discussed in the following section to find out something about how the problem occurred.

If you don't do at least this, there isn't much chance that a mail message to FreeBSD-current will have much effect.