System Operation


This section covers the basics of how the system functions and how you can make intelligent decisions as a system administrator. It does not cover every aspect of system administration in the depth necessary to set up or modify all system functions. Instead, it provides a guide to bringing a system up and keeping it running from day to day.

The way that system services run changed from OS X version 10.3 to version 10.4. Version 10.3 used init for system startup and launched services (daemons) using xinetd. Some services ran constantly in the background. Under version 10.4 and later, system startup and all daemons are run by launchd. This section describes how systems running OS X 10.4 and later work.

Booting the System

Booting a system is the process of reading the Mac OS X kernel (page 939) into system memory and starting it running. Although it is unlikely that you will need to do so, you can use the Startup Disk preference pane of System Preferences to modify the boot procedure.

OS X 10.4 and later

As the last step of the boot procedure, Mac OS X 10.4 runs the launchd program as PID number 1. The launchd program is the first genuine process to run after booting and is the parent of all system processes.

OS X 10.3 and earlier

Mac OS X 10.3 loads mach_init, which in turn loads init as well as any programs found in /etc/mach_init.d. System scripts, such as /etc/rc, are run by init and start other programs, such as xinetd, which provide services. The init program is the first genuine process to run after booting and is the parent of all system processes.

Startup Scripts

The first script that launchd runs is /etc/rc, the system startup script. This script checks the disks, starts system services, loads drivers, and so on. However, it is only part of the system startup process. Exactly what this script does depends on the system configuration. For example, on a system that is netbooting, rc runs the /etc/rc.netboot script, which handles network startup. If the /etc/rc.local file exists, /etc/rc runs it.

Because Apple has announced plans to phase out the rc script, avoid making changes to /etc/rc or using /etc/rc.local. If you want to add new services, set up a new launchd job (page 456) or create a new system startup item by copying and modifying the code of an existing item in /System/Library/StartupItems. Put your item in /Library/StartupItems to avoid conflicts with system startup items.

Most system services are started by launchd. Services that run on demand or at regular intervals are run from launchd. SystemStarter starts the services found in /Library/StartupItems and /System/Library/StartupItems and that must be launched in a particular order, as well as those that are dependent on other services.

Tip: List the kernel boot messages

As the system comes up, the kernel generates messages. To save the list of kernel boot messages, give the following command immediately after booting the system and logging in:

$ dmesg > dmesg.boot 


This command saves the kernel messages in the dmesg.boot file. This list can be educational. It can also be useful when you are having a problem with the boot process. For more information refer to dmesg on page 717.


No runlevels

Unlike Linux and System V UNIX systems, OS X does not have multiple runlevels. It can come up in single-user mode (where services are not started) or in multiuser mode (where services are started). Instead of a set of directories containing scripts to run when entering each runlevel, OS X uses configuration files to specify when each service should be started. Typically you do not need to modify these files.

You can enable and disable most system services from the Services tab of the Sharing preference pane. Making changes here affects the /etc/hostconfig file and certain files in the /System/Library/StartupItems, /System/Library/LaunchAgents, and /System/Library/Launch-Daemons directories. Other services are controlled through launchd's configuration files (page 456) and the files in the StartupItems directories.

Single-User Mode

You can put a Mac OS X system into single-user mode by holding down COMMAND-S while it is booting. When the system is in single-user mode, only the text console (page 35) is enabled. You can run programs from the console in single-user mode as you would from any terminal in multiuser mode. The differences are that not all filesystems may be mounted, so you may not be able to access some files, and few of the system daemons will be running. In single-user mode, the root filesystem (startup volume) is mounted readonly, so you cannot modify any files. If you need to modify files (for instance, to fix a configuration problem that prevents the system from booting normally), you must mount the required filesystem for both reading and writing.

If you need to modify a file on the root filesystem, you must remount it in read-write mode. Before you remount it, you should check it for errors. Although fsck is deprecated for most uses, Apple recommends using it to check filesystems for errors and correct errors in single-user mode:

# /sbin/fsck -fy 


Once you have checked the root filesystem, you can remount it in read-write mode using the mount utility:

# /sbin/mount -uw / 


The u (update) option causes mount to change the state of a mounted filesystem, not mount an unmounted filesystem. The w (write) option specifies the state to change; it mounts the filesystem in read-write mode.

With the system in single-user mode, you can perform system maintenance that requires either unmounted filesystems or just a quiet systemno one except you using it, so that no user programs interfere with disk maintenance and backup programs. The classical UNIX term for this state is quiescent.

Going Multiuser

After you have determined that all is well with all filesystems, you can bring the operating system up to multiuser mode. When you exit from the single-user shell, launchd brings the system up to multiuser mode. When it goes from single-user to multiuser mode, the system runs the /etc/rc script as described in "Startup Scripts" on page 436.

Multiuser Mode

Multiuser mode is the normal state for a Mac OS X system. All appropriate filesystems are mounted and users can log in from all connected terminals, dial-up lines, and network connections. All support services and daemons are enabled and running. Once the system is in multiuser mode, you will see a login screen or prompt. By default OS X systems are set up to boot directly to multiuser mode without stopping at single-user mode. By default non-Server OS X systems skip the login screen and log in the first user account automatically.

Logging In

The system launches the graphical login window by defaultyou have to request the text console if you want a textual login. For more information refer to "More About Logging In" on page 34 and "Logging In on the Text Console" on page 35.

OS X uses PAM (page 466), the Pluggable Authentication Module facility, which gives you a great deal of control over user logins and authentication. Using PAM, you can specify multiple levels of authentication, mutually exclusive authentication methods, or parallel methods, each each of which is sufficient to grant access to the system. For example, you can have a different authentication method for console logins and for network logins. You can require that modem users authenticate themselves via two or more methods (such as a smartcard or badge reader and a password). PAM modules also provide security technology vendors with a convenient way to integrate their hardware or software products into a system.

The default PAM configuration on Mac OS X uses NetInfo (page 441) for account and password verification. All passwords in the NetInfo database are encrypted or hashed. It is not feasible to recover an encrypted password. When you log in, the login process encrypts/hashes the password you type at the prompt and compares it to the encrypted/hashed password in the database. If it matches, you are authenticated.

Textual login

With a textual login, launchd starts a getty process, which displays a login: prompt. When you enter your username, getty establishes the characteristics of your terminal. It then overlays itself with a login process and passes to the login process whatever you entered in response to the login: prompt. Next login prompts you for a password and verifies the password you enter. If either your username or your password is not correct, login displays Login incorrect and prompts you to log in again.

Graphical login

With a graphical login, the launchd process spawns loginwindow on the console, providing features similar to getty and login. The loginwindow utility presents a login window, then uses PAM to authenticate the user. If the user is authenticated, the loginwindow program brings up the Finder and any programs configured to be started automatically upon login. These programs are controlled through the Login Items tab of the System Preferences Accounts pane.

Whether you are using login or loginwindow, the program handling your login assigns values to the HOME, PATH, LOGNAME, SHELL, and TERM variables. It looks in the NetInfo group database to identify the groups you belong to. When the program has finished its work, it overlays itself with the login shell (for a textual login) or the Finder (for a graphical login), which inherits these variables.

During a textual login, the login shell assigns values to additional shell variables and executes the commands in the system startup shell scripts /etc/profile and /etc/bashrc (or, if you are using tcsh, /etc/login and /etc/cshrc).

After executing the system startup commands, the shell executes the commands from the personal startup shell scripts in your home directory (page 259). Because the shell executes these scripts after the system scripts, a sophisticated user can override any variables or conventions that were established by the system, whereas a new user can remain uninvolved in these complications.

Periodic Tasks

OS X performs many system maintenance functions periodically. These tasks are handled by the /etc/daily, /etc/weekly, and /etc/monthly shell scripts. The daily script is run at 3:15 every morning, the weekly script at 3:15 on Saturday mornings, and the monthly script at 5:30 on the morning of the first day of each month. These scripts are launched by launchd under version 10.4 and later, and by cron on earlier systems.

Each of these scripts checks for a corresponding local script file containing additional maintenance tasks and runs these scripts using /bin/sh. The local files have .local filename extensions. For example, /etc/daily checks for a script named /etc/daily.local.

Running a Program and Logging Out

When OS X displays a shell prompt, you can execute a program or exit from the shell. If you exit from a shell, the process running the shell dies and the parent process wakes up. When the shell is a child of another shell, the parent shell wakes up and displays a prompt. Exiting from a login shell causes the operating system to send launchd a signal that one of its children has died. Upon receiving this signal, launchd takes action based on the contents of the /etc/ttys file. In the case of a process controlling a line for a terminal, for example, launchd informs getty that the line is free for another user.

When you are using a graphical login and exit from the GUI, launchd starts a new loginwindow session to allow a new login.

Bringing the System Down

The shutdown and halt utilities perform the tasks needed to bring the system down safely. These utilities can restart the system, prepare the system to be turned off, put the system in single-user mode, and, on some hardware, power down the system. The reboot utility is linked to halt. The shutdown utility calls halt to actually perform the system shutdown, but only after sending messages to any users logged in on textual devices. A user on the graphical console is not warned by the system and must be warned manually.

Caution: shutdown may not save your work

Unlike the Shut Down option on the Apple menu, the shutdown and halt utilities do not check with applications to see whether it is safe to shut the system down. If you are running a GUI, use the Shutdown option on the Apple menu to bring the system down.


You must tell shutdown when you would like to bring the system down. The time can be expressed as an absolute time of day, as in 19:15, which causes the shutdown to occur at 7:15 P.M. Alternatively, you can give the number of minutes from the present time, as in +15, which means 15 minutes from now. To bring the system down immediately (recommended for emergency shutdowns only or when you are the only user logged in), you can give the argument +0, or its synonym: now. Non-root logins are disabled 5 minutes before shutdown, or immediately if shutdown is sooner than that.

Calling shutdown with the r option causes the system to reboot (same as the reboot command except that reboot implies now). Using h instead of r forces the system to halt (same as the halt command except that halt implies now). A message appears once the system has been safely halted: System halted. Normally, however, the system will power off, preventing you from seeing the message.

Because Mac OS X is a multiuser system, shutdown warns textual users before taking any action. This warning gives users a chance to prepare for the shutdown, perhaps by writing out editor files or exiting from networking applications. You can replace the default shutdown message with one of your own by following the time specification on the command line with a message:

# /sbin/shutdown -h 09:30 Going down 9:30 to install disk, up by 10:00 am. 


Caution: Do not turn the power off before bringing the system down

Avoid rebooting a system without first bringing it down as described here. OS X, like other UNIX and UNIX-like systems, speeds up disk access by keeping an in-memory collection of disk buffers that are written to the disk periodically or when system use is momentarily low. When you turn off or reset the computer without writing the contents of these disk buffers to the disk, you lose the information held in the buffers. Running shutdown forces these buffers to be written. You can force the buffers to be written at any time by issuing a sync command. However, sync does not unmount filesystems, nor does it bring the system down.


Going Single-User

The only way to put an OS X system in single-user mode is to boot or reboot into it. You cannot go directly from multiuser to single-user mode as you can on some UNIX systems. For more information refer to "Single-User Mode" on page 437.

Turning the Power Off

Shutting the system down is quite straightforward: Give the command halt to bring the system down. This is equivalent to selecting Shut Down from the Apple menu. Running halt requires root privileges.

Crash

A crash occurs when the system suddenly stops or fails when you do not intend it to do so. A crash may result from software or hardware problems or from a loss of power. As a running system loses power, nothing is regular or predictable. In a fraction of a second, some components are supplied with enough voltage; others are not. Buffers are not flushed, corrupt data may be written to the hard disk, and so on. IDE drives do not behave as predictably as SCSI drives under these circumstances. After a crash, you must bring the operating system up carefully to minimize possible damage to the filesystems. Frequently there will be little or no damage, and the system will recover without any help beyond pressing the power button.

On a Macintosh, a crash frequently indicates a hardware problem. Third-party utilities are available for testing and diagnosing hardware problems. One such tool is TechTool Pro (www.micromat.com).

Repairing a Filesystem

Although the filesystems are checked automatically during the boot process if needed, you will have to check them manually if a problem cannot be repaired automatically. To check the filesystems manually after a crash, use the Disk Utility application or the diskutil command line utility (both perform the same function).

If a file is corrupt or missing, you will have to restore it from a backup.

When the System Does Not Boot

When you cannot boot the computer from the hard drive, you may need to rerun the Mac OS X installer from the disks that came with the computer. There are several ways to reinstall the operating system. Be careful to choose the technique that does not erase your data.




A Practical Guide to UNIX[r] for Mac OS[r] X Users
A Practical Guide to UNIX for Mac OS X Users
ISBN: 0131863339
EAN: 2147483647
Year: 2005
Pages: 234

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net