Administering SCO OpenServer

Troubleshooting SCOadmin

This section addresses problems with running SCOadmin:

SCOadmin will not start

If the SCOadmin launcher or a SCOadmin manager fails to start after a reasonable length of time, there may be a problem with the SCO Visual Tcl daemon process used to run SCOadmin:

Enter this command to determine the process number:

ps -ae | grep vtcld
You see output similar to this:
```
   571   ttyp0    00:00:00 xm_vtcld
```
In this case, the daemon is process number 571. (In character mode, the process is named cm_vtcld.)
Kill the daemon process with this command, substituting the actual process number for number:

kill -9 number
If the process does not appear to be running, you should check the /tmp directory for temporary files left there by SCO Visual Tcl daemons. First, SCOadmin character sessions leave files of the format ch_PID.UID (PID is the process ID number and UID is the user ID number), for example ch_8132.0. Graphical sessions can leave similar files of the format PID.UID. If there are a large number of these files present, you should remove them and try running SCOadmin again.

Recovering from SCOadmin failures in character mode

If a SCOadmin manager fails in character mode and you cannot get a prompt, enter the following command to restore your display to normal (the command will not appear on the screen as you type):

<Ctrl>jstty sane<Ctrl>j

Remote administration problems

If you have problems performing remote administration:

Ensure that user equivalence is configured properly. The account on the local system used to perform the remote task must be recognized by the remote system. In addition, the account must have the authorizations necessary to run the SCOadmin manager.
Verify your network connections are configured and functional (including the /etc/hosts file or name service).
Verify that SCOadmin is running on the remote system. This is necessary for all tasks except remote printing. You can set up a printer on a remote system that is not running SCOadmin, but the remote system must support LPD, and the local system must be recognized by the remote system (in /etc/hosts.lpd or /etc/hosts.equiv on UNIX systems). If the remote system is running SCOadmin, it is possible to get a list of the printers available on the system.

SCOadmin error trace

When a non-recoverable error occurs in SCOadmin, SCO Visual Tcl creates a file containing an error trace. The output is put into a file in the /tmp directory. While the SCO Visual Tcl output will probably not be useful to you, if the problem persists you should save the output when you call your provider for assistance.

Error filenames use the format:

tclerror.PID.log

where PID is the number of the process that created the file. Here is a sample output:

   Uncaught error in Tcl program: hostmib:
   no SMUX entry for hostmib: goingDown
   
   ----------------------------------------------------------------------
   Error code = NONE
   ----------------------------------------------------------------------
   no SMUX entry for hostmib: goingDown
   

       while executing
   "SMUXInit hostmib /etc/sysadm.d/hostmib.defs"
       ("uplevel" body line 3)
       invoked from within
   "uplevel $command"
   ======================================================================

The SCOadmin event log

SCOadmin includes a logging facility to record administrative events, including errors, object creation, among others.

SCOadmin events are recorded along with other system events in /usr/adm/syslog. These events help you keep track of all modifications made to your system configuration.

NOTE: Do not confuse messages contained in the SCOadmin event log with the system error messages located in /usr/adm/messages.

Understanding the SCOadmin event log

All SCOadmin managers generate records of administrative events that occur during the daily operation of your system. By default, SCOadmin errors are the only events recorded. This allows you to monitor any problems that might occur. You can also elect to record all administrative changes made to the system, for example when a user account is added to the system or modified.

Log entries use this format:

date sysname syslog SCOADM: sessionID object instance event_type message

sysname: name of the host system
sessionID: tty for the login session when the event took place
object: type of object
instance: name of object
event_type: event type
message: the system message associated with the event

Here is an example:

   Jul 12 22:27:38 apathy syslog: SCOADM: localhost {sco_printer}
   {toaster1} objectCreation SCO_OFACE_MSG_OBJECT_CREATION {object
   creation {(null)}}

The event types are:

Object creation: The creation of an object, such as a new printer.
Object deletion: The deletion of an object, such as a printer.
Attribute change: The modification of an object, such as the configuration values for a printer.
Error: A failure to complete a requested action, typically called an error message.
Warning: An action was completed successfully, but with a problem.
Notice: An informative message.

You can modify the list of event types by editing the /usr/adm/events file.

Using the SCOadmin Event Logs Manager

You can select events to be logged using the SCOadmin Event Logs Manager located in the System/Logs directory of the SCOadmin hierarchy. The SCOadmin Event Logs Manager displays the events currently logged and not logged.

To log an event, highlight it in the ``Ignored Events'' column and click on the Log event button.

To ignore an event, highlight it in the ``Logged Events'' column and click on the Ignore event button.

To save your selections, select Save from the File menu.