)
Figure 9-3 Port monitor state model.
| Previous | Table of Contents | Next |
Refer to Chapter 10, "Setting Up Modems and Character Terminals," for information about how to configure, start, and enable the ttymon port monitor. Refer to Chapter 11, "Setting Up Printing Services," for information about how to configure, start, and enable the listen port monitor.
To view the contents of the port monitor administrative file, type pmadm -l and press Return.
oak% /usr/sbin/pmadm -l PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC> zsmon ttymon ttya u root /dev/term/a I - ➥/usr/bin/login - 96ØØ ldterm,ttcompat ttya login: - tvi925 y # zsmon ttymon ttyb u root /dev/term/b I - ➥/usr/bin/login - 96ØØ ldterm,ttcompat ttyb login: - tvi925 y # oak%
In this example, the ttymon ports /dev/term/a and /dev/term/b show the default Solaris 2.x configuration. Table 9-2 describes the fields shown in the output of the pmadm -l command.
| Field | Description |
|---|---|
| PMTAG | A unique tag that identifies a particular port monitor. The system administrator assigns the name of the port monitor. The pmtag is used by the sac to identify the port monitor for all of the administration. Use the default pmtag zsmon for ttymon ports; use the pmtag tcp for listen ports. PMTAG can contain up to 14 alphanumeric characters. |
| PMTYPE | The type of the port monitor: ttymon or listen. |
| SVCTAG | A tag unique to the port monitor that identifies a service. The service tags for the serial ports are ttya and ttyb. A service requires both a service tag and a port monitor tag to uniquely identify it. |
| FLGS | If no flag is specified, the port is enabled and no utmp entry is created for the service. The x flag specifies that the port should not be enabled; the u flag specifies that a utmp entry should be created for this service. Some services, such as login, will not start unless a utmp entry has been created. |
| ID | The login name of the person who starts the service, typically root. |
| PMSPECIFIC | The address, name of a process, name of a STREAMS pipe, or baud rate and configuration for a login port. |
The ttymon STREAMS-based port monitor performs the functions provided by the getty process in SunOS 4.x system software. In addition, ttymon initializes and monitors tty ports, sets terminal modes and line speeds, invokes service on serial ports when it receives a connection request, and idles while a service is connected.
NOTE: In Solaris 2.x, the serial ports /dev/term/a and /dev/term/b are provided with a default configuration for the ttymon port monitor with a pmtag of zsmon.
Each instance of ttymon can monitor multiple ports, as specified in the port monitor's administrative file. You configure the administrative file using the pmadm and ttyadm commands.
When an instance of ttymon is started by the sac daemon, ttymon starts to monitor the daemon's ports. For each port, it first initializes the line disciplines, if specified, and the speed and terminal settings. The values it uses for terminal initialization are taken from the appropriate entry in the tty settings file, which is maintained by the sttydefs command. Default line disciplines on ports are set up by the autopush(1M) facility. You do not need to do anything to configure autopush.
The listen process "listens" for network service requests, accepts requests when they arrive, and starts services in response to the requests.
NOTE: No listen processes are started by default in Solaris 2.x system software.
The listen process provides services similar to those provided by the traditional Internet Services daemon, inetd. In Solaris 2.x system software, the inetd daemon is started with the -s option to run standalone outside of the SAF.
CAUTION! Solaris 2.x does not support running inetd under SAF. Be sure that the -s option is always present.
A service invocation is a process that provides the requested service to the incoming connection request. A service invocation can be a process such as login or lp. The ttymon port monitor works only with the login process, and the listen port monitor works only with the LP print service. The SAF architecture is structured so that programmers can write new port monitors to support other processes specified by the port monitor.
Once added, port monitors can be operational, transitional, or inactive in one of the six states shown in Figure 9-3.
Figure 9-3 Port monitor state model.
Port monitor operational states are ENABLED and DISABLED. Port monitors are started and enabled by default when you add them. Port monitors are stopped and disabled by default when you remove them. When a port monitor is enabled, it accepts requests for service. When a port monitor is disabled, existing services continue, but new service requests are refused. When a port monitor service is killed, all of its services are terminated.
A port monitor may be STARTING or STOPPING. When a port monitor is in the process of starting, it is in an indeterminate state in the process of becoming either ENABLED or DISABLED. When a port monitor is stopping, it has been terminated manually but has not yet completed its shutdown procedure. Consequently, it is in an indeterminate state in the process of becoming NOTRUNNING.
An inactive port monitor is either NOTRUNNING or has FAILED. A failed port monitor is unable to start and remain running. When a port monitor is not running, it has been killed. All ports it was monitoring are inaccessible. Unlike the disabled state, when a port monitor is not running, the system cannot write a message on the inaccessible port telling the user that it is disabled. If the message option is not used, an external user cannot determine whether a port is disabled or not running.
| Previous | Table of Contents | Next |
){kind=link}