Sponsored Content
Special Forums UNIX and Linux Applications Infrastructure Monitoring Event processing & machine learning in monitoring system Post 302821333 by DGPickett on Friday 14th of June 2013 11:44:01 AM
Old 06-14-2013
There is some of this sort of event predition in network protocols, to detect defective or slow paths to avoid, but servers are just supposed to run, not fail, predictable or not. The two flavors of handling this are parallel redundant concurrent load division where a dead server is detected and not sent any more load until it can respond to periodic tests. Recovery from services sent to a dying server is mostly left to client retry, but some systems of transactional middleware do requeue services that do not run to final commit, so they are run on alternative servers. Of course, query services are easier to handle than churn, where you need to rollback all when there is failure, before you requeue. Some systems do not use transactions, but structure churn so it can be applied any number of times and not have duplicate side effects (history filtering or believe the last of that seq. #).
 

We Also Found This Discussion For You

1. UNIX for Dummies Questions & Answers

learning UNIX on a Windows 2000 machine?

What is the best way to learn UNIX, shell, and Perl on a Windows 2000 machine? My place of employment uses Solaris and Perl and I would like to learn some UNIX skills on my home PC. I read about "dual boots", "Microsoft Windows Services for UNIX", and "cygwin". What other free options are... (9 Replies)
Discussion started by: wolfv
9 Replies
inetd.conf(4)							   File Formats 						     inetd.conf(4)

NAME
inetd.conf - Internet servers database SYNOPSIS
/etc/inet/inetd.conf /etc/inetd.conf DESCRIPTION
In the current release of the Solaris operating system, the inetd.conf file is no longer directly used to configure inetd. The Solaris ser- vices which were formerly configured using this file are now configured in the Service Management Facility (see smf(5)) using inetadm(1M). Any records remaining in this file after installation or upgrade, or later created by installing additional software, must be converted to smf(5) services and imported into the SMF repository using inetconv(1M), otherwise the service will not be available. For Solaris operating system releases prior to the current release (such as Solaris 9), the inetd.conf file contains the list of servers that inetd(1M) invokes when it receives an Internet request over a socket. Each server entry is composed of a single line of the form: service-name endpoint-type protocol wait-status uid server-program server-arguments Fields are separated by either SPACE or TAB characters. A `#' (number sign) indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search this file. service-name The name of a valid service listed in the services file. For RPC services, the value of the service-name field consists of the RPC service name or program number, followed by a '/' (slash) and either a version number or a range of version numbers, for example, rstatd/2-4. endpoint-type Can be one of: stream for a stream socket dgram for a datagram socket raw for a raw socket seqpacket for a sequenced packet socket tli for all TLI endpoints protocol A recognized protocol listed in the file /etc/inet/protocols. For servers capable of supporting TCP and UDP over IPv6, the following protocol types are also recognized: o tcp6 o udp6 tcp6 and udp6 are not official protocols; accordingly, they are not listed in the /etc/inet/protocols file. Here the inetd program uses an AF_INET6 type socket endpoint. These servers can also handle incoming IPv4 client requests in addition to IPv6 client requests. For RPC services, the field consists of the string rpc followed by a '/' (slash) and either a '*' (asterisk), one or more nettypes, one or more netids, or a combination of nettypes and netids. Whatever the value, it is first treated as a nettype. If it is not a valid nettype, then it is treated as a netid. For example, rpc/* for an RPC service using all the transports supported by the system (the list can be found in the /etc/netconfig file), equivalent to saying rpc/visible rpc/ticots for an RPC service using the Connection-Oriented Transport Service. wait-status This field has values wait or nowait. This entry specifies whether the server that is invoked by inetd will take over the listening socket associated with the service, and whether once launched, inetd will wait for that server to exit, if ever, before it resumes listening for new service requests. The wait-status for datagram servers must be set to wait, as they are always invoked with the orginal datagram socket that will participate in delivering the service bound to the specified service. They do not have separate "listening" and "accepting" sockets. Accordingly, do not configure UDP services as nowait. This causes a race condition by which the inetd program selects on the socket and the server program reads from the socket. Many server programs will be forked, and performance will be severely compromised. Con- nection-oriented services such as TCP stream services can be designed to be either wait or nowait status. uid The user ID under which the server should run. This allows servers to run with access privileges other than those for root. server-program Either the pathname of a server program to be invoked by inetd to perform the requested service, or the value internal if inetd itself provides the service. server-arguments If a server must be invoked with command line arguments, the entire command line (including argument 0) must appear in this field (which consists of all remaining words in the entry). If the server expects inetd to pass it the address of its peer, for compatibility with 4.2BSD executable daemons, then the first argument to the command should be specified as %A. No more than 20 arguments are allowed in this field. The %A argument is implemented only for services whose wait-status value is nowait. FILES
/etc/netconfig network configuration file /etc/inet/protocols Internet protocols /etc/inet/services Internet network services SEE ALSO
rlogin(1), rsh(1), in.tftpd(1M), inetadm(1M), inetconv(1M), inetd(1M), services(4), smf(5) NOTES
/etc/inet/inetd.conf is the official SVR4 name of the inetd.conf file. The symbolic link /etc/inetd.conf exists for BSD compatibility. This man page describes inetd.conf as it was supported in Solaris operating system releases prior to the current release. The services that were configured by means of inetd.conf are now configured in the Service Management Facility (see smf(5)) using inetadm(1M). SunOS 5.11 17 Dec 2004 inetd.conf(4)
All times are GMT -4. The time now is 01:35 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy