- 论坛徽章:
- 0
|
18．Srmount error
Cause
This error is RFS specific. It occurs when an attempt is made to stop RFS while resources are still mounted by remote machines, or when a resource is readvertised with a client list that does not include a remote machine with the resource currently mounted.
Technical Notes
The symbolic name for this error is ESRMNT, errno=69.
19．Stale NFS file handle
Cause
A file or directory that was opened by an NFS client was either removed or replaced on the server.
Action
If you were editing this file, write it to a local file system instead. Try remounting the file system on top of itself or shutting down any client processes that refer to stale file handles. If neither of these solutions works, reboot the system.
Technical Notes
The original vnode is no longer valid. The only way to remove this error is to force the NFS server and client to renegotiate file handles.
Th20．statd: cannot talk to statd at string
Cause
This message comes from the NFS status monitor daemon statd(1M), which provides crash recovery services for the NFS lock daemon lockd(1M). The message indicates that statd(1M) has left old references in the /var/statmon/sm and /var/statmon/sm.bak directories. After a user has removed or modified a host in the hosts database, statd(1M) might not properly purge files in these directories, which results in its trying to communicate with a nonexistent host.
Action
Remove the file named variable (where variable is the host name) from both the /var/statmon/sm and /var/statmon/sm.bak directories. Then kill the statd(1M) daemon and restart it. If that does not get rid of the message, kill and restart lockd(1M) as well. If that remedy does not work, reboot the machine at your convenience.
21．stty: TCGETS: Operation not supported on socket
Cause
This message occurs when a user tries to use remote copy with rcp(1) or remote shell with rsh(1) from one machine to another, but has an stty(1) command in the remote .cshrc file. This error creates failure for the rcp(1) or rsh(1) command.
Action
The solution is to move the invocation of the stty(1) command to the user's .login (or equivalent) file. Alternatively, execute the stty(1) command in .cshrc only when the shell is interactive. You could perform the following test:
if ($?prompt) stty ...
Technical Notes
The rcp(1) and rsh(1) commands make a connection using sockets, which do not support stty(1)'s TCGETS ioctl.
22．su: No shell
Cause
This message indicates that someone changed the default login shell for root to a program that is missing from the system. For example, the final colon-separated field in /etc/passwd could have been changed from /sbin/sh to /usr/bin/bash, which does not exist in that location. Possibly an extra space was appended at the end of the line. The outcome is that you cannot login as root or switch user to root, and, thus, cannot directly fix this problem.
Action
The only solution is to reboot the system from another source, then edit the password file to correct this problem. Invoke sync(1M) several times, then halt the machine by typing Stop-A or by pressing the reset button. Reboot as single-user from CD-ROM, the net, or diskette, such as by typing boot cdrom -s at the prompt.
After the system starts and gives you a # prompt, mount the device corresponding to the original root partition somewhere, such as with a mount(1M) command similar to the one that follows. Then run an editor on the newly mounted system password file (use ed(1) if terminal support is lacking):
# mount /dev/dsk/c0t3d0s0 /mnt
# ed /mnt/etc/passwd
Use the editor to change the password file's root entry to call an existing shell, such as /usr/bin/csh or /usr/bin/ksh.
Technical Notes
To keep the No shell problem from happening, habitually use admintool or /usr/ucb/vipw to edit the password file. These tools make it difficult to change password entries in ways that make the system unusable.
23．su: 'su root' failed for login on /dev/pts/int
Cause
The user specified by login tried to become superuser, but typed the wrong password.
Action
If the user is supposed to know the root password, wait to see if the correct password is supplied. If the user is not supposed to know the root password, ask why he or she is attempting to become superuser.
24．su: 'su root' succeeded for login on /dev/pts/int
Cause
The user specified by login just became superuser by typing the root password.
Action
If the user is supposed to know the root password, this message is only informational. If the user is not supposed to know the root password, change this password immediately and ask how the user learned it.
25．SunPC may NOT run correctly as root
Cause
With SunPC 4.1 and the 102924 jumbo patch installed, a user (who is not root) attempts to run SunPC and receives the following error message:
SunPC may NOT run correctly as root.
Please run in user mode.
SunPC script is exiting
The user's primary group ID is probably root. For example:
$ /usr/bin/id
uid=33650(gruff) gid=0(root)
Action
Change the user's primary group to another group, such as 10, and, because the user still needs to be in the root group, add the root group to the user's secondary group list.
26．syncing file systems...
Cause
This message indicates that the kernel is updating the super-blocks before taking the system down to ensure file system integrity. This message appears after a halt(1M) or reboot(1M) command. It can also appear after a system panic, in which case the system might contain corrupted data.
Action
If you just halted or rebooted the machine, take no action. This message is normal. In case of a system panic, look up the panic messages. Your system vendor might be able to help diagnose the problem. So that you can describe the panic to the vendor, either leave your system in its panicked state or be sure that you can reproduce the problem.
Technical Notes
Numbers that sometimes display after the three dots in the message show the count of dirty pages that are being written out. Numbers in brackets show an estimate of the number of busy buffers in the system.
27．syslog service starting.
Cause
During system reboot, this message might appear and the boot seemingly hangs. After starting syslogd(1M) service, the system runs /etc/rc2.d/S75cron, which in turn calls ps(1). Sometimes after an abrupt system crash /dev/bd.off becomes a link to nowhere, causing the ps(1) command to hang indefinitely.
Action
Reboot as a single user (for example with boot -s) and run ls -l /dev/bd* to see if this is the problem. If so, remove /dev/bd.off, then run bdconfig off or reboot with the -r (reconfigure) option.
This is the most commonly reported situation that causes ps(1) to hang.
28．System booting after fatal error FATAL
Cause
The system reboots automatically. Afterward, the messages file contains System booting after fatal error FATAL.
The message is issued during a reboot after the system detects a hardware error. The following can cause this response: UPA address parity error, Master queue overflows, DTAG parity errors, E-Cache tag parity errors, and Coherence errors.
Action
Use prtdiag(1M) to help identify failed hardware components. The errors indicate that you either have a bad CPU module or a bad system board.
e symbolic name for this error is ESTALE, errno=151. |
|
免费注册
发表于 2007-02-12 15:02
发表于 2007-02-13 08:40
