DragonFly BSD


UNIX Basics

*Rewritten by Chris Shumway. *


The following chapter will cover the basic commands and functionality of the DragonFly operating system. Much of this material is relevant for any UNIX®-like operating system. Feel free to skim over this chapter if you are familiar with the material. If you are new to DragonFly, then you will definitely want to read through this chapter carefully.

After reading this chapter, you will know:

Virtual Consoles and Terminals

DragonFly can be used in various ways. One of them is typing commands to a text terminal. A lot of the flexibility and power of a UNIX® operating system is readily available at your hands when using DragonFly this way. This section describes what terminals and consoles are, and how you can use them in !DragonFly.

The Console


Additional ABI support:.
Starting cron.
Local package initialization:.
Additional TCP options:.

Wed Feb 18 17:53:48 GMT 2009

DragonFly/i386 (Amnesiac) (ttyv0)



DragonFly/i386 (Amnesiac) (ttyv0)

This line contains some bits of information about the system you have just booted. You are looking at a DragonFlyBSD console, running on an Intel or compatible processor of the x86 architecture(1). The name of this machine (every UNIX machine has a name) is Amnesiac, and you are now looking at its system console--the ttyv0 terminal. Finally, the last line is always:


This is the part where you are supposed to type in your username to log into DragonFly. The next section describes how you can do this.

Logging into DragonFly

DragonFly is a multiuser, multiprocessing system. This is the formal description that is usually given to a system that can be used by many different people, who simultaneously run a lot of programs on a single machine. Every multiuser system needs some way to distinguish one userfrom the rest. In DragonFly (and every other kind of UNIX and UNIX-like operating system), this is accomplished by requiring that every user must log into the system before being able to run programs. Every user has a unique name (the username and a personal, secret key (the password). DragonFly will ask for these two before allowing a user to run any programs.

Right after DragonFly boots and finishes running its startup scripts(2), it will present you with a prompt and ask for a valid username:



login: john

Type in john's password now, and press Enter . The password is not echoed! You need not worry about this right now. Suffice it to say that it is done for security reasons. If you have typed your password correctly, you should by now be logged into DragonFly and ready to try out all the available commands. You should see the MOTD or message of the day followed by a command prompt (a #, $, or % character). This indicates you have successfully logged into DragonFly.

Multiple Consoles

Running UNIX commands in one console is fine, but DragonFly can run many programs at once. Having one console where commands can be typed would be a bit of a waste when an operating system like DragonFly can run dozens of programs at the same time. This is where virtual consoles can be very helpful. DragonFly can be configured to present you with many different virtual consoles. You can switch from one of them to any other virtual console by pressing a couple of keys on your keyboard. Each console has its own different output channel, and DragonFly takes care of properly redirecting keyboard input and monitor output as you switch from one virtual console to the next.

Special key combinations have been reserved by DragonFly for switching consoles(3). You can use Alt - F1 , Alt - F2 , through Alt - F8 to switch to a different virtual console in DragonFly. As you are switching from one console to the next, DragonFly takes care of saving and restoring the screen output. The result is an illusion of having multiple virtual screens and keyboards that you can use to type commands for DragonFly to run. The programs that you launch on one virtual console do not stop running when that console is not visible. They continue running when you have switched to a different virtual console.

The /etc/ttys File


You can use the /etc/ttys file to configure the virtual consoles of DragonFly. Each uncommented line in this file (lines that do not start with a # character) contains settings for a single terminal or virtual console. The default version of this file that ships with DragonFly configures nine virtual consoles, and enables eight of them. They are the lines that start with ttyv:

# name  getty                           type    status          comments
# Virtual terminals
ttyv8   "/usr/pkg/xorg/bin/xdm -nodaemon"  xterm   off secure


Single User Mode Console

A detailed description of what single user mode is can be found in [boot-init.html#BOOT-SINGLEUSER Section 7.5.2]. It is worth noting that there is only one console when you are running DragonFly in single user mode. There are no virtual consoles available. The settings of the single user mode console can also be found in the /etc/ttys file. Look for the line that starts with console:

# name  getty                           type    status          comments
# when going to single-user mode.
console none                            unknown off secure

Note: As the comments above the console line indicate, you can edit this line and change secure to insecure. If you do that, when DragonFly boots into single user mode, it will still ask for the root password. Be careful when changing this to insecure. If you ever forget the root password, booting into single user mode is a bit involved. It is still possible, but it might be a bit hard for someone who is not very comfortable with the DragonFly booting process and the programs involved.


(1) This is what i386 means. Note that even if you are not running DragonFly on an Intel 386 CPU, this is going to be i386. It is not the type of your processor, but the processor architecture that is shown here.
(2) Startup scripts are programs that are run automatically by DragonFly when booting. Their main function is to set things up for everything else to run, and start any services that you have configured to run in the background doing useful things.
(3) A fairly technical and accurate description of all the details of the DragonFly console and keyboard drivers can be found in the manual pages of syscons(4), atkbd(4), vidcontrol(1) and kbdcontrol(1). We will not expand on the details here, but the interested reader can always consult the manual pages for a more detailed and thorough explanation of how things work.


DragonFly, being a direct descendant of BSD UNIX®, is based on several key UNIX concepts. The first and most pronounced is that DragonFly is a multi-user operating system. The system can handle several users all working simultaneously on completely unrelated tasks. The system is responsible for properly sharing and managing requests for hardware devices, peripherals, memory, and CPU time fairly to each user.


Value Permission Directory Listing
0 No read, no write, no execute ---
1 No read, no write, execute --x
2 No read, write, no execute -w-
3 No read, write, execute -wx
4 Read, no write, no execute r--
5 Read, no write, execute r-x
6 Read, write, no execute rw-
7 Read, write, execute rwx


% ls -l
total 530




This is all well and good, but how does the system control permissions on devices? DragonFly actually treats most hardware devices as a file that programs can open, read, and write data to just like any other file. These special device files are stored on the /dev directory.



Symbolic Permissions

Contributed by Tom Rhodes.


Option Letter Represents
(who) u User
(who) g Group owner
(who) o Other
(who) a All (world)
Adding permissions
Removing permissions
(action) = Explicitly set permissions
(permissions) r Read
(permissions) w Write
(permissions) x Execute
(permissions) t Sticky bit
(permissions) s Set UID or GID


% chmod go=FILE

A comma separated list can be provided when more than one set of changes to a file must be made. For example the following command will remove the groups and world write permission on FILE, then it adds the execute permissions for everyone:

% chmod go-w,a+x FILE

DragonFly File Flags

Contributed by Tom Rhodes.

In addition to file permissions discussed previously, DragonFly supports the use of file flags. These flags add an additional level of security and control over files (but not directories), helping to ensure that in some cases not even root can remove or alter files. File flags are altered by using the chflags(1) utility, using a simple interface. For example, to enable the system undeletable flag on the file file1, issue the following command:

# chflags sunlink file1

To disable the system undeletable flag, simply issue the previous command with no in front of the sunlink. Observe:

# chflags nosunlink file1


# ls -lo file1

The output should look like the following:


Several flags may only added or removed to files by the root user. In other cases, the file owner may set these flags. It is recommended an administrator read over the chflags(1) and chflags(2) manual pages for more information.

Directory Structure

The DragonFly directory hierarchy is fundamental to obtaining an overall understanding of the system. The most important concept to grasp is that of the root directory, /. This directory is the first one mounted at boot time and it contains the base system necessary to prepare the operating system for multi-user operation. The root directory also contains mount points for every other file system that you may want to mount.

A mount point is a directory where additional file systems can be grafted onto the root file system. This is further described in this Section. Standard mount points include /usr, /var, /tmp, /mnt, and /cdrom. These directories are usually referenced to entries in the file /etc/fstab. /etc/fstab is a table of various file systems and mount points for reference by the system. Most of the file systems in /etc/fstab are mounted automatically at boot time from the script rc(8) unless they contain the noauto option. Details can be found in this section.


Directory Description
/ Root directory of the file system.
/dev/ Device nodes; see intro(4).
/etc/ System configuration files and scripts.
/root/ Home directory for the root account.
/tmp/ Temporary files. The contents of /tmp are usually NOT preserved across a system reboot. A memory-based file system is often mounted at /tmp. This can be automated with an entry in /etc/fstab; see mfs(8).
/usr/ The majority of user utilities and applications.
/usr/include/ Standard C include files.
/usr/lib/ Archive libraries.
/usr/libdata/ Miscellaneous utility data files.
/usr/local/ Local executables, libraries, etc. Within /usr/local, the general layout sketched out by hier(7) for /usr should be used. An exceptions is the man directory, which is directly under /usr/local rather than under /usr/local/share.
/usr/pkg Used as the default destination for the files installed via the pkgsrc® tree or pkgsrc packages (optional). The configuration directory is tunable, but the default location is /usr/pkg/etc.
/usr/pkg/xorg/ Xorg distribution executables, libraries, etc (optional).
/usr/pkgsrc The pkgsrc tree for installing packages (optional).
/usr/share/ Architecture-independent files.
/var/log/ Miscellaneous system log files.
/var/mail/ User mailbox files.
/var/yp NIS maps.

Disk Organization





So far this is probably similar to any other operating system you may have used. There are a few differences; for example, MS-DOS® and Windows® use \.












The fstab File



device       mount-point   fstype     options      dumpfreq     passno

These parameters have the following meaning:


The mount Command


In its most basic form, you use:

# mount device mountpoint

Or, if mountpoint is specified in /etc/fstab, just:

# mount mountpoint


Mount Options


The umount Command




Choosing File System Layout



Benefits of Multiple File Systems

Disk Slices, Partitions and local UNIX file systems

* Heavily edited by Nick Matavka*

DragonFly BSD divides disks into partitions and slices; it refers to locations on a disk by means of their unique codes. For instance, the disk code ad1s3d has a clear meaning: IDE hard disk one, slice three, root file system. Meanings for other such codes will become apparent by the end of this section; first of all come the meanings for the physical drive codes. The most common are:

Code Meaning
ad ATAPI (IDE) disk
da SCSI direct access disk
vn Virtual disk
fd Floppy disk


In BSD UNIX, including DragonFly, what are elsewhere known as partitions are instead known as slices; on a multi-boot system, every operating system occupies at least one slice and is aware of the others. Linux, and most UNIX operating systems, generally occupy at least two slices, one for the file system and one for swap space; on the other hand, BSD (with the exception of MacOS/DarwinBSD) may occupy only one slice, using an alternative method (called partitioning in BSD) to segregate file system and swap space. Programs such as parted and gparted, contrary to their names, are in fact disk slicers.

In DragonFly, disk slices are designated with the letter s for slice and a positive integer, beginning either from zero or one, depending on the slicing scheme. The first slice of a physical disk is thus named s0; the second, s1; and so on. There can only be four physical slices on a disk, but one of these, designated the extended slice, may itself be sliced into logical slices. If an extended slice exists, the logical slices it contains are numbered beginning with s5.

For instance, the disk ad6 may be divided into physical slices ad6s1, ad6s2 (the extended slice, containing logical slices ad6s5 and ad6s6), and ad6s3. Note that if there are less than four physical slices, the relevant numbers are skipped, even if there are logical slices.

DragonFly support two schemes for slices, MBR and GPT. Either of them can manage all of the slices on a disk:

NOTE: DragonFly doesn't support booting from a GPT slice in DragonFly 2.0. DragonFly 2.1 does have some support for booting from a GPT slice, this is described in gpt(8).


Uniquely in BSD, disk slices contain disklabel partitions, not to be confused with the word partition in its usual meaning (that kind of partition is called a slice in BSD). In most variants of UNIX, at least two slices are used to contain the system: one for the primary file system, and one for swap space. With one exception, BSD can dispense with slices entirely and use a utility known as disklabel (or bsdlabel) to partition the disk instead.

All BSD UNIX operating systems support eight partitions per slice, labelled a through h; most BSD systems, DragonFly included, support an additional eight, labelled i through p, for a total of sixteen per slice. Partition layout is defined in a label on the slice where they reside. Since each partition may have its own file system, in BSD, one slice may be formatted in several different file systems (a situation that does not hold true in Linux or Windows).

Partition layout is defined in a label on the slice where the partition reside. DragonFly support two types of disk labels, disklabel32 and disklabel64 (the default):

By convention, four partition labels are reserved by the system and have special meanings. The convention does not strictly have to hold true, but it is highly recommended to follow this gentleman's agreement:

Partition Convention
a Normally contains the root file system
b Normally contains swap space
c Normally the same size as the enclosing slice. This allows utilities that need to work on the entire slice (for example, a bad block scanner) to work on the c partition. You would not normally create a file system on this partition. This is not necessarily true; it is possible to use the 'c' partition as a normal partition.
d Normally the same size as the entire physical disk. This is now rare, but to this day, some tools may operate oddly if told to work on partition d.

Local UNIX file systems

Each partition can contain only one file system. Therefore, file systems often are described by either their typical mount point in the file system hierarchy, or the letter of the disklabel partition they are contained in. DragonFly BSD supports two local UNIX file systems, UFS and HAMMER:

Historically, the desirability of HAMMERfs increased with storage capacity. For booting DragonFly from a small, local file system, UFS was previously recommended, with the option of a BOOT+HAMMER set up (512 MB UFS boot partition, the rest HAMMERfs). For moderate storage requirements, UFS continued to be an option, but the extra features boasted by HAMMERfs (such as history retention) made it more desirable in this regard.
Then, as now, HAMMERfs was the unrivalled king of the large partition, usually with a disklabel64(8) label on a GPT slice.

As of DragonFly version 3.6, this question is mostly, or entirely, of academic interest. HAMMERfs is now recommended for all volumes greater than eighty gigabytes---that is to say, all volumes manufactured within the last five years, and a goodly portion of older ones as well.

The HAMMER File System

HAMMER(5) is a rather new file system, under active development. HAMMERfs reached beta in release 2.0. As of release 2.2.1, HAMMERfs is considered to be appropriate for use in the production environment; DragonFly is currently in release 3.6.

If you are deploying DragonFly on a low-capacity, low-memory system, you should evaluate if HAMMERfs is suitable for your needs; for a personal computer or server of even medium vintage, no thought need go into this, as it will be found that HAMMERfs is the file system of choice. HAMMER(5) has several advanced features not found in UFS:

All these features are subordinate to the single, basic, overarching purpose of the HAMMER file system: full history retention. With HAMMERfs, all file system changes are saved every ~30 seconds. Changes are written at least when sync() is called (see syncer(4)). Every time data are written to disk, a transaction is completed, this is assigned an identifier, and the file updated can after this be accessed with the contents from this moment.

To access the file as it was then, all the user must do is add the transaction identifier to the file name, in the form file@@<tid>. The TID can be saved from the snapshot, cleanup, or synctid hammer(8) command, or looked up with the hammer history file command. This history will typically grow over time, so any disk will fill up over time.

Two things are done so the disk does not fill up too fast, or too much. First of all, at least moderately large disks are used. Second, HAMMER can be made self-managing with a policy for which history to save for how long. For example, make a snapshot every hour and prune and reblock (hammer(8)) regularly. When snapshots get older than one month, keep them for six hours; when older than three months, keep them for a day; when older than three years, keep them for a month.

Historically, you needed to set up cron(8) jobs for this yourself, but HAMMER now includes a utility to make this easy.

Adding a Disk

Adding a disk is done by installing it physically and by connecting it to a disk controller supported by DragonFly BSD. If you are in doubt as to whether a particular disk controller is supported, the manual pages for disk controllers can be consulted (man -k disk or man -k scsi can be of help). Another, easier way of ascertaining support for a controller is to boot with the controller installed, and note if the boot messages contain the controller.

Assuming that disk ad6 is installed, we could set it up the old-fashioned way, using fdisk(8) and disklabel(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel&section8) or the modern way, with gpt(8) and disklabel64(8), or any combination thereof.

In this example, we chose gpt(8) and disklabel64(8).

# gpt -v create ad6
# gpt add -s1 ad6
# gpt add ad6
# gpt show ad6

In the above example, we first create the GPT and then add two slices. The first slice added is ad6s0, which is made a dummy slice of size 1 sector. The reason for this is backwards compatibility: veteran users may remember that s0 has special meaning in MBR slice schemes, but this is not true in GPT slices. The second slice, ad6s1, will cover the rest of the disk:

# disklabel64 -rw ad6s1 auto
# disklabel64 -e ad6s1          # edit label to add partitions as needed






% ps

  298  p0  Ss     0:01.10 tcsh
48630  p0  S      2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi
72210  p0  R+     0:00.00 ps
  390  p1  Is     0:01.14 tcsh
 6688  p3  IWs    0:00.00 tcsh
10735  p4  IWs    0:00.00 tcsh
20256  p5  IWs    0:00.00 tcsh
  262  v0  IWs    0:00.00 -tcsh (tcsh)




% top
47 processes:  1 running, 46 sleeping





Daemons, Signals, and Killing Processes


We call these programs daemons. Daemons were characters in Greek mythology; neither good or evil, they were little attendant spirits that, by and large, did useful things for mankind. Much like the web servers and mail servers of today do useful things. This is why the mascot for a number of BSD-based operating systems has, for a long time, been a cheerful looking daemon with sneakers and a pitchfork.

There is a convention to name programs that normally run as daemons with a trailing d. BIND is the Berkeley Internet Name Daemon (and the actual program that executes is called named), the Apache web server program is called httpd, the line printer spooling daemon is lpd and so on. This is a convention, not a hard and fast rule; for example, the main mail daemon for the Sendmail application is called sendmail, and not maild, as you might imagine.

Sometimes you will need to communicate with a daemon process. These communications are called signals, and you can communicate with a daemon (or with any other running process) by sending it a signal. There are a number of different signals that you can send--some of them have a specific meaning, others are interpreted by the application, and the application's documentation will tell you how that application interprets signals. You can only send a signal to a process that you own. If you send a signal to someone else's process with kill(1) or kill(2) permission will be denied. The exception to this is the root user, who can send signals to everyone's processes.

DragonFly will also send applications signals in some cases. If an application is badly written, and tries to access memory that it is not supposed to, DragonFly sends the process the Segmentation Violation signal (SIGSEGV). If an application has used the alarm(3) system call to be alerted after a period of time has elapsed then it will be sent the Alarm signal (SIGALRM), and so on.


SIGKILL can not be ignored by a process. This is the I do not care what you are doing, stop right now signal. If you send SIGKILL to a process then DragonFly will stop that process there and then(1).




Sending a Signal to a Process



    % ps -ax | grep inetd
    198  ??  IWs    0:00.00 inetd -wW

    So the inetd(8) PID is 198. In some cases the grep inetd command might also occur in this output. This is because of the way ps(1) has to find the list of running processes.


    % su
    # /bin/kill -s HUP 198

    In common with most UNIX® commands, kill(1) will not print any output if it is successful. If you send a signal to a process that you do not own then you will see kill: PID: Operation not permitted. If you mistype the PID you will either send the signal to the wrong process, which could be bad, or, if you are lucky, you will have sent the signal to a PID that is not currently in use, and you will see kill: PID: No such process.











Variable Description
USER Current logged in user's name.
PATH Colon separated list of directories to search for binaries.
SHELL The current shell.
TERM The name of the user's terminal. Used to determine the capabilities of the terminal.
OSTYPE Type of operating system. e.g., DragonFly.
MACHTYPE The CPU architecture that the system is running on.
EDITOR The user's preferred text editor.
PAGER The user's preferred text pager.
MANPATH Colon separated list of directories to search for manual pages.


% setenv EDITOR /usr/pkg/bin/emacs

Under Bourne shells:





Changing Your Shell



% chsh -s /usr/pkg/bin/bash




Then rerun chsh.

Text Editors

A lot of configuration in DragonFly is done by editing text files. Because of this, it would be a good idea to become familiar with a text editor. DragonFly comes with a few as part of the base system, and many more are available in the pkgsrc® tree.


DragonFly also comes with more powerful text editors such as vi as part of the base system, while other editors, like emacs and vim , are part of the pkgsrc tree. These editors offer much more functionality and power at the expense of being a little more complicated to learn. However if you plan on doing a lot of text editing, learning a more powerful editor such as vim or emacs will save you much more time in the long run.

Devices and Device Nodes

A device is a term used mostly for hardware-related activities in a system, including disks, printers, graphics cards, and keyboards. When DragonFly boots, the majority of what DragonFly displays are devices being detected. You can look through the boot messages again by viewing /var/run/dmesg.boot.


Most of these devices in a UNIX® operating system must be accessed through special files called device nodes, which are located in the /dev directory.

The device nodes in the /dev directory are created and destroyed automatically on DragonFly >= 2.4, by means of the device file system (devfs).

Binary Formats

To understand why DragonFly uses the elf(5) format, you must first know a little about the three currently dominant executable formats for UNIX®:





For More Information

Manual Pages


% man command


% man ls

The online manual is divided up into numbered sections:

  1. User commands.
  2. System calls and error numbers.
  3. Functions in the C libraries.
  4. Device drivers.
  5. File formats.
  6. Games and other diversions.
  7. Miscellaneous information.
  8. System maintenance and operation commands.
  9. Kernel internals.


% man 1 chmod



% man -k mail

With this command you will be presented with a list of commands that have the keyword mail in their descriptions. This is actually functionally equivalent to using the apropos command.


% cd /usr/bin
% man -f *


% cd /usr/bin
% whatis *

which does the same thing.

GNU Info Files

DragonFly includes many applications and utilities produced by the Free Software Foundation (FSF). In addition to manual pages, these programs come with more extensive hypertext documents called info files which can be viewed with the info command or, if you installed emacs , the info mode of emacs . To use the info(1) command, simply type:

% info
