Documentation Contents

Configuring inetd to Launch rmid

On the Solaris Operating System (Solaris OS), the Internet services daemon inetd provides an alternative to starting up services at system boot time. This daemon, a server process for Internet standard services, can be configured to start services on demand. For details on the Internet services daemon, see the Solaris OS inetd(1M) man page.

inetd can be configured to start the Java RMI activation daemon rmid on demand. In this case, rmid does not need to be started up at boot time or started up manually. Instead, rmid will be started when a client attempts to connect to it, such as in order to activate an object.

Note: If restartable services are registered with rmid, rmid should be started at system boot type (not by inetd) so that the restartable services are always running when the system is up.

To configure inetd to launch rmid, you will need to add an entry to each of two configuration files that inetd uses, /etc/inetd.conf and /etc/services. Editing these files requires root access to the machine that rmid will run on.

After inetd has been reconfigured, you should test your configuration to make sure that it works properly.

This tutorial has the following steps:


Configure /etc/inetd.conf

The /etc/inetd.conf configuration file contains entries for the services to be launched when inetd receives a request over a socket. For details on the format of this configuration file see the Solaris OS inetd.conf(4) man page.

To configure inetd to launch rmid, add the following entry to the /etc/inetd.conf configuration file (requires root access to the machine):

rmid stream tcp wait nobody jreHome/bin/rmid  \
     rmid -log logDir/rmid.log rmidOptions
where jreHome is a path to the installed JRE, logDir is the directory for the log file, and rmidOptions is any other options for rmid (for example, property initializations). When rmid is launched by inetd the -log option must be specified, and the -port option must not be specified, since the port is derived from the /etc/services configuration.

If rmid needs to be run as a user other than nobody, replace nobody above with the user ID under which rmid should run.

Configure /etc/services

Next, rmid needs to be listed as a service in the /etc/services configuration file. For details on the format of this configuration file see the Solaris OS services(4) man page.

To list rmid as a service, add the following entry to the /etc/services configuration file (requires root access to the machine):

rmid        port/tcp

where port is the port number for the ActivationSystem and the Activator remote objects that rmid exports. This port number is typically 1098, but another port number can be used as long as the clients and activatable services define the system property java.rmi.activation.port to that port.

Force inetd to read its new configuration

Now that the configuration has been modified, inetd needs to read the new configuration so that it can listen on the appropriate ports for the services that are configured.

But first, it is important to make sure that rmid is not already running. To do this, run the following command:

% ps -ef | grep rmid

If the above command does not print out the information for a running rmid process, then rmid is not running. If it does, then you will need to shut down rmid first before continuing.

Next, inetd needs to read its new configuration. To force inetd to reread its configuration, the running inetd process must be sent a hangup signal. First, find the process ID for the running inetd process by running the following command:

% ps -ef | grep inetd

which will print out something like this:

root   171     1  0   Sep 30 ?        0:02 /usr/sbin/inetd -s

In this example, the process ID for inetd is 171. Now, the inetd process can be sent a hangup signal by running the following command and supplying the process ID (requires root access):

% kill -HUP 171

Now, inetd is all set to launch rmid when a program attempts to connect to the port configured above.

Test your configuration

To test that inetd is configured properly, you can run a simple program that looks up the ActivationSystem which will, in turn, cause inetd to launch rmid if the configuration is correct.

The following is a simple program to look up the ActivationSystem on a port, supplied as the value of the java.rmi.activation.port system property:

package example.inetd;

import java.rmi.activation.ActivationSystem;
import java.rmi.activation.ActivationGroup;

public class GetActivationSystem {

    public static void main(String[] args) throws Exception {

        ActivationSystem system = ActivationGroup.getSystem();
        System.err.println("ActivationSystem = " + system);
    }
}

Compile and run this program as follows:

% javac -d classDir GetActivationSystem.java
% java -classpath classDir -Djava.rmi.activation.port=port 
example.inetd.GetActivationSystem
where classDir is the class path for this example class, and port is the port for the ActivationSystem configured for rmid in the /etc/services file.

If the program prints out the ActivationSystem successfully then rmid was launched by inetd.

If the program either hangs or prints an exception trace, check the output file produced by rmid. When rmid is launched by inetd, any output written to System.err is written to a file located in the directory specified by the property java.io.tmpdir, typically /var/tmp on the Solaris OS. The output file is prefixed with "rmid-err" and has the suffix of ".tmp". The file name also contains other characters (typically numbers) in between to keep the file name unique.

If rmid starts up successfully from inetd, the output file should contain text similar to the following (with no warning or error messages):

Tue Sep 30 13:07:38 EDT 2003
rmid startup with inherited channel: sun.nio.ch.ServerSocketChannelImpl[/192.0.2.120:1098]

If the file does not exist, the above text is not in the file, or additional error output is in the file, then recheck the configuration. Upon changing the inetd configuration, remember to send inetd a hangup signal so that it rereads its altered configuration, and remember to terminate any rmid process started from the previous attempt before continuing.


Oracle and/or its affiliates Copyright © 1993, 2017, Oracle and/or its affiliates. All rights reserved.
Contact Us