This chapter contains notes about issues and known problems with the base operating system and, whenever possible, provides solutions or workarounds to those problems.
The following topics are discussed:
Compaq maintains an online Technical Update that contains information about restrictions and problems that have been discovered since Version 4.0E began shipping. To view this document on the Web, go to the following URL:
http://www.unix.digital.com/faqs/publications/updates/V40E-update.html
Compaq recommends that you visit this site periodically to see if any new information has been added.
The following notes apply to commands and utilities.
The
make
command will not recognize escaped comment symbols as
literal characters in a Makefile.
Comment lines that begin with a
#
(number sign)
and all text following
this symbol up to the end of
the line are considered part of a comment.
This is also true even if the symbol is preceded with a backslash
(\).
The following notes describe problems that may occur when using commands and utilities under certain security settings.
Programs cannot reliably inspect the permission bits in the
stat
structure and determine the access that will be granted to a particular
user. On local file systems, read-only mounts and Access Control Lists
(ACLs) can both modify
the access that will be allowed. On remote file systems, in addition to
read-only mounts and ACLs, there may be additional controls
that can alter the permitted access such as:
Programs that copy files to update them, rather than updating them in place,
often do not preserve ACLs. Some programs that have this problem are
gzip,
compress,
and
emacs.
The best solution for programs that need to make access decisions is for the
program to use the
access()
call to determine what access will be granted.
Note that even this may not work as the access protections of the file
could be changed between the
access()
call and the
read,
write,
or
execute
operation.
For programs that copy files, the following command will copy a file while preserving ACLs and any other extended attribute (property list):
#
cp -p
See the
acl(4),
and
proplist(4)
reference pages for more information.
The
pax,
tar,
cpio,
dump,
restore,
vdump,
and
vrestore
archive tools may not restore ACLs on files in the manner you would
think that they should be restored. Always check the ACLs on your
files after saving and restoring them with any of these tools.
By default, the Emacs editor will rename the original file and save the new file as a copy under the original name. If the original file had an Access Control List (ACL) it will now apply to the backup file. If the directory had a default ACL, the new file (original file name) will now have the default ACL instead of the original ACL. If the directory did not have a default ACL, the new file will be protected only by the file permission bits.
The Emacs editor has some user-preference variables that you can set to control which file will retain the original ACL. The relevant Emacs variables are:
backup-by-copying
backup-by-copying-when-mismatch
backup-by-copying-when-linked
DIGITAL ships the Emacs software as it is received from the source.
The following command line options do not work as documented in the
emacs(1)
reference page:
-cr,
-geometry,
-i,
-ib,
-iconic,
-iconname,
-in,
-internal borderwidth,
-mc,
-T,
and
-title.
In some cases, a workaround is available by using an appropriate X resource.
The
write()
system call may fail with an ETXTBSY error when an attempt is made to
overwrite a running program or shared library. This prevents the
image in memory from being overwritten accidentally, which can result
in application crashes or hangs.
For example, using the
/usr/bin/cp
command to copy into an executing program will fail with the message
Text file busy
when the
write
system call is invoked:
%
a.out &
%
cp foo a.out
cp: a.out: Text file busy
A workaround is to use the
/usr/bin/mv
command:
%
mv -f foo a.out
You may also see this error in a development or compilation
environment where the
make
utility is used to build executables.
If Oracle8 running on DIGITAL UNIX hangs, look for console message
malloc_wait:X : no space in map.
If this message is present add the following to
/etc/sysconfigtab:
generic: kmem-percent=XXX
where
XXX
is the size of the kernel malloc map. By default,
XXX
is set to 25 percent of physical memory. Increase this parameter to 50
and reboot the system. If Oracle8 continues to hang, increase this parameter
up to 100.
The
/sbin/disklabel
command supports operations on an image file, including the capability of
writing a disk label and boot blocks. The default format is
ISO 9660 Rock Ridge standard CD-ROM format known as the CD-ROM File System
(CDFS).
With this feature, users can create a bootable CD-ROM, in CDFS format, from the image file.
The output format of the
ipcs
command has been modified. The
KEY
field now presents the value in hexadecimal format instead of decimal.
This change is compatible with other UNIX implementations and conforms to the
upcoming X/Open Unix98 standard.
The
sendmail
program has been upgraded to Version 8.8.8 as the default version for
DIGITAL UNIX. The current version, Version 5.65, is still available for use.
The new version, known as V8, has become the defacto standard in the industry,
especially for ISPs. Some of the features and enhacements provided with this
new version include masquerading, virtual domains, relay control, and spam. For more
information, see the sendmail book by O'Reilly and Associates, or the
sendmail Installation and Operations Guide,
or the
sendmail(8)
and
sendmail.cf(4)
reference pages. The
sendmail Installation and Operations Guide
is included in PDF format on the Supplementary Documents bookshelf of the
online DIGITAL UNIX documentation.
You can configure
sendmail
using the
mailconfig
or
mailsetup
applications.
During an update installation, the system will attempt to update your existing
sendmail.cf
file to comply with this new version. This updated
sendmail.cf
is compatible with both new and old version of
sendmail.
To continue using the previous version of
sendmail,
invoke the following command as root:
/sbin/init.d/sendmail select old
This will change all links related to
sendmail
to point to the version previous to Version 8.0.
Once you are ready to use the new version, you can switch back by invoking the
following command:
/sbin/init.d/sendmail select v8.8.8
When the system is first booted, after a full installation, the following warning
message is displayed as a result of starting
sendmail:
warning: local host name(hostname) is not qualified; fix $j in config file.
This means the system does not have a qualified name. This is because neither
bind
nor
mail
has been configured.
Sendmail
will continue to operate.
Sendmail
gives the following warning message when it is started and its
alias database is updated:
WARNING: writable directory /var/adm/sendmail
When
sendmail
initializes the alias database, it checks the modes on system directories and
files to determine if they have been trusted.
Because the permission on the
/var
directory is 775,
sendmail
gives a warning message because it expects the permission on
/var
to be set as follows:
chmod go-w /var
The
ifconfig
command will sometimes show "trustgrp unknown" in the status line for an
interface. This is mainly restricted to ATM lis and elan interfaces, but
might be seen on any interface configured after the system has booted.
For example, if you have an ATM lis0 interface:
# ifconfig lis0 lis0: flags=808e1<UP,NOTRAILERS,RUNNING,NOARP,SIMPLEX> inet 212.180.32.49 netmask ffffff00 ipmtu 9180 trustgrp unknown
The message can be ignored and has no effect on your system. It will be fixed in a future release of DIGITAL UNIX.
The
h
option to the
tar
command, which expands symbolic links to real files and
directories in the archive, does not work as documented. Do not use the
h
option. This problem will be fixed in a future release.
The following notes apply to the Netscape communicator.
Netscape Communicator V4.05 dumps core when
the application posts a file selection dialog
(XmFileSelectionBox).
Typically, this occurs when you are running the application in the
Common Desktop Environment (CDE) and select the
Save As option in the File pulldown menu
of the Navigator browser. It can also occur
when you select a link to download a
file or save an attachment to a mail message
in the Messenger Mailbox component.
To avoid this problem, edit the
/usr/bin/X11/netscape
script, as follows:
exec $REAL_NETSCAPE -name netscape $*
exec $REAL_NETSCAPE -name netscape -xrm '*nsMotifFSBCdeMode: True' $*
For more information, see the Communicator on UNIX release notes at the Netscape Web site:
http://home.netscape.com/eng/mozilla/4.0/relnotes/unix-4.0.html
The Netscape Communicator V4.05 process hangs the first time a page containing a Java applet is loaded by the Navigator browser when running on a DEC 3000 or AlphaStation 200. The Netscape process also hangs if you select the Java Console option in the Communicator pulldown menu. How long the process hangs depends on the processor type.
This hang only occurs the first time you start Java. Therefore, leave the Netscape process running in background until the hung process clears itself. After the hang has cleared once, you can continue to use Netscape Communicator normally.
Unlike the Netscape Navigator software in previous versions of the DIGITAL UNIX Operating System, the Netscape Communicator software bundled with the current version of DIGITAL UNIX does not currently come with any localization. Therefore, you cannot bring up a Japanese interface of the Communicator, for instance, even when your process is running in a Japanese locale.
Localizations for Netscape Communicator are planned. When available, these localizations will be provided on the DIGITAL UNIX web site, and in future releases of the operating system.
The following sections apply to restrictions on using the SysMan applications.
The following notes apply to Account Manager,
dxaccounts.
When copying user accounts via cut and paste or drag and drop, the Allow Duplicate UIDs option in the General Preferences dialog box will be honored. For example, when making a copy of user account that has a UID of 200, if the Allow Duplicate UIDs check box is off (the default), the resulting copy will have a unique UID automatically generated. If the Allow Duplicate UIDs check box is on, then the copy will have an identical UID. The same rules apply to copying groups.
The Account Manager has the following restrictions on both base security and enhanced security (C2) systems:
Workaround: Delete the original icon after the copy has been completed.
Workaround: Use the
usermod
or
groupmod
commands to set a starting value within the range:
usermod -D -x next_uid=xxx
usermod -D -x next_gid=xxx
Suppose the minimum UID is 100 and the maximum UID is 10000. Then the following line would cause the Account Manager to start generating UIDs from 5000:
usermod -D -x next_uid=5000
johndoe
from 200 to 201, the files and subdirectories under his home directory
will still belong to UID 200. Furthermore, if
johndoe
does not own his home directory, the ownership of that directory will
not change either.
Workaround: Use the
chown
command to change the directory and files, if applicable.
Workaround: Use the copy/paste feature to copy users, groups, or templates from Account Manager A to B.
Workarounds: Account manager correctly allows two or
more system administrators to work on the same password files
simultaneously. The proper file locking will occur and
new accounts can be added or modified. However, the
local groups file,
/etc/group,
and the NIS groups file,
/var/yp/src/group,
are written out after each group modification.
Therefore, the last system administrator to make a change
in a group's view window would overwrite any prior changes
from a different system administrator. For this reason,
running multiple, concurrent Account Manager
instances is not recommended.
Warning: DtComboBoxWidget: Unable to find item to select
Workaround: None. You can safely ignore these messages.
Leading and trailing white space is not stripped from text entry areas. This could lead to confusion, for example, if a field on the Find dialog contains a space character before the desired search string. The search string would not match because of the spurious space character.
The following problems apply to Account Manager when running on enhanced security systems:
Workaround: Change the template lock setting on the Create/Modify Template dialog screen after selecting the template by double clicking on the template icon in the Template view icon box.
Workaround: Set passwords through
/usr/tcb/bin/dxchpwd
or the
/usr/bin/passwd
command when the C1Crypt
Encryption type is chosen.
Workaround: Set the C1Crypt Encryption type for the user from the Create/Modify User dialog.
Workaround: Set passwords through
/usr/tcb/bin/dxchpwd
or
the
/usr/bin/passwd
command if the
minimum/maximum password length limitation is
necessary.
Workaround: To delete a user account you must do the following:
/etc/passwd
and
/etc/group
files
to remove references to the user.
#
/usr/tcb/bin/edauth -r <user name>
Workaround: Use the following command to remove the dangling protected password database entry:
#
/usr/tcb/bin/edauth -r <user name>
Workaround: Restart Account Manager to restore the former template icon. Use the Delete Toolbar icon or the Edit->Delete... option from the Template view to delete the undesired template
Workaround: Modify the copied user's account and change the template from the default to the desired template. Note that the template reference is maintained if the user is dropped within the same view.
Workaround: Only the drag and drop method of template assignment has this problem. You can use the Create/Modify dialog box to change a single user's template or use the Modify Selected dialog box to change templates for several selected users. Both methods correctly propagate the template's lock field.
template %2
instead of the template's name.
Workaround: None.
Workaround: Restart Account Manager and then delete the template.
Workaround: Manually remake the NIS maps or perform an Account Manager function (for example, Account Modification) that will trigger the maps to be remade. To manually remake the maps do the following:
#
cd /var/yp
#
make all
The Print Configuration Manager may have some problems with
/etc/printcap
files from DEC OSF/1 Version 3.2 or earlier, as follows:
Using
/etc/printcap
files in the current version of DIGITAL UNIX,
the system assigns printer names
lp[0-9]*,
[0-9]*,
and for the default printer,
lp.
For example, the default printer may have a name field such as
lp0|0|lp|default|declaser3500:....
Another printer may be named
lp7|7|some_alias|another alias:....
Therefore, the system has difficulty with printers
that have less than two names or that use
these reserved names as aliases.
Some of the attribute value checking is different between earlier versions and the current version. For example, some fields that were not required now are, and some attribute values that were legal no longer are.
The Print Configuration Manager requires that all comments be associated with a printer. As a result, comments appearing after the last printer are truncated.
To avoid these problems, invoke the
printconfig
utility with the menu interface
(printconfig -ui menu).
This brings up the
lprsetup
utility, which is fully compatible
with earlier
printcap
files.
The following problems apply to configuring BIND servers with the BIND configuration graphical user interface.
Workaround: Edit the
/etc/namedb/named.boot
file to remove the zone entry that needs to be deleted.
Workaround: If the Forwarder is not needed, you can edit the
/etc/namedb/named.boot
file to remove the Forwarder entry after you Commit to the
setup in the BIND configuration interface.
/etc/namedb/named.boot
file will be deleted if the Zones
button is not clicked first.
Workaround: Whenever you modify your BIND setup using the BIND configuration interface, click on the Zones button before you Commit to any changes.
Workaround: The address can be modified by editing the secondary
domain entry in the
/etc/namedb/named.boot
file.
The
dxshutdown
application does not create the
/etc/nologin
file as described in the documentation.
This means that users will be able to log in to a machine
that is being shut down up until the actual time of the shut down.
Note that this behavior differs from that of the
shutdown
command that creates the
/etc/nologin
file at 5 minutes prior to the shutdown.
The following notes apply to system administration.
When the
/etc/passwd
file is very large, a performance degradation may occur.
When the number of
passwd
entries reaches the 30,000 to 80,000 range or greater,
mkpasswd
will sometimes fail to create a hashed
(ndbm)
database. Because the purpose of this database is to allow for
efficient (fast) searches for
passwd
file information, failure to build it causes commands that rely on it
to do a linear search of
/etc/passwd.
This results in a serious performance degradation for those commands.
For customers choosing to use the
mkpasswd -s
option to avoid this type of failure, a potential database or binary
compatibility problem may arise. If a customer application that
accesses the password database created by
mkpasswd
is built statically (nonshared), that application will be unable to
read from or write to the password database correctly. This would
cause the customer application to fail either by generating incorrect
results or by possibly dumping core. Any statically linked
application would be affected if it directly or indirectly calls any
of the
libc ndbm
routines documented in the
ndbm(3)
reference page and then accesses the password database. To remedy
this situation, you must re-link the application.
Customers who do not use the
mkpasswd -s
option will not see this compatibility problem.
Certain software license PAKs include expiration dates that currently limit the ability to run software when the date is set well into the future (into the year 2000). While most customers do not have PAKs with expiration dates, those who do (such as CSLG, ASAP, or Partner PAK Program members) may benefit from the following enhancements.
The
lmf
utility and supporting code have been enhanced to allow customers with
expiring software license PAKs to set the system date beyond the
expiration dates within a specific time window to allow Year 2000
(Y2K) testing.
Also, a test PAK,
00Y2K-TESTING,
is available for use with DIGITAL UNIX Version 4.0D and higher. If
you have expiring license PAKs, you can install this test PAK,
allowing your PAKs to operate beyond their expiration dates between
the dates of December 1, 1999 and March 2, 2000. The test PAK allows
you to conduct Y2K testing within the specified time window.
For information about obtaining the
00Y2K-TESTING
PAK and other Y2K issues, see the
DIGITAL UNIX Year 2000 Readiness
white paper, which is available in HTML format on the
DIGITAL UNIX 4.0E Documentation, Volume 1
CD-ROM. This document is also available on the DIGITAL UNIX
web page at the following URL:
http://www.UNIX.digital.com/unix/year2000/whitepaper.html
Once you obtain and install the
00Y2K-TESTING
PAK and set the system date forward for Y2K testing,
you must execute the following command from the root account the first
time run level 3 (also referred to as "init 3" or "multiuser mode")
is entered after each system boot:
#
/usr/sbin/lmf reset
This will ensure that all software licenses are loaded while the system date is set within the Y2K testing window. You need to execute this command only once within run level 3 between each system boot. You can toggle the system between run level 1 and run level 3 after the first execution of the command in run level 3. You will only be required to execute the command again after rebooting the system.
Compressed crash dumps have been enabled for this release of DIGITAL UNIX.
You may need to disable this feature if you have tools or scripts that
do not work with compressed crash dumps. If necessary, use
dbx
to set the
compressed_dump
variable to 0 in the running kernel, as follows:
(dbx) assign compressed_dump = 0
Note that this must be repeated each time the kernel is booted.
Alternatively, you can use
dbx
to patch the value of
compressed_dump
to 0 in the kernel image file.
Chapter 4 of the
Kernel Debugging
guide provides more information
about crash dump settings. Also, see the
savecore(8),
sysconfig(8),
and
dbx(1)
reference pages.
The
/var/adm/syslog.dated
directory contains preserved copies of log files that are used for
debugging. Normally, these files do not contain many entries.
However, under certain error conditions, a DIGITAL UNIX subsystem
might log an excessive amount of entries to a file and cause a
problem.
You should either physically check the logs on a regular basis or
use the
cron
utility to set up a regular job to clear the log files. The default
root
crontab file in the
/var/spool/cron/crontabs
directory contains the following sample line for clearing up the
/var/adm/syslog.dated
directory (the \ indicates line continuation):
40 4 * * * find /var/adm/syslog.dated -depth -type d -ctime +5 \
-exec rm -rf {} ;
If enabled, this
cron
job will be activated every morning at 4:40 a.m. and will delete any log
file in
/var/adm/syslog.dated
that has not been updated for the last five days. You can edit the
crontab
file to uncomment and modify this line or add a similar line
by using the following command:
# crontab -e
For more information, see the
crontab(8)
reference page.
The security of the
syslog
facility has been enhanced in this release. Unless the domain host name of a
remote host is entered in the local file,
/etc/syslog.auth,
the local system will not log any
syslog
messages from that remote host.
If you are installing
the secure version of
syslogd
on a system, and you have configured or intend to configure other
hosts to forward
syslog
messages to the system, complete the following steps:
su
to become the superuser
(root)
/etc/syslog.auth
using a text editor. This file must be owned by
root
and have permissions set to 0600.
syslog
messages to the local system. Host names must meet the following criteria:
/etc/syslog.auth.
(A line started with the "#" character is considered as a comment and is
ignored.)
trout.fin.huk.com
/etc/hosts
file or the local system must resolve it through a name server
(such as BIND).
MAXHOSTNAMELEN
constant in
<sys/param.h>,
although each line in the
/etc/syslog.auth
file is limited to 512 characters.
System configurations that are large, containing many adapters and
devices, may exhibit incomplete message logging in the
/var/adm/messages
file.
If this happens, you should compensate for the large system
configuration by increasing the value of the
msgbuf_size
attribute in the
generic
subsystem using
sysconfigdb
utility or the
dxkerneltuner
interface.
The default value for
msgbuf_size
is 4096. Usually, setting it to 8192 is sufficient to resolve the
problem. If you have a smaller configuration and you do not see this
problem, you should not make the change.
Refer to the
sysconfigdb(8),
reference page and the
System Configuration and Tuning
guide for information about modifying system attributes.
For DIGITAL UNIX Version 4.0E and its software supplements, the supported version of the EISA Configuration Utility (ECU) is Version 1.10 or higher. If your system is configured with an EISA bus, you should update the ECU to this supported version.
Consult the Open3D Software Product Description (SPD) before installing Open3D to ensure that this DIGITAL layered product is supported on your system.
Installing Open3D on systems not supported by the Open3D layered product can leave your system in an unusable state.
For this release, bootable tape will not work with the LSM product. Not all platforms and tape drives support bootable tape. The following processor platforms are supported:
The following tape devices are supported:
To use the
btcreate
utility, your system must have at least 156,000 512-byte blocks of free
space in the
/usr
directory.
You will not have enough space if your system uses an RZ26 or smaller disk with the default partitions and you have installed all of the subsets and kernel options.
To overcome this limitation, you can reclaim the required space by removing some subsets or by creating and mounting new partitions.
The following steps show you how to create and mount new partitions for
a UNIX file system (UFS). If you prefer to use AdvFS, use the
mkfdmn
and
mkfset
commands.
newfs
command to recreate a new partition:
#
newfs /dev/rz1d
/usr/sys
directory:
#
cd /usr/sys
.BOOTABLE directory under the
/usr/sys
directory, where
SYSTEM
is the system name:
#
mkdir FLAWLESS.BOOTABLE
.BOOTABLE directory:
#
mount /dev/rz1d /usr/sys/FLAWLESS.BOOTABLE
This device should have at least 75,000 512-blocks available.
#
newfs /dev/rz1b
#
mount /dev/rz1b /mnt
/usr/sys/bin
directory.
/usr/sys/bin
directory to the
/mnt
directory:
#
cp * /mnt
/mnt
directory:
#
umount /mnt
/usr/sys/bin
directory:
#
mount /dev/rz1b /usr/sys/bin
After completing these steps, your system should have the necessary
space to run
btcreate.
If you are using AdvFS, the
/usr/sys/bin
file system must be copied during
btcreate
in order to copy the entire contents of the
/usr
file system.
Ensure that the kernel has been built with the tape drive connected to your system. If the drive was not connected when the kernel was built, you will see dump errors and the system will not be able to boot from the tape drive.
Bootable tape will not function with the
-m mfs
option on systems with 32 MB
memory configurations.
After booting the kernel from tape, commands that use
shared libraries will core dump.
Use the
-m ufs
option while creating
the tape on systems with 32 MB memory configurations.
Bootable tape does not support the bootable kernel built with the
/usr/sys/conf/GENERIC
kernel configuration file.
Be sure to use a system-specific custom kernel.
Using a bootable tape on a platform other than the one on which it was created is not supported. For example, you cannot create a tape on a 4100 system and boot from it on a 1000A system.
When using QIC tape drives to create bootable tapes, you must use only high-density tapes of 320 or more megabytes. The QIC-24, QIC-120, and QIC-150 format tapes of fixed-512 blocks will not work. Tapes with a variable block size, such as the QIC-320 and QIC-525, will work with bootable tape.
Using an improperly configured QIC tape drive to create a bootable tape will result in an I/O error, a write error, or permission denied error. Therefore, you must take one of the following actions:
If creating a bootable tape with a UFS
file system
extends to multiple tapes, the
/sbin/dump
command displays a message indicating that the tape must be changed.
If the tape is not changed promptly,
warning messages repeat periodically until the tape is changed.
When you change the tape, the warning messages will stop.
When selecting disk partitions while restoring file systems from tape, add 5 percent to the needed file size displayed on the console.
A QIC tape created with the
btcreate
utility may fail with the following error when booted:
failed to send Read to mka...
Be sure that the tape is write protected before booting.
The behavior of the
open
call to a tape device has changed. You can no longer use
write
mode to open a write protected tape. The attempt to open the tape
will fail, returning the following message:
EACCES (permission denied).
If an application is written so that it attempts to
open the tape device with
O_RDWR
when the intention is only to read
the tape, the open attempt will fail. Applications should be changed to open the
device with
O_RDONLY.
For applications that cannot be changed, use the
following command to obtain the previous behaviour of the open call:
#
sysconfig -r cam_tape open_behaviour=0
The DIGITAL UNIX Server Extensions includes support for installing and
operating systems in a dataless configuration. A server system maintains
the
root,
/usr,
and
/var
file systems for all client systems. The server maintains one copy of root f
or each client. The
/usr
file system is exported read-only and is shared by all clients registered to the
environment. Each client has their own
/var
file system. Dataless clients access the file systems maintained on the
server utilizing NFS.
A dataless environment should be considered in the following scenarios:
root,
usr
and
var
file systems are resident on the server.
You should consider the following limitations when deciding to implement a dataless environment:
/usr
file system and all client
specific data is contained in a
/clients
file system on the server. As
clients are added to the dataless environment, the demands on these file
systems on the server increase and may surpass the capabilities of the
server.
The following notes apply to the use of enhanced security features.
The following restrictions apply to distributing enhanced security profiles via NIS:
rpc.yppasswdd
daemon must respond and update the last successful and last
unsuccessful login fields in the
prpasswd
NIS map.
yppush
operation initiated from the
rpc.yppasswdd
daemon. (Most successful logins do not require a
yppush
operation, but login failures and password changes do.)
The login process will not continue or terminate until both of these steps are completed.
The more NIS slave servers that are present in a given NIS domain, the
more time
rpc.yppasswdd
takes to complete these steps. Also, nearly-simultaneous login
attempts are processed sequentially by the NIS master, each waiting on
a possible
yppush
for the previous attempt to succeed. Therefore, if several
simultaneous attempts arrive at once, some may timeout and require you
to log in again. You can alleviate this problem to some extent by
using the
-p
option of
yppush.
One way to do this is to modify the
/var/yp/Makefile
file and change the
YPPUSH=
line. The following example allows up to 6 simultaneous transfers to
NIS slave servers (the default number is 4):
YPPUSH=$(YPDIR)/yppush -p 6
prpasswd
map, the more likely the time limit is to expire during a login
attempt, causing that attempt to fail. Simultaneous or
nearly-simultaneous login attempts will fail if the NIS master server
does not respond quickly enough to the pending login processes. If the
total time taken on the NIS master for the following commands exceeds
25 seconds, then there will be circumstances under which only one user
will succeed in logging in at a time:
#
cd /var/yp
#
make passwd prpasswd PRPWDPUSHONLY=1 NOPUSH='"'
You can decrease the time required for map transfers if you use the
btree
format to store the maps on all of your NIS servers.
With successful logins, the
rpc.yppasswdd
daemon will defer pushing the maps if the login notification comes
from a Version 4.0D client. Therefore, the
yppush
operation is only completed when an older client initiates the
operation or when it is necessary to clear a failed login count.
prpasswd
information may be able to use NFS to share the
/tcb/files
and
/var/tcb/files
directories instead. This requires you to export the directories with
root access to the participating nodes (with
-root=0
or
-root=client1:client2:client3
as appropriate). It also requires you to enable NFS locking to ensure
that no database corruption occurs. For more information, see the
exports(4)
reference page.
In previous releases of DIGITAL UNIX, NIS slaves that were listed in
the
ypservers
NIS map on the NIS master but that did not already have a copy of the
prpasswd
and
prpasswd_nonsecure
NIS maps may not have succeeded in transferring those maps during the
yppush
operation. This problem has been fixed for Version 4.0D and higher.
Because the user profile and
tty
information is now stored in database files, the previous recovery
method of editing the files while in single-user mode is no longer
available. However, as long as the
/usr
(and, if separate,
/var)
file systems are mounted, you can use the
edauth
utility in single-user mode
to edit extended profiles and ttys database entries.
If the
/etc/passwd
file is somehow lost, but the extended profiles are still available,
then you can use a command sequence as in the following example to
recover some of the missing data (the "\" characters indicate line
continuation):
#
bcheckrc
#
/tcb/bin/convuser -dn | /usr/bin/xargs /tcb/bin/edauth -g | \ sed '/:u_id#/!d;s/.*:u_name=//;s/:u_id#/:*:/;s/:u_.*$/:/' \ >psw.missing
This will create a
psw.missing
file containing entries like the following:
root:*:0:
Primary group information, finger information, home directory, and login shell are not recorded in the extended profile. You must recover the data for those fields by other means.
The Enhanced Security routines
pw_idtoname,
pw_nametoid,
gr_idtoname,
and
gr_nametoid
(described in
pw_mapping(3))
previously used the
/etc/auth/system/pw_id_map
and
/etc/auth/system/gr_id_map
files to find the required information for mapping names to numeric
identifiers, and vice versa. The disk space required by those files
imposed a limit on how many accounts a system could support.
The Enhanced Security routines no longer use the
pw_id_map
and
gr_id_map
files. If you are running DIGITAL UNIX Version 4.0D or later and
still have those files, it is recommended that you remove them to
recover the space occupied on the
root
paritition.
Logins with NIS-shared extended user profiles under Enhanced Security
have been streamlined, thus lifting the former restriction of 4,000
accounts. However, depending on the method chosen for building the
NIS maps (using
nissetup
or the
/var/yp/Makefile
file), the limits of the
ndbm
storage format may still impose a limit on the number of accounts
that can be shared through NIS. If you are sharing more than 10,000 accounts
with NIS, DIGITAL recommends that you use the
btree
storage format instead of
ndbm
(where practical). The limitations on NIS slave servers and NIS
master availability for use of the
prpasswd
NIS map are unchanged.
The
useradd
command correctly honors the default administrative
lock value found in the
/.sysman/Account_defaults file.
If
Account_defaults
does not exist, the internal default for
useradd
is to create locked accounts. You can use the
administrative_lock_applied
extended command line option to override the default. In the
following example,
useradd
creates a locked account for
foo
regardless of the default value for administrative lock:
useradd -x administrative_lock_applied=1 foo
For base security, a locked account has the text
Nologin
in the password field in the
/etc/passwd
file. If an account is unlocked and has no password, that account has
no value in the password field. The account is open and accessible to
anyone. A warning is displayed if an unlocked account with no
password is created.
For enhanced security, all accounts have an asterisk
(*)
in the password field in
/etc/passwd,
but the lock flag in the protected password database is correctly
set to reflect the lock status. As with base security, an unlocked
account with no password is accessible to anyone.
The
usermod
command correctly sets the lock flags for enhanced security when the
administrative_lock_applied
option is given on the command line. If
usermod
is used to unlock a locked account with no password, a warning is
displayed.
The
userdel
command will retire, instead of remove, accounts on a system running
enhanced security.
By default, extended UIDs are not enabled in the kernel. To enable this feature, use
sysconfig
or the
dxkerneltuner
interface to set the value of
variable
enable_extended_uids
to.
1
(enabled).
If you chose to do this, please note the following:
enable_extended_uids
can be set dynamically, you cannot disable it dynamically.
To disable
enable_extended_uids,
set the boot time value to
0
(disabled) and reboot your system.
The following notes apply to network and communications software.
When using
netconfig
while CDE is running, avoid restarting network services after
reconfiguring the primary network interface. This action can result
in error dialog boxes and may even cause CDE to hang. The problems
may not be observed until you use
bindconfig
to set up BIND.
In particular, do not use the following
netconfig
features while running a CDE session:
yes
to restart the network services from the
netsetup
or
netconfig
menu interfaces.
yes
to the following prompt after reconfiguring the primary network
interface from the
netconfig
graphical interface:
restarting network services
netconfig
graphical interface to start, stop, or restart the network.
netconfig
then use the
/usr/sbin/rcinet
stop, start, or restart options from the command line.
For the configuration changes to take effect, you must use
/sbin/reboot
or
/sbin/shutdown -r now
to reboot your machine from the command line.
The following restrictions apply when using IP switching over ATM:
ips)
per host is supported.
atmsig
command to start UNI signaling on a driver used for IP switching.
ips
interface,
tcpdump
and
packetfilter
are not supported.
/etc/atm.conf
file,
and not through the
atmsetup
utility.
This release does not support Orderly Release in XPG4 XTI (default XTI interface). It is still available for users of XPG3 XTI. See the Network Programmer's Guide for information on using XPG3 XTI.
When you use
netsetup
to restart the network, an error message similar to the following will
be displayed:
kill: 204: no such process
This problem also appears when you execute the following commands:
#
rcinet stop
#
rcinet restart
The message is incorrect and has no effect on your system.
In DIGITAL UNIX Version 4.0E, once you configure your interfaces using
netsetup,
view the
/etc/hosts
file and make sure that the hostname and the ip address of your system has been
added to this file. If not, then you need to add this information in the
/etc/hosts
file. Edit the
/etc/hosts
file as a root, and add the following line:
<your system's ip address> <your system's hostname> <any aliases for your system>
Example:
16.60.266.6 example.domain.com example
where:
16.60.266.6 = ip address of your system.
example.domain.com = fully qualified hostname of your system.
example = aliases for your system.
Refer to the
hosts(4)
reference page for further information regarding the
/etc/hosts
file.
The Common Desktop Environment (CDE) provides facilities and features for applications to communicate in a networked environment. After the network is configured and enabled, these features become available each time a new desktop session is started. After a desktop session has started, the current session has a static dependency on the state of the network configuration. Network and system administrators should be very cautious about dynamic changes to the network configuration while in a network-aware desktop session.
Prior to making any dynamic network changes, such as
changing the state of your network adapter to off or
changing your primary network address, add the following entry to the
/.dtprofile
file:
export DTNONETWORK=true
The system administrator must then log out and back in as root for the change to take effect. This change removes the dependency on the state of the network. Failure to do this may result in a session hanging after clicking on a CDE icon, such as the screen lock or Exit icons.
After all network changes are completed, remove the
export DTNONETWORK=true
entry from the
/.dtprofile
file.
The autosense feature has been removed from the Tulip Ethernet and Fast Ethernet driver. This feature automatically determined whether your Ethernet connection was 10BaseT (UTP, Twisted Pair), 10Base2 (BNC, Thinwire), or 10Base5 (AUI, Thickwire) during the boot sequence. It also attempted to select between 10 Mbps and 100 Mbps operation if applicable, but not between half-duplex and full-duplex mode.
The Tulip driver used autosense in those systems where the
Alpha SRM Console did not support or communicate (to the driver) the
setting of the
EW*0_MODE
environment variable. Autosense was also used as the default mode for
the EISA DE425 adapter.
In both cases, the default is now Twisted-Pair (half-duplex, 10 Mbps). If this new default is acceptable, then you do not need to do anything. Otherwise, you need to take one or more of the following actions:
EW*0_MODE
console environment variable for each
tu
or EW interface as desired.
lan_config
command to select the desired mode of operation. This command
overrides whatever was selected via the ECU or console
(EW*0_MODE
setting). You may use the
/etc/inet.local
configuration file to maintain
lan_config
settings across system restarts.
Refer to the
tu(7),
lan_config(8),
and
inet.local(8)
reference pages for more information.
Note that the autosense feature is different from autonegotiation. The autosense feature uses a software algorithm to determine what media is currently present on the given device, and the autonegotiation feature uses specific hardware for determining the speed (10/100) and mode (full duplex/half duplex). The autonegotiation feature is still available in the Tulip driver and there are no plans to retire it.
DIGITAL UNIX now provides support for detecting the physical loss of network connectivity, and subsequent automatic switchover to a working network interface. This feature is called Redundant Array of Independent Network adapters (NetRAIN).
NetRAIN uses two or more network interfaces to provide redundancy. Although only one interface at a time is actually used for communication, all interfaces are monitored to ensure that traffic is flowing on each. If the interface currently being used should suffer a loss of connectivity, NetRAIN will switch network traffic to the next working interface. All the context of the previous interface is maintained: hardware address, multicast addresses, and so on.
NetRAIN is configured through extensions to the
ifconfig
command. It also features a programming
interface via
ioctl()
for manual program control.
NetRAIN supports the following network adapters:
DECsafe ASE users should consult the DECsafe ASE software product description (SPD) for a list of network interfaces supported by that product.
When using NetRAIN over LANE it is recommended that you use UNI Version 3.1. With some ATM switches it is necessary to use UNI Version 3.1 to obtain acceptable failover times. This includes the Gigaswitch. If you use UNI Version 3.0, the failure over time may be long because of the T309 timer is default set to 90 seconds in some switches. If the T309 timer is adjustable on the switch, you may try to set the T309 timer to 10 seconds like UNI Version 3.1 for acceptable failover times.
For more details about NetRAIN, see the
nr(7)
and
ifconfig(8)
reference pages.
Local Area Transport (LAT) cannot be started on a system where a NetRAIN set has been configured.
Licensing schemes that use a network adapter's Media Access Control (MAC)
address to uniquely identify a machine can be affected by how NetRAIN changes
the MAC address. All network drivers support the
SIOCRPHYSADDR
ioctl that fetches MAC addresses from the interface. This ioctl returns two
addresses in an array:
Licensing schemes based on MAC addresses should use the default hardware address
returned by the
SIOCRPHYSADDR
ioctl; do not use the current physical
address as NetRAIN modifies this address for its own use. See the reference
page for your network adapter (for example,
ln(7)
and
tu(7)
) for a sample
program that uses the
SIOCRPHYSADDR
ioctl.
DIGITAL UNIX Version 4.0E includes a new version of the
sendmail
application, which includes as a feature the ability to specify an owner for
a mail alias, which can cause
the identity of the sender as passed on the mailer command line to be different
from the identity of the sender as specified in the From: header line. The end
result is that the recipient of the mail may see the wrong address identified
as the sender of the message.
If this problem is seen, the corrective action is to create a file,
/var/dna/defaults/Dnetrc.defaults
containing the following two lines:
mail11.SenderFromHeader: on mail11.FromLineToUse: From
The file
Dnetrc.defaults
is a configuration file read by the mail11
mailer. The above two options tell mail11 to take the sender id from
the header lines, and specificaly to get it from the From: line.
Then obtain the latest version of mail11v3 and replace the current
version in the
/usr/sbin
directory. The new mail11v3 will understand the above
option lines and use the appropriate sender id.
The following notes apply to Local Area Transport (LAT).
The
latsetup
utility sometimes creates devices with duplicate minor numbers.
If you manually create LAT BSD devices that do not match the valid BSD
tty
name space convention,
latsetup
can create devices with duplicate minor
numbers. For example, creating device
tty0
with a minor number 2 instead of 1 can cause this problem.
When a CTRL/A character is typed during a LAT tty session, all lowercase characters are converted to uppercase. Another CTRL/A changes the mode back to normal.
When doing a number of simultaneous
llogin
connections, you should use
llogin
with the
-p
option. To speed up an
llogin
connection, add the target host name as a reserved service.
You no longer need to build LAT into the kernel. LAT is not made a mandatory kernel option upon selecting the LAT subset and does not appear in the kernel configuration file. As LAT requires the Data Link Bridge (DLB), you must still build DLB into the kernel when using LAT.
The default behavior upon booting to multiuser mode is for LAT to be
dynamically loaded into the running kernel. If LAT is not started at
boot-time via the
/sbin/rc3.d/S58lat
script, the recommended method for starting and stopping LAT is to
verify that
LATSETUP
is enabled in
/etc/rc.config
and execute the
/sbin/init.d/lat
program, using the
start
or
stop
options.
The notes in this section apply to file systems.
When using the UNIX file system (UFS), there is a problem when
setting properties. Setting a property on a FAST symbolic link, a
block special file, or a character special file causes
fsck
to erroneously detect contradictory block counts and produce
inconsistent file system activity. There is no solution for this
problem and it will be fixed in a future release.
Starting with Version 4.0D, the
newfs
command no longer searches the
/etc/disktab
file for hard disk geometry information. It now performs an
ioctl GETDEVGEOM
call to determine the characteristics of a disk.
For an NFS client to make direct use of ACLs or extended attributes
(property lists) over NFS,
you must be enable the
proplistd
daemon on an NFS server. You also must use the
proplist
mount option when mounting on the client. Access checks are enforced
by the server in any case, although NFSv2 client caching could
sometimes cause inappropriate read access to be granted. Correctly
implemented NFSv3 clients make the necessary access checks.
Start the
proplistd
daemon by selecting the number of
proplist
daemons to run when you use the
nfssetup
utility. You can also use the
proplistd
command to start the daemon manually:
#
/usr/sbin/proplistd 4
On the client, the file system must be mounted with the
proplist
option by either of the following methods:
proplist
to the options field in the
/etc/fstab
file:
sware1:/advfs /nfs_advfs nfs rw,proplist 0 0
#
mount -o proplist sware1:/advfs /nfs_advfs
See the
acl(4),
fstab(4),
proplist(4),
mount(8),
nfssetup(8),
and
proplistd(8)
reference pages for more information. Note that the
proplist
option is not documented in
mount(8).
On AdvFS file systems there is a hard limit of 1560
bytes for a property list entry. Since Access Control Lists (ACLs)
are stored in property list entries, this equates to 62 ACL
entries in addition to the three required ACL entries. The
EINVAL
error is returned if you attempt to exceed this limit.
To facilitate interoperation of the UFS and AdvFS ACLs, a
configurable limit has been imposed on UFS ACLs. The default
value of the UFS limit is 1548 bytes, equivalent to the 65-entry
limit on AdvFS. The UFS configurable limit on ACLs has been
added to the
sec
subsystem and has been given the attribute name
ufs-sec-proplist-max-entry.
You can use the
sysconfig
utility to dynamically configure the attribute or you can use
sysconfigdb
or
dxkerneltuner
to statically configure the attribute in the
/etc/sysconfigtab
file.
A configurable property list element size for UFS has also been added
to the
sec
subsystem and has been given the attribute name
ufs-proplist-max-entry.
The value of
ufs-proplist-max-entry
must be larger than
ufs-sec-proplist-max-entry
by enough space to hold a property list element header. The
sysconfig
utility adjusts the
ufs-proplist-max-entry
attribute automatically. The default value of
ufs-proplist-max-entry
is 8192 bytes.
See the
cfgmgr(8),
seconfig(8),
seconfigdb(8),
sysconfig(8),
and
sysconfigdb(8)
reference pages for more information.
The following notes discuss features, problems, and restrictions of the Advanced File System (AdvFS).
For information about recovering from AdvFS domain panics and
correcting an overlapping
frag
data corruption problem, see
Appendix F.
You can use the
fsync()
system call to synchronously write dirty file data to
disk. There are two ways a file can have dirty data in memory. One way
is via the
write()
system call. The other is from a memory write reference after an
mmap()
system call. For AdvFS files, the
fsync()
system call writes out dirty data only from the
write()
system call.
If dirty data from an
mmap()
also needs to be written then you must also use the
msync()
system call.
You can reuse a partition that was previously part of an AdvFS domain.
However, before you reuse the partition, you must remove the domain on the
partition you want to reuse. Use the
rmfdmn
command to remove the entire domain. After the unused domain is
removed, you can create a new domain on the partition.
Under certain conditions, the disk usage information on an AdvFS file system
may become corrupted. To correct this, turn on quotas in the
/etc/fstab
file for the affected file system, and then run the
quotacheck
command on the file system. This should correct the disk usage
information.
AdvFS ordinarily does not allow a domain to be mounted if another
domain is already mounted with the same domain ID. However, in some cases,
such as a split mirror dual-mount, you may want to bypass this restiction.
You can do this by using the
-o
dual option to the
mount
command. When this option is used, AdvFS assigns a new
domain ID to the domain being mounted.
When a
read()
system call is made to a fileset's files, the default
behavior is for AdvFS to update both the in-memory file access time and
the on-disk stat structure, which contains most of the file information
that is returned by the
stat()
system call.
You can improve AdvFS performance for proxy servers by
specifying at mount time that AdvFS update only the in-memory file access
time when a
read()
system call is made to a file. AdvFS will update
the on-disk stat structure only if the file is modified.
To enable this feature, use the
mount
command
noatimes
option.
See the
read(2)
and
mount(8)
reference pages for more information.
Updating only the in-memory file access time for reads can improve proxy server response time by decreasing the number of disk I/O operations. However, this behavior jeopardizes the integrity of read access time updates and violates POSIX standards. Do not use this feature if it will affect utilities that use read access times to perform tasks, such as migrating files to different devices.
If your system opens and then reuses many files (for example, if you have a proxy server), you may be able to improve AdvFS performance by increasing the number of AdvFS access structures that the system places on the access structure free list at startup time.
AdvFS access structures are in-memory data structures that AdvFS uses to cache low-level information about files that are currently open and files that were opened but are now closed. Increasing the number of access structures on the free list allows more open file information (metadata) to remain in the cache, which can improve AdvFS performance if the files are reused.
However, allocating more AdvFS access structures on the free list will decrease the memory that is available to processes and to the UBC.
Use the
AdvfsPreallocAccess
attribute to modify the number of
AdvFS access structures that the system allocates at startup time.
The default and minimum values are 128. The maximum value is either
65536 or the value of the
AdvfsAccessMaxPercent
attribute, whichever is
the smallest value. The
AdvfsAccessMaxPercent
attribute specifies
the maximum percentage of the malloc pool (pageable memory) that
can be used for AdvFS access structures.
By using the
/usr/sbin/chfile
command, you can now activate
atomic write data logging for individual files in an AdvFS domain.
Atomic write data logging is a mode of performing writes to a file
that differs from the normal, asynchronous mode that is typical
of UNIX file systems, and from the forced synchronous write mode
available through the
-l
switch to the
/usr/sbin/chfile
command.
When atomic write data logging is activated, writes to a file are done asynchronously. They are, however, also written to the AdvFS log file. This has the effect that if the system crashes any time during or after a write system call and the contents of the file are examined upon reboot, only entire write requests will be present in the file.
For example, if a write of a 8192-byte buffer were done to the file and either during the write system call or shortly thereafter the system crashed, upon reboot either the entire 8192 bytes of data would be found in the file or none of it would be found there. There is no possibility that only 1024, or 2048 bytes of the write, for example, would be in the file.
You can also activate and deactivate this feature using the
fcntl()
system call. In addition, both
/usr/sbin/chfile
and
fcntl()
can be used on an NFS client to activate or deactivate this feature on a file
that resides on the NFS server.
Note that because atomic write data logging causes user data to be written to both the user's file and the AdvFS log file, writes to files with Atomic Write Data Logging enabled will be slower than normal, asynchronous writes.
Refer to the
fcntl(2)
and
chfile(8)
references pages for more information.
AdvFS writes data to disk in 8 KB chunks. By default and in accordance with POSIX standards, AdvFS does not guarantee that all or part of the data will actually be written to disk if a crash occurs during or immediately after the write. For example, if the system crashes during a write that consists of two 8 KB chunks of data, only a portion (anywhere from 0 to 16 KB) of the total write may have succeeded. This can result in partial data writes and inconsistent data.
To prevent partial writes if a system crash occurs, you can use the
chfile -L on
command to enable atomic write data logging for a specified file.
By default, each file domain has a transaction log file that tracks fileset activity and ensures that AdvFS can maintain a consistent view of the file system metadata if a crash occurs. If you enable atomic write data logging on a file, data from a write call will be written to the transaction log file before it is written to disk. If a system crash occurs during or immediately after the write call upon recovery, the data in the log file can be used to reconstruct the write. This guarantees that each 8 KB chunk of a write is either completely written to disk or is not written to disk.
For example, if atomic write data logging is enabled and a crash occurs during a write that consists of two 8 KB chunks of data, the write can have three possible states: none of the data is written, 8 KB of the data is written, or 16 KB of data is written.
Atomic write data logging may degrade AdvFS write performance because of
the extra write to the transaction log file. In addition, a file
that has atomic write data logging enabled cannot be memory mapped by
using the
mmap()
system call.
A file cannot have both forced synchronous writes enabled and atomic write
data logging enabled. However, you can enable atomic write data logging
on a file and also open the file with an
O_SYNC
flag. This ensures that the write is synchronous, but also prevents partial
writes if a crash occurs.
Use the
chfile
command with no flags in order to determine if forced
synchronous writes or atomic write data logging is enabled. Use the
chfile -L off
command to disable atomic write data logging (the default).
To enable atomic write data logging on AdvFS files that are NFS mounted, the
NFS property list daemon,
proplistd
, must be running on the NFS client and the
fileset must be mounted on the client by using the mount command's
proplist
option.
If atomic write data logging is enabled and you are writing to a file that has been NFS mounted, the offset into the file must be on an 8 KB page boundary, because NFS performs I/O on 8 KB page boundaries.
Starting with DIGITAL UNIX Version 4.0E, attempts to memory map
an AdvFS file using the
mmap()
system call will fail if the file has had atomic write data logging activated
on it. Use the
chfile
command to determine if a file is using atomic write data logging.
If the
chfile
command displays the following, attempts to memory-map
the file using the
mmap()
system call will fail:
I/O mode = atomic write data logging
To deactivate the atomic write data logging, enter the following command:
#
chfile -L off
filename
For more information on atomic write data logging, see the
chfile(8)
references page.
If a system crashes or goes down unexpectedly due to a loss of power or other similar circumstances, AdvFS will perform recovery the next time that the filesets that were mounted at the time of the crash are remounted after rebooting. This recovery keeps the AdvFS metadata consistent and makes use of the AdvFS log file.
Different versions of DIGITAL UNIX use different AdvFS log record types. Therefore, it is important that AdvFS recovery be done on the same version of DIGITAL UNIX that was running at the time of the crash. For example, if your system is running DIGITAL UNIX Version 4.0E and the system crashes, do not reboot using DIGITAL UNIX Version 3.2G, because that version of AdvFS may not be able to work with the log records that the DIGITAL UNIX Version 4.0D system put into the log.
Therefore, if you want to reboot using a different version of DIGITAL UNIX,
make sure that any mounted AdvFS filesets are unmounted cleanly
before rebooting. In addition, if the system panicked or an
AdvFS domain was domain panicked, it is best to reboot using the
original version of DIGITAL UNIX and run the
/sbin/advfs/verify
command to make sure that the domain is not corrupted. If it is not,
it is then safe to reboot using a different version of DIGITAL UNIX
and remount the filesets.
The AdvFS tool
verify
will report the following error when it is run on a Version 4.0 domain which was created
with the
mkfdmn
command using the
-p
flag:
Checking mcell list ... set_mcell_position: position field already set disk: 1, mcell id (page.cell): 0.6 set tag: -2.0 (0xfffffffe.0x00000000) tag: -6.0 (0xfffffffa.0x00000000)
This error message can be ignored.
The following notes describe problems and restrictions of the Logical Storage Manager (LSM).
Under certain hardware failure scenarios, an LSM volume configured with a sparse plex may erroneously return success to the file system or application when in fact the I/O failed. DIGITAL recommends that you do not configure volumes with sparse plexes.
Root, primary swap, and secondary swap volumes configured under LSM have the following restrictions:
rootdg.
Physical block 0 on DIGITAL disks is typically write protected by default. If
a disk is added to LSM by using the
voldiskadd
utility, physical block 0 is skipped. However, if a partition that includes
physical block 0 is encapsulated into LSM by using the
volencap,
vollvmencap,
or
voladvdomencap
utility, physical block 0 is not skipped. This is not a problem because the
file system already skips block 0 and does not write to it.
A problem can occur when an LSM volume that contains a write-protected block 0 is dissolved and its disk space is reused for a new purpose. Neither the new application nor LSM know about the write-protected physical disk block 0 and a write failure can occur.
To fix this problem, use the following steps to remove the write-protected physical disk block 0 from the LSM disk before it can be assigned to the new volume:
voldg
and
voldisk
commands to remove the disk from LSM.
voldiskadd
command to add either a specific partition of the disk
or the entire disk to LSM.
When you create an LSM mirror using a disk that is configured as Just-a-Bunch-of-Disks (JBOD) with either the SWXCR-P or SWXCR-E RAID controllers, a disk failure requires that you reconfigure the disk on the controller. The disk is in an unusable state once it is set off line by the controller and cannot be used by LSM until it is reconfigured. Refer to the StorageWorks RAID Array 200 Subystem Family Installation and Configuration Guide.
If you use the
setld
utility to install LSM after you originally install DIGITAL UNIX,
you must rebuild the system kernel to enable LSM.
To rebuild the kernel, run the
doconfig
utility with no command flags. Note that the
doconfig
menu display does not include LSM. However, the
doconfig
utility will build a kernel that includes LSM. Refer to the
Logical Storage Manager
guide for more information.
Only
LUN 0
is supported as a boot device by the console. Hence, you can
only mirror the LSM
rootvol
and
swapvol
volumes to
LUN 0
in an
HSZ.
Therefore, when you use the
volrootmir
script to mirror
rootvol
and
swapvol,
use only
LUN 0
on an
HSZ
as an argument to the
volrootmir
script.
If you use the LSM
rootvol
volume for the root file system and
the
swapvol
volume is in use as a primary swap volume, LSM adds the following entries to
the
/etc/sysconfigtab
file to enable rootability:
lsm: lsm_rootvol_is_dev=1 lsm_swapvol_is_dev=1
If these entries are deleted or if the
/etc/sysconfigtab
file is deleted, the system will
not boot. If this happens, you can boot the system interactively
as follows (the "\" character indicates line continuation):
>>>
boot -fl i
......... .........
Enter
kernel_name option_1 ... option_n:
vmunix \ lsm_rootdev_is_volume=1
Use the
sysconfigdb
utility to add the LSM entries as shown above to the
/etc/sysconfigtab
file after the system boots. Then, reboot the system for the changes
to take effect.
The Associated Products CD-ROMs (APCDs) can be mounted with
the usual
mount
command on DIGITAL UNIX systems running Version 4.0E, as follows:
#
mount -r /dev/rz4c /mnt
On releases prior to Version 4.0E, the APCDs must be mounted with additional options, as follows:
#
mount -r -t cdfs -o rrip /dev/rz4c /mnt
On versions of DIGITAL UNIX prior to 4.0D you may receive the following error indicating that CDFS support is not built into the current running kernel:
#
mount -r -t cdfs -o rrip /dev/rz4c /mnt
/dev/rz4c on /mnt: No valid filesystem exists on this partition
If you receive this error, you need to build your kernel with the following option:
ISO 9660 Compact Disc File System (CDFS)
The
proc
subsystem's
open-max-soft
and
open-max-hard
attributes control the maximum number of open file descriptors for each process.
When the
open-max-soft
limit is reached, a warning message is issued, and when the
open-max-hard
limit is reached, the process is stopped. These attributes prevent runaway
allocations (for example, allocations within a loop that cannot be exited
because of an error condition) from consuming all the available file
descriptors.
The
open-max-soft
and
open-max_hard
attributes both
have default values of 4096 file descriptors (open files) per process, which is
the maximum, systemwide value.
If an application requires many open files, you can increase the open file
descriptor limit for that application above the maximum that is supported by the
proc
subsystem (4096). Increasing the maximum limit up to 65,536 provides more file
descriptors to the process, but it increases the possibility of runaway
allocations. In addition, if you increase the number of open files for a
process, make sure that the
max_vnodes
attribute is set to an adequate value. See
Appendix E
for information about increasing the open file descriptor limit for an application.
Decreasing the open file descriptor limit decreases the number of file descriptors available to each process and prevents a process from consuming all the file descriptors. However,decreasing the limit may adversely affect the performance of processes that require many file descriptors.
The Prestoserve subsystem attribute
presto-buffer-hash-size
controls the size of the Prestoserve buffer cache. The minimum value is 0, and
the maximum value is 64 KB. The default value is 256 bytes.
Under certain circumstances, Netscape Navigator may crash upon
invocation when the current locale is
ja_JP.deckanji.
If this happens, a workaround for the problem is to add the
following four lines to the
/usr/i18n/lib/X11/ja_JP.deckanji/app-defaults/Netscape
file:
netscape.xnlLanguage: ja_JP.eucJP netscape.XnlLanguage: ja_JP.eucJP Netscape.xnlLanguage: ja_JP.eucJP Netscape.XnlLanguage: ja_JP.eucJP
This will force Navigator to run in the
ja_JP.eucJP
locale to avoid the crash.