HP-UX 10.0 File system layout

HP-UX 10.0 File System Layout White
Version 2.3
Last Modification: March 23, 1995
© Copyright 1994, 1995, 1996 and 1997 Hewlett-Packard Company
Legal Notices
The information contained within this document is subject to change
without notice.
Hewlett-Packard shall not be liable for errors contained herein or for
incidental consequential damages in connection with the furnishing,
performance, or use of this material.
Warranty. A copy of the specific warranty terms applicable to your
Hewlett-Packard product and replacement parts can be obtained from
your local Sales and Service Office.
Restricted Rights Legend. Use, duplication, or disclosure by the U.S.
Government Department is subject to restrictions as set forth in
subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.227-7013 for DOD agencies, and
subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software
Restricted Rights clause at FAR 52.227-19 for other agencies.
Copyright Notices. (C)copyright 1983-97 Hewlett-Packard Company, all
rights reserved.
This documentation contains information which is protected by
copyright. All rights are reserved. Reproduction, adaptation, or
translation without written permission is prohibited except as allowed
under the copyright laws.
(C)Copyright 1981, 1984, 1986 UNIX System Laboratories, Inc.
(C)copyright 1986-1992 Sun Microsystems, Inc.
(C)copyright 1985-86, 1988 Massachusetts Institute of Technology.
(C)copyright 1989-93 The Open Software Foundation, Inc.
(C)copyright 1986 Digital Equipment Corporation.
(C)copyright 1990 Motorola, Inc.
(C)copyright 1990, 1991, 1992 Cornell University
(C)copyright 1989-1991 The University of Maryland.
(C)copyright 1988 Carnegie Mellon University.
Trademark Notices. UNIX is a registered trademark in the United
States and other countries, licensed exclusively through X/Open
Company Limited.
NFS is a trademark of Sun Microsystems, Inc.
OSF and OSF/1 are trademarks of the Open Software Foundation, Inc. in
the U.S. and other countries.
First Edition: March 1995 (HP-UX Release 10.0) Second Edition: April
1995 (HP-UX Release 10.0)
Chapter 1
With the release of HP-UX 10.0, Hewlett-Packard introduced many new
features for the HP9000 UNIX operating system. One of these is a new
file system layout paradigm, modeled after AT&T SVR4 and OSF/1. The
model provides many benefits such as separating the operating system
from applications, providing a solid foundation for diskless and client/
server file sharing models, and aligning HP with an industry-accepted
file system layout. There are two main areas affected by the new file
system layout: file/directory locations and system start-up/shutdown
control. As easy as this sounds, all software developers will be faced with
design decisions when moving to the new model. The file system layout is
a core technology upon which the operating system is built. Applications
running on HP-UX 10.x may need to make modifications to their
products that enable them to correctly function within the new file
system model.
Although the file system paradigm is modeled after AT&T SVR4 and
OSF/1, HP is not implementing either of these operating systems with
Release 10.0. Rather, HP has implemented the file system model within
Chapter 1
Purpose of Document
Purpose of Document
This document is intended to explain the HP-UX 10.x file system layout,
along with its benefits and impacts to software developers and users.
After reading this document, a person should be able to:
• articulate the reasoning for implementing the new file system layout.
• assess the impacts of file system layout to products and/or user
• design, build, and test the changes necessary to comply with the new
file system layout.
Chapter 1
This document is intended for HP-UX software developers, system
administrators, site system planners, and users, both internal and
external to Hewlett-Packard.
Chapter 1
Within the computer industry, this file system layout is referenced by
many different names: “AT&T SVR4 File System”, “V.4 File System”,
“OSF/1 File System”, and “V4FS”. For the purposes of this document, the
product will be referred to as the “HP- UX 10.x File System Layout” and
“10FSL”. All references in this paragraph refer to the same topic and
may be used interchangeably. However, implementations among vendors
will differ.
Chapter 1
Terms and Definitions
Terms and Definitions
Please refer to the Glossary section (at the end of this paper) for terms
and definitions used throughout this document.
Chapter 1
Related Documentation
Related Documentation
The following is a list of references used to design the HP-UX 10FSL.
The reader is encouraged to consult them for more information:
1. filesys(BA_ENV) manpage
System V Interface Definition, Third edition, Volume 1
Page 5-40, UNIX Press, UNIX System Laboratories, Inc., 1992
2. hier(5) manpage
OSF/1 Release 1.0 Programmer’s Reference Manual
Page 3-6, Open Software Foundation, Inc., Nov. 1990
3. hier(5) manpage
HP-UX Reference, Volume 3, Release 9.0
Pages 816-819, Hewlett-Packard Company, August 1992
Chapter 1
Related Documentation
Chapter 1
The New File System Layout
The New File System Layout
This chapter explains the 10.x File System Layout (10FSL) and outlines
the differences between HP-UX Releases 9.x and 10.x. All of the changes
apply to both S700 and S800 computer systems. These differences will
affect software developers, system administrators, and end users of HPUX. For users of HP-UX, the changes will be seen primarily as new
locations of many files and directories. For administrators, more changes
will be apparent, including new configuration files and a new paradigm
for system start-up and shutdown scripts. For software developers,
application behavior may need to be restructured to conform to the new
These topics are covered in the following sections:
• Introduction: the rationale for, and an overview of, the layout.
• File System Layout Specification: the specification of the new layout.
• Applications: file system specifications for applications (non-OS
• General Impacts to Developers and Users: explanation of affected
• Solutions to Commonly Asked Questions: task-oriented solutions to
common questions.
Chapter 2
The New File System Layout
2.1 Introduction
2.1 Introduction
2.1.1 Philosophy of the New Layout
The 10.x file system layout is similar to the OSF/1 and SVR4 layout.
Important features of the HP-UX 10.x file system layout include:
• The overall layout is based on a defacto industry standard.
Customers with inter-vendor networks will find the HP-UX file
system to be similar to that used by other vendors. When supporting
multiple platforms, developers will require fewer HP-UX-specific
• Files are organized by various categories, such as static vs. dynamic,
executable vs. configuration data, etc. This provides a logical
structure to the file system, as well as providing the benefits listed in
the following items.
• The operating system is kept separate from the applications on the
system, and applications are kept separate from each other. This
facilitates a manageable client/server file sharing model.
• Files that may be shared among hosts are kept separate from files
that pertain only to a particular host. This facilitates sharing file
system hierarchies over a network for both the diskless and client/
server models.
• Configuration data, which is host-specific, is kept separate from the
executable code that uses the data, allowing the code to be shared
among hosts. In addition, since configuration data never appears in
the same file as the code that uses it, changes made by the customer
to the configuration data are not lost when installing future HP-UX
• Important system configuration data is kept separate from temporary
files, log files, and other by-products of system execution that are not
required for correct operation of the system. This eases the tasks of
system backups and disk space administration.
• The portion of the file system that is allowed to “grow” is restricted to
a manageable subset of directories, simplifying the task of disk space
Chapter 2
The New File System Layout
2.1 Introduction
Although the 10.x file system layout is based on the OSF/1 and V.4 file
system layouts, it is not a “pure” implementation of either of these
layouts. Industry compatibility is of great importance. However, it is
important to note that all of the major vendors supporting V.4 have
slightly different implementations and their respective documentation
should be consulted.
2.1.2 File System Layout Overview
One of the primary benefits of the 10.x file system layout is that it
categorizes and groups together files by functionality (static, dynamic,
executable, configuration information, etc.). This organization is depicted
in Figure 2-1.
Figure 2-1
Generic File System Model
Static Files
System Startup
Dynamic Files
Chapter 2
The New File System Layout
2.1 Introduction
In the above figure, files are primarily categorized as static and dynamic.
Dynamic files, which include files like log and configuration files, are
further categorized by functionality (configuration, temporary, and user).
A similar division is possible with the static files, where files may be
categorized by three functionalities: executable, library and system
start-up. File types can further subdivided into user or system, OS or
Application, etc., as illustrated in the figure above.
This grouping of files also supports the diskless paradigm by arranging
the file system in a manageable fashion and allowing a clean sharing of
file system resources in a client/server environment. In the diskless
paradigm, directories are considered shared among clients (such as
executables) or private to a client (for example, configuration and
temporary files). This shared vs. private distinction conforms well to the
static vs. dynamic distinction given above; in 10.x, static files are shared,
while dynamic files are private. Figure 2-2 represents the directory tree
of the 10.x file system layout, showing this private/dynamic vs. share/
static distinction.
Chapter 2
The New File System Layout
2.1 Introduction
Figure 2-2
The tree
Chapter 2
The New File System Layout
2.1 Introduction
The static (shared) subdirectories are:
• /usr-- OS commands, ksh, vi, libraries
• /sbin -- minimum commands to boot and mount other filesystems
the application subdirectories of /opt
The dynamic (private) subdirectories are:
• /opt -- applications
• /home -- user directories
• /etc -- system configuration (no programs!)
• /stand -- kernel, boot loader
• /dev -- device files
• /tmp -- OS temporary files
• /var -- dynamic info logs, spooler
• /mnt -- local mounts
2.2 File System Layout Specification
This section describes the differences in the layout between HP-UX
Release 9.x and 10.x.
2.2.1 General Definitions
The following are general rules for the new layout:
• The shareable portion of the OS resides beneath /usr and /sbin.
Only the operating system may install files into these hierarchies.
• Applications reside in subdirectories beneath /opt. This is the
recommended install point for applications.
• Directories /usr, /sbin, and the application subdirectories of /opt
are shareable among networked hosts. These hierarchies must not
contain host-specific information. All host-specific configuration data,
temporary files, log files, and other files inappropriate for sharing
among hosts must reside in private directories on the file system. The
private directories include /etc, /var, /tmp, /stand, /home.
Chapter 2
The New File System Layout
2.1 Introduction
• The /etc directory is used exclusively for host-specific configuration
data essential to the correct operation of the system. This directory no
longer holds executable commands.
• The /var hierarchy contains host-specific files created during
execution of the system that are not essential configuration
information. Examples of files that reside here are log files,
temporary files, and printer spool files.
• The /home directory is the root for all users' home directories.
• The /export directory is the root for sharable, networked file
systems, such as NFS exported directories.
10.x Directory Definitions
The following table outlines most of the directories found in the HP-UX
file system. For each directory, it shows the old directory name, where
applicable, and the associated use for the directory. The last column of
the table indicates whether the directory is shared among members of a
cluster or is private to the host. Each directory is explained in detail in
Section 2.2.3, “Directory Details”.
Table 2-1
HP-UX 10.x
HP-UX 10.x Directory Definitions
Pre-HP-UX 10.0
No Change
Device files for local devices
No Change
Machine-specific configuration
and administration databases.
No executables invoked by
configuration files
Start-up configuration files
Default root of exported file
Default root of exported file
Chapter 2
The New File System Layout
2.1 Introduction
HP-UX 10.x
Pre-HP-UX 10.0
For shared OS and applications
Default for user directories
User home directory
directory or
local mount
No Change
Storage directory for fsck
No Change
Mounting point for local file
No Change
Mounting point for remote file
Root for optional applications
Application executables,
libraries, and support files.
Essential system commands
(those needed to boot system
and mount file systems).
Start-up and shutdown scripts
Start-up and shutdown link
files for script sequencing.
Standalone machine-dependent
binaries and kernel configs.
No Change
System-generated temporary
No Change
Mount point for sharable user
commands, libraries, and
/usr/bin and /bin
OS user commands
Chapter 2
The New File System Layout
2.1 Introduction
HP-UX 10.x
Pre-HP-UX 10.0
Unbundled development
Development binaries
Development libraries
Kernel configuration
No Change
Contributed software.
No Change
Header files
Back-ends to other commands.
/usr/lib and /lib
Object code and object code
No Change
User contributed software
Default operating system
configuration data files.
Obsolete files
System administration
Architecture independent
sharable files.
Dictionaries for spell and ispell
Misc. sharable files.
OS manpages
Holds files created at run time,
such as log files and temporary
Common administrative files
and log files.
Chapter 2
The New File System Layout
2.1 Introduction
HP-UX 10.x
Pre-HP-UX 10.0
Kernel crash dumps
Cron queueing
SD directory
Files generated by syslog
Incoming mail
Application-specific temporary
or data files
Preserved editor files.
PID files
Spooled files.
Crontabs and at jobs.
UUCP Lock files.
Printer spooling.
Outgoing mail.
Default location for SD depot.
UUCP spool directory
Incoming UUCP files
Application generated
temporary files.
UUCP administration files
Chapter 2
The New File System Layout
2.1 Introduction
2.2.3 Directory Details
This section provides details on each of the directories listed in the
previous table. /dev
/dev is used for device files. The contents and meaning of /dev has not
changed. Nothing should be installed in /dev. Instead, configuration
files should create node-specific device files. /etc
The /etc hierarchy contains host-specific system and application
configuration files important to the correct operation of the system. Files
located here are usually fixed size and do not grow. By contrast, the /var
hierarchy holds files that are dynamic in length or are less critical to
system execution, such as log files. In general, /etc holds essential
information that must be preserved in order for the system to function
correctly, while /var holds information generated by the system that
may be disposed of when it is no longer of interest. Some customer sites
may choose to make automatic backups of the /etc hierarchy, but not of
/var.There will be subdirectories under /etc for some systems; for
example /etc/mail and /etc/uucp for the mail system and uucp
The /etc directory itself is used only for system configuration files. /etc
no longer contains commands, rc scripts, log files (with the exception of a
few critical log files), or other files not related to system configuration.
Most commands have moved to /usr/sbin. Rc scripts now reside in /
sbin/init.d and follow the new system start-up and shutdown
paradigm (see Section 3., “System Start-up/Shutdown Model”). Log files
and other miscellaneous files not related to system configuration are now
in /var. /etc/opt. Applications will store application-specific,
host-specific configuration data under /etc/opt/<application>. See
section 2.3, “Applications”, for more details. /etc/rc.config.d. This directory contains
configuration data files for start-up and shutdown scripts.
Chapter 2
The New File System Layout
2.1 Introduction /export
The directory is used to support diskless file sharing. Servers export root
directory hierarchies for networked clients. /home
User directories will be created and managed under /home instead of /
users. Nothing should be installed in /home. This is a portion of the file
system that is allowed to grow. /lost+found
/lost+found contains files located by fsck(1m). /mnt
Reserved name for mount points for local file systems. This is not an
install location (that is, nothing should be directly installed here from
HP update media). /mnt can be used as a mount point directory, or a
directory containing multiple mount points. /net
Reserved name for mount points for remote file systems. /opt
The root directory for optional applications. /opt is not a sharing point,
but rather, its subdirectories are sharing points. This allows one to
mount only those applications that make sense for a given machine or
release, rather than mounting all applications available on a server. No
files should be delivered into /opt, but rather into subdirectories of /
opt, as described below. /opt/<application>. The shareable portion of each optional
application resides in a hierarchy beneath a single subdirectory of /opt.
A uniform application structure is recommended, which consists of the
following standard set of directories under /opt/<application>: bin,
lib, man, help, lbin and newconfig for default configuration info. See
section 2.3, “Applications”, for more details.
Chapter 2
The New File System Layout
2.1 Introduction /sbin
/sbin contains the commands and scripts essential to boot and
shutdown a system. /sbin contains the commands required to bring the
system into a state in which the /usr filesystem can be mounted and the
boot process continued. /sbin also contains commands needed to fix
filesystem mounting problems.
Commands in /sbin must not depend on any filesystems that may not
be mounted at the time the command must execute, including the /usr,
/var, and /opt filesystems. Since shared libraries reside beneath /usr,
commands in /sbin are statically linked (that is, built with archived
libraries). Commands in /sbin must not execute any commands from
the /usr filesystem; only other /sbin executables may be referenced. If
a command referenced by an /sbin command is replicated between /
sbin and either /usr/bin or /usr/sbin, then the path to the
command must refer to the /sbin version.
Some commands in /sbin are duplicates of, or the target of symbolic
links from, other commands in /usr/bin and /usr/sbin. For example,
the ls command exists in both /sbin and /usr/bin. If a command in /
sbin is duplicated in either /usr/bin or /usr/sbin, the duplicate
exists to take advantage of shared libraries for most executions of that
command, or to provide full functionality if the /sbin version does not.
Some commands in /sbin do not offer the full functionality provided by
their /usr/bin or /usr/sbin counterparts. For example, some NLS
functionality that requires shared libraries is not present in the /sbin
versions of certain commands. For this reason, use of the /usr/bin or /
usr/sbin versions of replicated commands is preferred, when possible.
When constructing shell PATH variables that contain a /sbin
component, /sbin should appear after /usr/bin and/or /usr/sbin in
the path. /sbin/init.d and /sbin/rc#.d. /sbin/init.d contains all
rc scripts used to start-up and shutdown various subsystems./sbin/
rc#.d contains ordered symbolic links to rc scripts in /sbin/init.d
that are executed when changing run levels.
See Section 3, “System Start-up/Shutdown Model”, for more information.
Chapter 2
The New File System Layout
2.1 Introduction /stand
/stand is for system-specific kernel configuration and binary files. The
files are typically needed at boot time to bring up a system. This
directory is not an install point. /tmp
/tmp is for system-generated temporary files. The contents of /tmp are
usually not preserved across a system reboot. The choice of whether or
not /tmp is cleaned up at boot time is left to the customer.
The /tmp directory is private. Since many sites will delete files from /tmp
at boot time, files that must be preserved should not be placed in the /
tmp directory. Application working files should go in /var/tmp or /var/
opt/<application>. Files generated by the OS that must be preserved
across reboots should go into the /var/tmp directory. /usr
/usr contains the bulk of the operating system, including commands,
libraries and documentation. The /usr file system contains only
shareable operating system files, such as executables and ASCII
documentation. Multiple systems of compatible architectures should be
able to access the same /usr directories. /usr may be mounted as readonly by diskless clients, and thus may not be writable by clients.
The allowed subdirectories in /usr are defined below; no additional
subdirectories should be created. Any 9.x applications that resided in
other subdirectories in /usr have moved beneath the /opt hierarchy. /usr/bin. /usr/bin is used for common utilities and
applications. In general, commands documented in section 1 of the HPUX Reference Manual reside in /usr/bin, while commands documented
in section 1M reside in /usr/sbin. /usr/ccs. The minimal C compiler is located here. The
functionality is sufficient to build a kernel. The fully-functional C
compiler resides below /opt. /usr/conf. /usr/conf is a static directory containing the
sharable kernel build environment.
Chapter 2
The New File System Layout
2.1 Introduction /usr/contrib. This directory contains contributed software.
The 10.x layout has no changes to this directory. /usr/include. /usr/include contains header files. The
10.x layout has no changes to this directory. /usr/lbin. The /usr/lbin directory is intended for backends to commands in the /usr hierarchy. Commands such as /usr/
lib/divpage and /usr/lib/diff3prog are placed in /usr/lbin.
There are some subdirectories for special systems, such as /usr/lbin/
spell and /usr/lbin/uucp. /usr/lib. /usr/lib holds libraries and machine dependent
databases. In 10.x, most files that once resided in /lib now reside in /
usr/lib. There is no /lib directory; code referencing /lib should be
changed to reference the correct path. /usr/local. /usr/local is for site local files, including
binaries, libraries, sources, and documentation. HP will deliver this
directory empty and not install software here. /usr/newconfig. This directory contains default operating
system configuration data files.
Files that once resided in /etc/newconfig might now reside in /usr/
newconfig or /opt/<application>/newconfig. The structure of /usr/
newconfig is different than that of /etc/newconfig: /usr/
newconfig contains a directory hierarchy somewhat mirroring that of /
. /usr/old. During an operating system update, this
directory is used for host customization. System files being replaced by
files in /usr/newconfig, will be moved here. It is also used to hold old
versions of software for compatibility with a previous release. /usr/old
contains a directory hierarchy somewhat mirroring that of /. /usr/sbin. The directory /usr/sbin is for system
administration related commands. Many of the commands previously in
/etc have moved to this directory. In general, commands documented in
section 1M of the HP-UX Reference Manual are in /usr/sbin.
Chapter 2
The New File System Layout
2.1 Introduction /usr/share. This hierarchy contains architectureindependent sharable files that can be shared among various
architectures (for example, terminfo files). /usr/share/dict. This directory contains spell and ispell
dictionaries. /usr/share/doc. This directory contains HP-UX operating
system documentation on various topics that is not delivered with other
parts of the system. /usr/share/lib. This directory is for miscellaneous
sharable files. For example, terminfo files will appear beneath this
directory. /usr/share/man. This directory is for man pages.
Processed man pages (for example, /usr/share/man/cat1.Z/*) will
also be held here. /usr/tmp. A temporary directory symbolically linked to /
var/tmp for backward compatibility. This directory is not shared with
other systems in a diskless cluster. /var
This directory is for multipurpose log, temporary, transient, variable
sized, and spool files. The /var directory is extremely “variable” in size,
hence the name. In general, any files that an application or command
creates at run time, and that are not critical to the operation of the
system, should be placed in a directory that resides under /var. For
example, /var/adm will contain log files and other run time-created files
related to system administration. /var will also contain variable size
files like crontabs, and print and mail spooling areas.
In general, files beneath /var are somewhat temporary. System
administrators that wish to free up disk space are likely to search the /
var hierarchy for files that can be purged. Some sites may choose not to
make automatic backups of the /var directories. If a product locates
important configuration files here that do not fit under /etc, it is
recommended that documentation explicitly reference /var files to backup.
/var should not be placed on a small, fixed-size partition. Also, /var is
not an install point.
Chapter 2
The New File System Layout
2.1 Introduction /var/adm. This directory hierarchy is used for common
administrative files, logs, and databases. For example, files generated by
syslog(3C), files used by cron(1M), and kernel crash dumps will be kept
here and in subdirectories. Host-specific administration information will
also be kept here. /usr/adm has become /var/adm. /var/adm/crash. Kernel crash dumps will be located in
this directory. /var/adm/cron. Used for log files maintained by cron, and
cron fifos. /var/adm/sw. Used by SD, the HP OpenView Software
Distributor. /var/adm/syslog. System log files generated by syslog
(see syslogd(1M) and syslog(3C)) will go into this directory. /var/mail. Directory where incoming mail messages are
kept. /var/news. Electronic bulletin board files used by news(1)
will be kept here. Formerly /usr/news. /var/opt. Application run time files (for example, logs,
status, temporary files) for applications mounted in /opt will be stored
in /var/opt/<application> for each application. /var/preserve. Files preserved by vi will be stored here.
Formerly /usr/preserve. /var/run. PID files for daemon programs will be stored in
/var/run, NOT in /etc. /var/spool. Host-specific spool files are located here. In
general, /usr/spool becomes /var/spool. /var/tmp. /var/tmp is for user temporary files generated
by commands in the /usr hierarchy. Files located here are preserved
between system reboots. Temporary files generated by applications
installed under /opt/<application> will use /var/opt/<application>
for temporary files.
Chapter 2
The New File System Layout
2.1 Introduction /var/uucp. UUCP administration files will reside here.
2.3 Applications
As discussed earlier, the 10.x file system model separates static and
dynamic files. Application product file system layouts follow the same
conventions and extend the model to provide separation among products.
This is accomplished in many ways:
• In general, applications are located separate from the operating
system under /opt. They do not reside below /usr and /sbin, which
are OS directories. This allows for separate application product
directories that can span OS revisions, and allows easier disk
partitioning management.
• System administrators are able to easily identify the location of all
files related to an application.
• Critical information is easily backed-up because all application
configuration files are contained beneath one hierarchy.
2.3.1 File Layout
In general, /opt is the application directory. Below here, applications
are self-contained in their own directory, /opt/<application>. Shareable
files (that may be shared among multiple nodes), such as binaries, man
pages and libraries, reside in this directory. Host-specific private files,
such as logs and node-specific configurations, are located in the private/
dynamic directories under /var/opt/<application> and /etc/opt/
<application>, respectively.
The application root (/opt/<application>) should contain a subdirectory
structure similar to that of /usr: bin, lbin, lib, man and newconfig.
Figure 2-3, “Application File Layout”, shows a sample directory
bin, lbin, lib, share, and newconfig look like /usr.
Chapter 2
The New File System Layout
2.1 Introduction
Figure 2-3
Application File Layout
Looks like /usr
2.3.2 Commands and Libraries
Application binaries and libraries follow the same layout used by the
operating system. User commands are located in /opt/<application>/
bin, back end commands reside in /opt/<application>/lbin, and
shared and archived libraries reside in /opt/<application>/lib. NLS Message Catalogs. NLS message catalogs for
applications should be placed in the /opt/<application>/lib/nls
directory. To automatically access these files using the standard NLS
interfaces, the NLSPATH environment variable must be set to include
the application's message catalog directory. Applications are responsible,
upon invocation of any application binaries, to add the correct component
to the NLSPATH environment variable.
2.3.3 Manpages and Other Architecture-Independent
Application manpages are kept separate from OS manpages and reside
in /opt/<application>/share/man.
Other architecture-independent files that may be shared by more than
one system reside below /opt/<application>/share and must follow
the same layout conventions specified for the operating system in section
2.2, “File System Layout Specification”. These include object files and
libraries, to name a few.
Chapter 2
The New File System Layout
2.1 Introduction
2.3.4 Configuration Files
System-dependent configuration files for applications reside in /etc/
opt/<application> and include files necessary for the proper run-time
execution of the product. Files that are by-products of execution are
considered temporary files and should be located under /var/opt/
<application>. Because all system configurations are located under /
etc, system administrators can easily view system and application
configurations. This also facilitates backup of configuration data for a
given machine.
Dynamic files, such as logs and configurations, should never be loaded
directly into their target locations in /etc or /var (This may overwrite
current data). These should be delivered below /opt/<application>/
newconfig, as specified in section, “/usr/newconfig”, and
moved into place during product configuration.
2.3.5 Logs and Temporary Files
Temporary files created by applications (products installed in /opt) for
use during run time are located in /var/opt/<application>. This
includes logs and lock files that are by-products of run time execution,
but does not include those configuration files necessary for correct
execution of the application. Configuration files reside below /etc/opt.
2.3.6 Path Variables
Product binaries, man pages and other files are no longer contained in
common system directories. Consequently, the default system path
values no longer point to all the installed software and must be adjusted
for products as they are added to a system. The new model provides a
mechanism to “register” a product's files with the appropriate path
Two path variables are considered: PATH and MANPATH. Each variable
is addressed with a separate file, each containing a colon-separated list
of values representative of the particular path variable:
location of commands
location of man pages
Chapter 2
The New File System Layout
2.1 Introduction
The system default login files (/etc/profile, /etc/csh.login)
appropriately source these files for the respective path variables.
The path files should never be directly manipulated by a product's
installation processes. SD provides configuration utilities that enable
applications to add their product-specific values to the appropriate path
variable files.
2.4 General Impacts to Developers and Users
The 10FSL introduces many changes that affect not only software
developers, but also users and system administrators. The major change
involves filename and directory locations. If you have existing code that
needs to be integrated into HP-UX 10.x, some of the common impacts are
discussed below.
2.4.1 Embedded Pathnames
Software developers frequently code pathnames into their source. These
paths may appear in header files and library routines, as well as the
main body of code. The 10FSL changes require developers to scan these
sources for pathname values, evaluate the findings and implement the
necessary changes to reflect the correct file system layout. Hard-coded
pathnames may be found in:
• Program source, headers and make files.
• Scripts (ksh, psh, sh, awk, sed, etc.)
• Libraries
• Binaries and Object code
• Message catalogs and help/man files
For solutions to finding embedded pathnames, see section 2.5.1, “Finding
Embedded Pathnames.”
2.4.2 Environment Variables
An important, but often overlooked, area is environment variables.
These may be contained in the system and user login files such as ~/
.profile, ~/.login, ~/.vueprofile, ~/.cshrc, and /etc/skel/
Chapter 2
The New File System Layout
2.1 Introduction
d.*. These are the most common files, but there may be others
associated with applications. Be sure to check your system for other
possible occurrences.
Environment variables that have execution strings or contain paths are
likely to be impacted. Be sure to change all path variables to reflect the
correct directories where your commands are contained.
2.4.3 Build & Test Environments
Developers often keep separate environments for building and testing
their systems and applications. This is also an important area to
evaluate for hard-coded pathnames. Makefiles and test scripts may
contain paths that have been changed as a result of the 10FSL.
2.4.4 Documentation
Many applications have detailed documentation outlining the product
installation locations. Documentation should also be scanned for obsolete
path names.
2.5 Solutions to Commonly Asked Questions
This section includes both tips and answers to commonly asked
questions regarding the file system layout and the upgrade from HP-UX
9.x to 10.x.
2.5.1 Finding Embedded Pathnames.
There are a number of ways to search for embedded pathnames. A few
recommended solutions are listed below. However, you should note that
these are only suggestions and are not guaranteed to find all embedded
pathnames. Each developer should analyze their applications and
systems for any other areas that may not execute properly on the 10FSL. HP Tools. Hewlett-Packard provides tools to help users
identify and fix absolute pathnames that are obsolete. The tools convert
shell scripts (ksh, sh, csh, etc.) and makefiles to comply with the new
10FSL. The same tools that operate on scripts and makefiles also do
simple string translations for absolute pathnames found in ordinary
ASCII files. On an HP-UX 10.x system, one such tool is /opt/upgrade/
bin/analyzer. Please see its accompanying documentation for further
Chapter 2
The New File System Layout
2.1 Introduction “strings” command. The strings command is a good
alternative. This is most effective on non-ASCII files, but may be used on
ASCII text files. See the HP-UX manual page, strings(1), for more
details. A sample command is shown below:
strings -a <filename> | grep / | sort -u
This will produce a unique sorted list of alphanumeric strings containing
“/”, indicating either an absolute or relative pathname. This will probably
generate a lot of non-pathname results and will need to be searched for
valid pathnames.
On a pre-10.0 system, the strings command may be found in /usr/bin.
On a 10.x system, strings is found under /usr/ccs/bin.
2.5.2 Finding New Locations of Files
HP provides a database and a tool to assist you in locating operating
system product files in both the 9.x and 10.x locations. The tool is /opt/
upgrade/bin/fnlookup on an HP-UX 10.x system. Please see its
accompanying documentation for further details.
In the meantime, you may examine a HP-UX 10.x system using the find
find <path> -print | grep <filename>
This will produce the location of the desired file if it is contained below
<path>. If not, try another path location.
2.5.3 Building PATH Variables
In the 10FSL, there are no longer only a few key places, such as /usr/
bin, where executables may be found. Applications will have both
manual (“man”) pages and binaries in application directories below /
As applications are added to a user's environment, the PATH and
MANPATH variables must be updated so that commands and man pages
will be found. There is an automated mechanism available to application
developers to add their appropriate entries to these paths. However, all
applications may not take advantage of this mechanism. In this case, the
user will need to manually add to the appropriate path variables.
For example, if a (ksh, sh) user has application XYZ and wishes to have
the man pages and binaries accessible without fully qualifying the path,
both the PATH and MANPATH variables may be updated to resemble:
Chapter 2
The New File System Layout
2.1 Introduction
This task would be executed for each application that was added to the
user's environment. In some cases, applications may provide this
capability during configuration. In other cases, system administrators
and users must ensure their variables are set correctly for the
environment. This syntax is specific for ksh and sh; csh users must use
the appropriate syntax.
Chapter 2
System Start-up/Shutdown Model
System Start-up/Shutdown
This chapter explains the 10.x system start-up and shutdown model and
outlines the differences between HP-UX Releases 9.x and 10.x. All of the
changes apply to both S700 and S800 computer systems. These
differences will primarily affect software developers and system
administrators. Software developers will construct rc files in a different
manner, specifying run-level execution order and enabling control
through configuration variables. System administrators will control
subsystem behavior, on a per-host basis, by modifying variables that
control subsystem start-up and shutdown.
These topics are covered in the following sections:
• Introduction: the rationale for, and an overview of, the model.
• Start-up/Shutdown Specifications: the specifications of the new
• General Developer and User Impacts: explanation of affected areas.
Chapter 3
System Start-up/Shutdown Model
3.1 Introduction
3.1 Introduction
3.1.1 Philosophy of the New
Start-up/Shutdown Model
The 10.x Start-up/Shutdown model is based upon the scheme used by the
OSF/1 operating system. Important new features of the scheme include:
• The model separates the execution scripts from the configuration
information required for execution. Within a single directory, system
administrators may easily modify the behavior of the
start-up/shutdown sequence by changing configuration variables.
• Execution scripts are not modifiable. System administrators cannot
change the scripts themselves, but rather they are provided with
configuration variables that change the behavior of the scripts.
• Individual subsystems may now be started or stopped on a per-initstate basis. This enables fine levels of control and subsystem
3.1.2 Start-up/Shutdown Overview
The old /etc/rc-based start-up scheme will be replaced by the start-up
and shutdown scheme used by the OSF/1 operating system. The new
start-up/shutdown scheme consists of three parts:
1. Execution Scripts used to start up and shutdown individual
subsystems are contained in /sbin/init.d.
2. Configuration files for each execution script are contained in
/etc/rc.config.d and reside in a filename that is generally equal
to the script for which they configure.
3. Link Files in /sbin/rc*.d control the sequencing order of the
execution scripts.
Figure 3-1, “9.x - 10.x RC Configuration Mapping”, shows the
relationship of 9.x files to 10.x files. Prior to 10.0, both script code and
configuration information, such as IP addresses and hostnames, were
contained within the files. The new model partitions the configuration
data from the scripts. Administrators use the configuration variables in
Chapter 3
System Start-up/Shutdown Model
3.1 Introduction
/etc/rc.config.d to change the behavior of scripts in
/sbin/init.d. Script sequencing is also a new feature for 10.x and is
controlled through link files in /sbin/rc*.d directories.
Figure 3-1
9.x - 10.x RC Configuration Mapping
9.x Files
10.x Files
Link Files
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
3.2 Start-up/Shutdown Specifications
This section describes the new start-up and shutdown model
components: execution scripts, configuration variable scripts and link
3.2.1 Execution Scripts
The /sbin/init.d directory contains all scripts used to start up and
shutdown various subsystems. No script may invoke any of the other
scripts in this directory. Scripts obtain configuration data from variables
in /etc/rc.config.d (more on this later), which must be sourced by
the execution script. All files in the /etc/rc.config.d directory may
be read by sourcing the single file /etc/rc.config.
The start-up and shutdown scripts shipped by HP in /sbin/init.d
must not be edited. Any changes made to these scripts will be
overwritten when a new software release is installed. Modifying the
behavior of a subsystem script is accomplished by using configuration
variables, discussed in Section 2.3.4, “Configuration Files.”
In general, each script under /sbin/init.d should perform both the
start-up and shutdown functions. In order to control the functionality
within the script, each must also support standard arguments and exit
codes. Scripts must be written for the POSIX shell. A template script
may be found in /sbin/init.d/template. Arguments to scripts
The start-up/shutdown scripts must recognize the following four
• start_msg. The “start_msg” argument is passed to scripts so the
script can report back a short message indicating what the “start”
action will do. For instance, when the lp spooler script is invoked with
a “start_msg” argument, it echoes “Starting the LP subsystem”.
This string is used by the start-up checklist. Note that when given
just the “start_msg” argument, scripts will only print a message and
NOT perform any other actions.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
• stop_msg. The “stop_msg” argument is passed to scripts so that the
script can report back a short message indicating what the “stop”
action will do. For instance, when the lp spooler script is invoked with
a “stop_msg” argument, it echoes “Stopping the LP subsystem”. This
string is used by the shutdown checklist. Note that when given just
the “stop_msg” argument, scripts will only print a message and NOT
perform any other actions.
• start. Upon receiving the “start” argument, the script should start
the subsystem. All output should be echoed to stdout.
• stop. Upon receiving the “stop” argument, the script should
shutdown the subsystem. All output should be echoed to stdout.
The messages echoed by the execution script when start_msg and
stop_msg arguments are passed should contain a single line message
with no more than 30 characters.
When passed the start and stop arguments, an execution script must not
echo any messages indicating the entry or exit from the script. Stop_msg
and start_msg arguments will be passed to the execution scripts by
/sbin/rc to record these messages both on screen and in log files,
indicating the beginning and ending of the script. Naming Conventions
The start-up and shutdown scripts are named after the subsystem they
control. For example, the /sbin/init.d/cron script controls the cron
daemon. Scripts and Console Output
To ensure proper reporting of start-up events, start-up scripts will be
required to comply with a few guidelines for script output and exit
Status messages, such as “starting foobar daemon”, must be directed to
stdout. All error messages must be directed to stderr. Both stdout and
stderr are redirected to the log file /etc/rc.log, unless the start-up
checklist mode is set to the raw mode. In this case, both stdout and stderr
output go to the console.
Start-up scripts, and the daemons or binaries they execute, must not
send messages directly to the console during system boot or shutdown.
This restriction exists because console output during the boot or
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
shutdown sequence will overwrite the graphical checklist, leaving the
checklist unreadable. These messages should be directed to stdout or
stderr. Exit values
Exit values for start-up scripts are as follows:
script exited without error. This causes the status “OK”
to appear in the checklist.
script encountered errors. This causes the status
“FAIL” to appear in the checklist.
script was skipped due to overriding control variables
from /etc/rc.config.d files or for other reasons,
and did not actually do anything. This causes the
status “N/A” to appear in the checklist.
script executed normally and requires an immediate
system reboot for the changes to take effect (Reserved
for key system components).
These are the only exit values acceptable. Returning an arbitrary
non-zero exit value from a command to indicate failure may cause the
script to appear to have been skipped in the checklist, or may cause the
system to reboot!
3.2.2 Configuration Variable Scripts
Instead of spreading configuration data throughout the various rc files in
the system, configuration data is structured as a directory of files that
allows developers to create and manage their own configuration files,
without the complications of shared file ownership. The directory that
holds the configuration variable scripts is /etc/rc.config.d. The
configuration variable scripts will be sourced by the start-up and
shutdown execution scripts in /sbin/init.d during system start-up
and shutdown. This configuration information is used by the execution
scripts to enable/disable and configure subsystems (such as IP
Examples of these variables include:
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
• HOSTNAME: Internet name of your system.
• IP_ADDRESS[0]: Internet address of your system, in dot format.
• SUBNET_MASK[0]: Internet subnetmask.
Each execution script may source its variables in one of two ways. If the
execution script only needs the variables delivered with its product or
fileset, it may explicitly source the file in /etc/rc.config.d. If the
script requires variables that are delivered by other products or filesets,
it may just source /etc/rc.config, which is a script that sources all
the files below /etc/rc.config.d.
There are no requirements on the order of the files sourced. This means
configuration files must not refer to variables defined in other
configuration files, since there is no guarantee that the variable
being referenced is currently defined.
Configuration variable scripts are written for the POSIX sh
(/usr/bin/sh or /sbin/sh), and not the Bourne sh, ksh, or csh. In
some cases, these files must also be read, and possibly modified by other
scripts or the SAM program. For this reason, each variable definition
must appear on a separate line, in the syntax:
No trailing comments may appear on a variable definition line. Comment
statements must be on separate lines, with the “#” comment character in
column 1. An example of the required syntax for configuration files is
given below:
# Cron configuration. See cron(1m)
# CRON: Set to 1 to start cron daemon
The name of a configuration script in /etc/rc.config.d corresponds
to the names of the associated start-up and shutdown scripts found in
/sbin/init.d. /etc/TIMEZONE
/etc/TIMEZONE contains the definition of the TZ environment variable.
It is sourced by /etc/rc.config along with the other
/etc/rc.config.d/* files.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
3.2.3 Sequencing Scripts with Link Files
The third aspect of the start-up/shutdown scheme is controlling the order
of script execution with link files. An important feature enables
developers to control individual subsystems among run-levels. This is
accomplished by providing link files in run level directories that point to
the scripts in /sbin/init.d. Run-level Directories: /sbin/rc#.d
The /sbin/rc#.d (where # is a run-level) directories are start-up and
shutdown sequencer directories. They contain only symbolic links to
start-up/shutdown scripts in /sbin/init.d that are executed by
/sbin/rc on transition to a specific run level. For example, the
/sbin/rc3.d directory contains symlinks to scripts that are executed
when entering run level 3. (There is more information on /sbin/rc in
Section 3.2.4, “Run Levels and /sbin/rc”).
These directories contain two types of link files: start links and kill links.
Start links have names beginning with the capital letter “S” and are
invoked with the “start” argument at system boot time or on transition to
a higher run level. Kill links have names beginning with the capital
letter “K” and are invoked with the “stop” argument at system shutdown
time, or when moving to a lower run level.
Further, all link files in a sequencer directory are numbered to ensure a
particular execution sequence. Each script has, as part of its name, a
three digit sequence number. This, in combination with the start and kill
notation, provides all the information necessary to properly start-up and
shutdown a system.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
Figure 3-2
Start-up/Shutdown Component Relationships
Link Files
Config Files
Note: The sequence numbers above are only for example and may not accurately represent your system.
K180sendmail and S460sendmail are linked to sendmail.
The sequence numbers above are only for example and may not
accurately represent your system.
Figure 3-2 shows the run-level directories and the relationship of the
link files to the scripts. Because each script in /sbin/init.d performs
both the start-up and shutdown functions, each will have two links
pointing towards the script from /sbin/rc*.d; one for the start action
and one for the stop action. Naming Conventions
The naming conventions for the link files are as follows:
The various components have the following meanings:
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
1. Run Level Number (2): The sequencer directory is numbered to reflect
the run-level for which its contents will be executed. In this case,
Start scripts in this directory will be executed upon entering run-level
2 from run-level 1, and Kill scripts will be executed upon entering
run-level 2 from run-level 3.
2. Sequencing Type (S): The first character of a sequencer link name
determines whether the script is executed as a start script (if the
character is “S”), or as a kill script (if the character is “K”).
3. Sequence Number (060): A three digit number is used for
sequencing scripts within the sequencer directory. Scripts are
executed by type (start or kill) in lexicographical order.
4. Script Name (cron): Following the sequence number is the name of
the start-up script. This name must be the same name as the script to
which this sequencer entry is linked. In this example, the link points
to /sbin/init.d/cron.
Scripts are executed in lexicographical order. The entire file name of the
link is used for ordering purposes. When adding new sequencer entries,
sequencer numbers are chosen to allow for gaps so that future entries
may be inserted without requiring renumbering of existing entries.
HP-supplied sequencer entries will all have unique numbers. (There is
more information on sequence numbers in Section 3.2.5, “Link File
Sequence Number Rationale and Assignment”).
Subsystems are killed in the opposite order they were started. This
implies that kill scripts will generally not have the same numbers as
their start script counterparts. For example, if two subsystems must be
started in a given order due to dependencies (e.g., S111fubar followed by
S222uses_fubar), the counterparts to these scripts must be numbered so
that the subsystems are stopped in the opposite order in which they were
started (e.g., K555uses_fubar followed by K777fubar).
Also, kill scripts for start scripts in directory /sbin/rcN.d reside in
/sbin/rc(N-1).d. For example /sbin/rc3.d/S123foobar and
/sbin/rc2.d/K654foobar might be start/kill counterparts.
HP-UX will continue to support short filenames (i.e. 14 characters).
Because of the filename place holders for `K', `S' and the 3 digit sequence
numbers, subsystem script names in /etc/init.d are restricted to 10
characters in length.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
3.2.4 Run Levels and /sbin/rc
In previous HP-UX releases, /etc/rc was run only once. Now it may
run several times during the execution of a system, sequencing the
execution scripts when transitioning run levels. However, only the
subsystems configured for execution, through configuration variables in
/etc/rc.config.d, are started or stopped when transitioning the run
/sbin/rc sequences the start-up and shutdown scripts in the
appropriate sequencer directories in lexicographical order. Upon
transition from a lower to a higher run level, the start scripts for the new
run level and all intermediate levels between the old and new level are
executed. Upon transition from a higher to a lower run level, the kill
scripts for the new run level and all intermediate levels between the old
and new level are executed.
When a system is booted to a particular run level, it will execute start-up
scripts for all run levels up to and including the specified level (except
run level 0). For example, if booting to run level 4, /sbin/rc looks at the
old run level (S) and the new run level (4) and executes all start scripts in
states 1, 2, 3, and 4. Within each level, the start scripts are sorted
lexicographically and executed in that order. Each level is sorted and
executed separately to ensure that the lower level subsystems are
started before the higher level subsystems.
Consequently, when shutting down a system, the reverse takes place.
The kill scripts are executed in lexicographical order starting at the
highest run level and working down, as to stop the subsystems in the
reverse order they were started. As mentioned earlier, the numbering is
reversed from the start-up order.
States 0 and S are special cases. When entering state 0 or S, /sbin/rc
will run start scripts in /sbin/rc0.d. Start scripts in state 0 are quick
system administration scripts that prepare the system for a shutdown.
When entering state S, all processes are killed and the system is in
single user state. When entering state 0, the system is halted. The table
below summarizes the run level definitions.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
Table 3-1
Run Level Definitions
Run level
Single User
Exported File
Not currently
/sbin/rc interaction
When entering from
lower state, all start
scripts are executed.
When entering from
higher state, all kill
scripts are executed
For run levels 1 through 6: when entering from lower state, all start
scripts are executed, and when entering from higher states, all kill
scripts are executed.
3.2.5 Link File Sequence Number Rationale
and Assignment
To enable proper system start-up and shutdown, execution scripts must
be invoked in the correct order. This is accomplished by assigning
sequence numbers for the link files (e.g., S300cron) contained in the
sequencer directories (i.e., /sbin/rc2.d). The HP-UX 10.x operating
system and its associated products have been structured using a
paradigm that groups various related functions into the same run state.
This is accomplished by reserving blocks of sequence numbers for these
functions. The paradigm is described in the sections below. Some entries
provide examples of subsystems that are started at a particular level.
Please consult an HP-UX 10.x system for a complete and accurate
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications Run Level 1 Paradigm
Run level 1 provides essential services, such as mounting file systems
and configuring essential system parameters.
reserved for temporary links
mount local filesystems
essential process initialization/kill
set essential system parameters (hostname, lan
set other system parameters (date, privilege groups)
start essential daemons (swapper and syncer daemons)
not currently used
reserved for future expansion Run Level 2 Paradigm
Run level 2 is the general multi-user run state where most services are
reserved for temporary links
software installation/configuration (SD)
essential local daemons and services, started before
network start-up (clean log/tmp files, syslogd)
network start-up
network tracing/logging must be first
network low-level services (FDDI, ATM, Fiber, token
traditional TCP/IP initialization (ifconfig, route,
gateway, netmask, etc.)
other network start-up (x25, loopback daemon, naming
NFS/NIS initialization
services built on top of network services
(DCE,DFS,NCS, rbootd, NetLS, mail. Also
client/server services: X font server, Kanji server)
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
inetd super-server
other local daemons/services (lp, cron, diagnostics,
auditing, accounting, etc.)
reserved for future expansion
“Don't Care” number for run state 2 Run Level 3 Paradigm
Run level 3 is the networked multi-user state. This run level is used to
export file systems. Currently HP supports NFS exports only. Other
vendors also do RFA exports here.
reserved for temporary links
exports (NFS server)
not currently used
reserved for future expansion Run Level 4 Paradigm. Run level 4 is reserved for
desktop managers. Currently, HP-VUE is started in this run level, but as
an entry in /etc/inittab. No start/kill links are currently shipped in
run level 4.
3.2.6 Adding Your Own Subsystems
System administrators and software product developers may have a
need to add their subsystem(s) to this model. This may be easily
accomplished by following a few steps.
A good place to start is with the execution script. This may be derived
from any of the system execution scripts found in /sbin/init.d. There
is also a blank template in /sbin/init.d/template. The guidelines
for execution scripts must be strictly followed such that the interface
with /sbin/rc is correctly maintained. Any failure to do so will likely
cause the execution script to fail.
A configuration file should also be added to /etc/rc.config.d. This
file should contain a variable assignment that enables the user or system
administrator to enable or disable the particular subsystem. The file
should also contain any other variable assignments required by the
subsystem during start-up. The configuration file should not contain any
executable script code other than variable assignments.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
Selecting a run state and a sequence number should probably be done
last. Many times it is difficult to determine exactly where the subsystem
should fit until it has been coded and tested. Selecting Sequence Numbers
All of the sequence numbers for HP products have been carefully
assigned to ensure correct ordering, eliminate overlap and allow room for
growth. Each of these products has registered with a central
organization and has been given specific sequence numbers based on a
number of factors about the product. When choosing sequence numbers
for products or applications, system administrators and software product
developers should adhere to the guidelines below.
Commercially available products may require specific sequence number
ordering. Software developers should not arbitrarily choose an
unused/unassigned number that happens to be absent from the system
or table they are reviewing. Absent numbers that appear unused may
have already been assigned by Hewlett-Packard to a product that has not
yet been released, or is not installed on the system. Instead, developers
should contact HP through:
Software Provider Program
1-800-249-3294 (Leave a message in the Technical Assistance Mailbox)
Ask for information regarding “Start-up/Shutdown Sequence Number
Developers will be asked a few questions about the product and assigned
a set of numbers (start and kill). The product will then be registered with
Hewlett-Packard and be ensured that no other registered products will
have duplicate numbers that may corrupt an end-user's system.
However, duplicate numbers may be assigned for applications that do not
conflict. Developers are encouraged to contact HP late in their
development cycle, as close to application release as possible.
If specific ordering is not a concern and the subsystem may be started at
any point after system boot and initialization, run level 2, number 900
should be used for the start link and run level 1, number 100 for the kill
link. These “Do Not Care” numbers may be used by any product or
application without registering with Hewlett-Packard.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
Many end-user customers may find creative ways to utilize the
start-up/shutdown mechanism to control their environments. In many
cases, this will be realized by adding site or company specific
applications layered over HP-UX. If these products are not commercially
available, customer should choose their own numbers based upon the
paradigm in the previous section. However, this should be done with
caution when selecting specific numbers other than run level 2, #900.
The numbers selected for in-house use only are not registered with
Hewlett-Packard and may already be in use by a commercial product.
This potential conflict may be satisfactory to organizations that do not
anticipate installing many commercial applications. However, always
use caution when using numbers for in-house applications, or testing.
3.2.7 An Illustrative Example
Figure 6 below depicts a simple example of the start up of cron. The
relationships of the files between the static and dynamic file system is
also shown.
When entering run state 2 from a lower level, the 'S' scripts are executed.
In the example, S700cron is a link to the cron script under
/sbin/init.d. cron will start because the configuration variable in
/etc/rc.config.d/cron is set to 1. A value of 0 would not start cron.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
Figure 3-3
Implementing CRON in the New Model
minimum commands
to boot and mount
other filesystems
system configuration
symbolic link
# cron startup
. /etc/rc.config
if [ $CRON = 1 ]
then /usr/sbin/cron
# cron config
# CRON=1 to start
S700cron is linked to /sbin/init.d/cron. /sbin contains the
minimum commands to boot and mount other filesystems, and /etc
contains the system configuration files.
Chapter 3
System Start-up/Shutdown Model
3.2 Start-up/Shutdown Specifications
3.2.8 Guidelines for Start-up/Shutdown
System execution scripts are installed in the /sbin/init.d directory
directly from update media. Sequencer links for execution scripts are
also installed into the various sequencer directories directly from update
media. In the new scheme, system execution scripts are not customer
editable. No provisions are made to keep newconfig versions of the
scripts; any changes made by a customer to a system execution script are
overwritten and lost when an update occurs.
Customers are warned of the following:
• Execution scripts must not be modified. If a script in /sbin/init.d
is modified, the modification will be lost at the next update, when the
script is overwritten with a new version.
• It is not necessary to remove scripts from the sequencer. If a script is
removed from the sequencer, it will be replaced at the next update.
Control variables in files within /etc/rc.config.d should be used
to control whether a start-up script is executed.
• Sequencer links must not be renamed. If a symbolic link in the
sequencer directory is renamed (or renumbered), at the next update,
a symbolic link with the original name will be installed. This will
result in two copies of the same start-up script appearing in the
All HP-supplied start-up scripts are meant to be present in sequencer
directories as installed. They should not be removed or renamed (to
change the relative sequencing). Execution control should be performed
via control variables in /etc/rc.config.d/*.
Chapter 3
System Start-up/Shutdown Model
3.3 Applications
3.3 Applications
The start-up/shutdown specifications outlined above apply to all system
components, including applications.
Chapter 3
System Start-up/Shutdown Model
3.4 General Developer and User Impacts
3.4 General Developer and User Impacts
The 10.x Start-up/Shutdown model introduces an entirely new scheme
for subsystem control. Users no longer modify the large and confusing
/etc/rc* scripts to modify the system behavior.
3.4.1 /etc/rc* Scripts
If your system or application modified or created its own /etc/rc*
script, this will need to be changed for 10.0. Modification of the
HP-supplied scripts is discouraged. Creating application (or subsystem)
specific scripts is the recommended solution. Guidelines in section 3.2,
“Start-up/Shutdown Specifications”, must be followed to ensure correct
3.4.2 Manageable Configuration and Script
HP is no longer supplying large /etc/rc* scripts. Instead, they have
been separated into functional pieces, with the configuration data
residing under /etc/rc.config.d.
Developers and users will only modify configuration files to control the
system start-up/shutdown behavior. Modification of the scripts under
/sbin/init.d is not recommended.
Chapter 3
10FSL Acronym for “10.0 File
System Layout”
Link Files A component of the
start-up/shutdown model used to
link the execution scripts to a
particular run-state. Link files are
contained in /sbin/rc*.d and
point to execution scripts in /
Cluster A set of one or more
nodes, connected by a network,
that are provided boot services by
a cluster server.
Configuration data information
used to configure the system and
includes: IP address, hostname,
timezone, etc.
NFS Network File System. An
implementation of Remote
Procedure Calls (RPCs) and
remote mounting and access of file
systems over a network.
OSF Open Software Foundation.
Execution script An execution
script is a system start-up and
shutdown script located in/sbin/
Install point A directory into
which software can be directly
installed. All non-install points are
potentially private directories, and
must be configured on a per-host
basis by execution of SD
configuration scripts.
PID file A file which contains the
process ID of a running application
or subsystem component.
Runtime File A working file
created by an application or a
subsystem. these include lock
files, PID files, temporary files,
state files, etc.
SD Acronym for Software
Distributor, a replacement for the
HP-UX DUI update utility.
Server The node or nodes in a
cluster providing services to other
Subsystem An operating system
feature that is tightly coupled with
the rest of the operating system;
enough so that it is not considered
an application. An example of a
subsystem is NFS.
V.4 AT&T System V, release 4.
Sometimes used in this paper to
denote the 10.x Filesystem Layout.
V4FSL Acronym for the AT&T
System V, Release 4 FileSystem