File: Netplex_admin.html

package info (click to toggle)
ocamlnet 4.1.9-7
links: PTS, VCS
area: main
in suites: forky, sid
size: 54,024 kB
sloc: ml: 151,939; ansic: 11,071; sh: 2,003; makefile: 1,310
file content (946 lines) | stat: -rw-r--r-- 50,009 bytes
parent folder | download | duplicates (4)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<link rel="stylesheet" href="style.css" type="text/css">
<meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="Start" href="index.html">
<link rel="previous" href="Netplex_advanced.html">
<link rel="next" href="Netshm.html">
<link rel="Up" href="index.html">
<link title="Index of types" rel=Appendix href="index_types.html">
<link title="Index of extensions" rel=Appendix href="index_extensions.html">
<link title="Index of exceptions" rel=Appendix href="index_exceptions.html">
<link title="Index of values" rel=Appendix href="index_values.html">
<link title="Index of class attributes" rel=Appendix href="index_attributes.html">
<link title="Index of class methods" rel=Appendix href="index_methods.html">
<link title="Index of classes" rel=Appendix href="index_classes.html">
<link title="Index of class types" rel=Appendix href="index_class_types.html">
<link title="Index of modules" rel=Appendix href="index_modules.html">
<link title="Index of module types" rel=Appendix href="index_module_types.html">
<link title="Uq_gtk" rel="Chapter" href="Uq_gtk.html">
<link title="Uq_tcl" rel="Chapter" href="Uq_tcl.html">
<link title="Equeue" rel="Chapter" href="Equeue.html">
<link title="Unixqueue" rel="Chapter" href="Unixqueue.html">
<link title="Unixqueue_pollset" rel="Chapter" href="Unixqueue_pollset.html">
<link title="Unixqueue_select" rel="Chapter" href="Unixqueue_select.html">
<link title="Uq_resolver" rel="Chapter" href="Uq_resolver.html">
<link title="Uq_engines" rel="Chapter" href="Uq_engines.html">
<link title="Uq_multiplex" rel="Chapter" href="Uq_multiplex.html">
<link title="Uq_transfer" rel="Chapter" href="Uq_transfer.html">
<link title="Uq_socks5" rel="Chapter" href="Uq_socks5.html">
<link title="Uq_io" rel="Chapter" href="Uq_io.html">
<link title="Uq_lwt" rel="Chapter" href="Uq_lwt.html">
<link title="Uq_libevent" rel="Chapter" href="Uq_libevent.html">
<link title="Uq_mt" rel="Chapter" href="Uq_mt.html">
<link title="Uq_client" rel="Chapter" href="Uq_client.html">
<link title="Uq_server" rel="Chapter" href="Uq_server.html">
<link title="Uq_datagram" rel="Chapter" href="Uq_datagram.html">
<link title="Uq_engines_compat" rel="Chapter" href="Uq_engines_compat.html">
<link title="Equeue_intro" rel="Chapter" href="Equeue_intro.html">
<link title="Equeue_howto" rel="Chapter" href="Equeue_howto.html">
<link title="Netcamlbox" rel="Chapter" href="Netcamlbox.html">
<link title="Netcgi_apache" rel="Chapter" href="Netcgi_apache.html">
<link title="Netcgi_modtpl" rel="Chapter" href="Netcgi_modtpl.html">
<link title="Netcgi_plex" rel="Chapter" href="Netcgi_plex.html">
<link title="Netcgi_common" rel="Chapter" href="Netcgi_common.html">
<link title="Netcgi" rel="Chapter" href="Netcgi.html">
<link title="Netcgi_ajp" rel="Chapter" href="Netcgi_ajp.html">
<link title="Netcgi_scgi" rel="Chapter" href="Netcgi_scgi.html">
<link title="Netcgi_cgi" rel="Chapter" href="Netcgi_cgi.html">
<link title="Netcgi_fcgi" rel="Chapter" href="Netcgi_fcgi.html">
<link title="Netcgi_dbi" rel="Chapter" href="Netcgi_dbi.html">
<link title="Netcgi1_compat" rel="Chapter" href="Netcgi1_compat.html">
<link title="Netcgi_test" rel="Chapter" href="Netcgi_test.html">
<link title="Netcgi_porting" rel="Chapter" href="Netcgi_porting.html">
<link title="Nethttp_client_conncache" rel="Chapter" href="Nethttp_client_conncache.html">
<link title="Nethttp_client" rel="Chapter" href="Nethttp_client.html">
<link title="Nettelnet_client" rel="Chapter" href="Nettelnet_client.html">
<link title="Netftp_data_endpoint" rel="Chapter" href="Netftp_data_endpoint.html">
<link title="Netftp_client" rel="Chapter" href="Netftp_client.html">
<link title="Nethttp_fs" rel="Chapter" href="Nethttp_fs.html">
<link title="Netftp_fs" rel="Chapter" href="Netftp_fs.html">
<link title="Netsmtp" rel="Chapter" href="Netsmtp.html">
<link title="Netpop" rel="Chapter" href="Netpop.html">
<link title="Netldap" rel="Chapter" href="Netldap.html">
<link title="Netclient_tut" rel="Chapter" href="Netclient_tut.html">
<link title="Netgss_bindings" rel="Chapter" href="Netgss_bindings.html">
<link title="Netgss" rel="Chapter" href="Netgss.html">
<link title="Nethttpd_types" rel="Chapter" href="Nethttpd_types.html">
<link title="Nethttpd_kernel" rel="Chapter" href="Nethttpd_kernel.html">
<link title="Nethttpd_reactor" rel="Chapter" href="Nethttpd_reactor.html">
<link title="Nethttpd_engine" rel="Chapter" href="Nethttpd_engine.html">
<link title="Nethttpd_services" rel="Chapter" href="Nethttpd_services.html">
<link title="Nethttpd_plex" rel="Chapter" href="Nethttpd_plex.html">
<link title="Nethttpd_util" rel="Chapter" href="Nethttpd_util.html">
<link title="Nethttpd_intro" rel="Chapter" href="Nethttpd_intro.html">
<link title="Netmcore" rel="Chapter" href="Netmcore.html">
<link title="Netmcore_camlbox" rel="Chapter" href="Netmcore_camlbox.html">
<link title="Netmcore_mempool" rel="Chapter" href="Netmcore_mempool.html">
<link title="Netmcore_heap" rel="Chapter" href="Netmcore_heap.html">
<link title="Netmcore_ref" rel="Chapter" href="Netmcore_ref.html">
<link title="Netmcore_array" rel="Chapter" href="Netmcore_array.html">
<link title="Netmcore_sem" rel="Chapter" href="Netmcore_sem.html">
<link title="Netmcore_mutex" rel="Chapter" href="Netmcore_mutex.html">
<link title="Netmcore_condition" rel="Chapter" href="Netmcore_condition.html">
<link title="Netmcore_queue" rel="Chapter" href="Netmcore_queue.html">
<link title="Netmcore_buffer" rel="Chapter" href="Netmcore_buffer.html">
<link title="Netmcore_matrix" rel="Chapter" href="Netmcore_matrix.html">
<link title="Netmcore_hashtbl" rel="Chapter" href="Netmcore_hashtbl.html">
<link title="Netmcore_process" rel="Chapter" href="Netmcore_process.html">
<link title="Netmcore_tut" rel="Chapter" href="Netmcore_tut.html">
<link title="Netmcore_basics" rel="Chapter" href="Netmcore_basics.html">
<link title="Netplex_types" rel="Chapter" href="Netplex_types.html">
<link title="Netplex_mp" rel="Chapter" href="Netplex_mp.html">
<link title="Netplex_mt" rel="Chapter" href="Netplex_mt.html">
<link title="Netplex_log" rel="Chapter" href="Netplex_log.html">
<link title="Netplex_controller" rel="Chapter" href="Netplex_controller.html">
<link title="Netplex_container" rel="Chapter" href="Netplex_container.html">
<link title="Netplex_sockserv" rel="Chapter" href="Netplex_sockserv.html">
<link title="Netplex_workload" rel="Chapter" href="Netplex_workload.html">
<link title="Netplex_main" rel="Chapter" href="Netplex_main.html">
<link title="Netplex_config" rel="Chapter" href="Netplex_config.html">
<link title="Netplex_kit" rel="Chapter" href="Netplex_kit.html">
<link title="Rpc_netplex" rel="Chapter" href="Rpc_netplex.html">
<link title="Netplex_cenv" rel="Chapter" href="Netplex_cenv.html">
<link title="Netplex_semaphore" rel="Chapter" href="Netplex_semaphore.html">
<link title="Netplex_sharedvar" rel="Chapter" href="Netplex_sharedvar.html">
<link title="Netplex_mutex" rel="Chapter" href="Netplex_mutex.html">
<link title="Netplex_encap" rel="Chapter" href="Netplex_encap.html">
<link title="Netplex_mbox" rel="Chapter" href="Netplex_mbox.html">
<link title="Netplex_internal" rel="Chapter" href="Netplex_internal.html">
<link title="Netplex_intro" rel="Chapter" href="Netplex_intro.html">
<link title="Netplex_advanced" rel="Chapter" href="Netplex_advanced.html">
<link title="Netplex_admin" rel="Chapter" href="Netplex_admin.html">
<link title="Netshm" rel="Chapter" href="Netshm.html">
<link title="Netshm_data" rel="Chapter" href="Netshm_data.html">
<link title="Netshm_hashtbl" rel="Chapter" href="Netshm_hashtbl.html">
<link title="Netshm_array" rel="Chapter" href="Netshm_array.html">
<link title="Netshm_intro" rel="Chapter" href="Netshm_intro.html">
<link title="Netstring_pcre" rel="Chapter" href="Netstring_pcre.html">
<link title="Netconversion" rel="Chapter" href="Netconversion.html">
<link title="Netchannels" rel="Chapter" href="Netchannels.html">
<link title="Netstream" rel="Chapter" href="Netstream.html">
<link title="Netmime_string" rel="Chapter" href="Netmime_string.html">
<link title="Netmime" rel="Chapter" href="Netmime.html">
<link title="Netsendmail" rel="Chapter" href="Netsendmail.html">
<link title="Neturl" rel="Chapter" href="Neturl.html">
<link title="Netaddress" rel="Chapter" href="Netaddress.html">
<link title="Netbuffer" rel="Chapter" href="Netbuffer.html">
<link title="Netmime_header" rel="Chapter" href="Netmime_header.html">
<link title="Netmime_channels" rel="Chapter" href="Netmime_channels.html">
<link title="Neturl_ldap" rel="Chapter" href="Neturl_ldap.html">
<link title="Netdate" rel="Chapter" href="Netdate.html">
<link title="Netencoding" rel="Chapter" href="Netencoding.html">
<link title="Netulex" rel="Chapter" href="Netulex.html">
<link title="Netaccel" rel="Chapter" href="Netaccel.html">
<link title="Netaccel_link" rel="Chapter" href="Netaccel_link.html">
<link title="Nethtml" rel="Chapter" href="Nethtml.html">
<link title="Netstring_str" rel="Chapter" href="Netstring_str.html">
<link title="Netmappings" rel="Chapter" href="Netmappings.html">
<link title="Netaux" rel="Chapter" href="Netaux.html">
<link title="Nethttp" rel="Chapter" href="Nethttp.html">
<link title="Netpagebuffer" rel="Chapter" href="Netpagebuffer.html">
<link title="Netfs" rel="Chapter" href="Netfs.html">
<link title="Netglob" rel="Chapter" href="Netglob.html">
<link title="Netauth" rel="Chapter" href="Netauth.html">
<link title="Netsockaddr" rel="Chapter" href="Netsockaddr.html">
<link title="Netnumber" rel="Chapter" href="Netnumber.html">
<link title="Netxdr_mstring" rel="Chapter" href="Netxdr_mstring.html">
<link title="Netxdr" rel="Chapter" href="Netxdr.html">
<link title="Netcompression" rel="Chapter" href="Netcompression.html">
<link title="Netunichar" rel="Chapter" href="Netunichar.html">
<link title="Netasn1" rel="Chapter" href="Netasn1.html">
<link title="Netasn1_encode" rel="Chapter" href="Netasn1_encode.html">
<link title="Netoid" rel="Chapter" href="Netoid.html">
<link title="Netstring_tstring" rel="Chapter" href="Netstring_tstring.html">
<link title="Netdn" rel="Chapter" href="Netdn.html">
<link title="Netx509" rel="Chapter" href="Netx509.html">
<link title="Netascii_armor" rel="Chapter" href="Netascii_armor.html">
<link title="Nettls_support" rel="Chapter" href="Nettls_support.html">
<link title="Netmech_scram" rel="Chapter" href="Netmech_scram.html">
<link title="Netmech_scram_gssapi" rel="Chapter" href="Netmech_scram_gssapi.html">
<link title="Netmech_scram_sasl" rel="Chapter" href="Netmech_scram_sasl.html">
<link title="Netmech_scram_http" rel="Chapter" href="Netmech_scram_http.html">
<link title="Netgssapi_support" rel="Chapter" href="Netgssapi_support.html">
<link title="Netgssapi_auth" rel="Chapter" href="Netgssapi_auth.html">
<link title="Netchannels_crypto" rel="Chapter" href="Netchannels_crypto.html">
<link title="Netx509_pubkey" rel="Chapter" href="Netx509_pubkey.html">
<link title="Netx509_pubkey_crypto" rel="Chapter" href="Netx509_pubkey_crypto.html">
<link title="Netsaslprep" rel="Chapter" href="Netsaslprep.html">
<link title="Netmech_plain_sasl" rel="Chapter" href="Netmech_plain_sasl.html">
<link title="Netmech_crammd5_sasl" rel="Chapter" href="Netmech_crammd5_sasl.html">
<link title="Netmech_digest_sasl" rel="Chapter" href="Netmech_digest_sasl.html">
<link title="Netmech_digest_http" rel="Chapter" href="Netmech_digest_http.html">
<link title="Netmech_krb5_sasl" rel="Chapter" href="Netmech_krb5_sasl.html">
<link title="Netmech_gs2_sasl" rel="Chapter" href="Netmech_gs2_sasl.html">
<link title="Netmech_spnego_http" rel="Chapter" href="Netmech_spnego_http.html">
<link title="Netchannels_tut" rel="Chapter" href="Netchannels_tut.html">
<link title="Netmime_tut" rel="Chapter" href="Netmime_tut.html">
<link title="Netsendmail_tut" rel="Chapter" href="Netsendmail_tut.html">
<link title="Netulex_tut" rel="Chapter" href="Netulex_tut.html">
<link title="Neturl_tut" rel="Chapter" href="Neturl_tut.html">
<link title="Netsys" rel="Chapter" href="Netsys.html">
<link title="Netsys_posix" rel="Chapter" href="Netsys_posix.html">
<link title="Netsys_pollset" rel="Chapter" href="Netsys_pollset.html">
<link title="Netlog" rel="Chapter" href="Netlog.html">
<link title="Netexn" rel="Chapter" href="Netexn.html">
<link title="Netsys_win32" rel="Chapter" href="Netsys_win32.html">
<link title="Netsys_pollset_posix" rel="Chapter" href="Netsys_pollset_posix.html">
<link title="Netsys_pollset_win32" rel="Chapter" href="Netsys_pollset_win32.html">
<link title="Netsys_pollset_generic" rel="Chapter" href="Netsys_pollset_generic.html">
<link title="Netsys_signal" rel="Chapter" href="Netsys_signal.html">
<link title="Netsys_oothr" rel="Chapter" href="Netsys_oothr.html">
<link title="Netsys_xdr" rel="Chapter" href="Netsys_xdr.html">
<link title="Netsys_rng" rel="Chapter" href="Netsys_rng.html">
<link title="Netsys_crypto_types" rel="Chapter" href="Netsys_crypto_types.html">
<link title="Netsys_types" rel="Chapter" href="Netsys_types.html">
<link title="Netsys_mem" rel="Chapter" href="Netsys_mem.html">
<link title="Netsys_tmp" rel="Chapter" href="Netsys_tmp.html">
<link title="Netsys_sem" rel="Chapter" href="Netsys_sem.html">
<link title="Netsys_pmanage" rel="Chapter" href="Netsys_pmanage.html">
<link title="Netsys_crypto" rel="Chapter" href="Netsys_crypto.html">
<link title="Netsys_tls" rel="Chapter" href="Netsys_tls.html">
<link title="Netsys_ciphers" rel="Chapter" href="Netsys_ciphers.html">
<link title="Netsys_digests" rel="Chapter" href="Netsys_digests.html">
<link title="Netsys_crypto_modes" rel="Chapter" href="Netsys_crypto_modes.html">
<link title="Netsys_gssapi" rel="Chapter" href="Netsys_gssapi.html">
<link title="Netsys_sasl_types" rel="Chapter" href="Netsys_sasl_types.html">
<link title="Netsys_sasl" rel="Chapter" href="Netsys_sasl.html">
<link title="Netsys_polypipe" rel="Chapter" href="Netsys_polypipe.html">
<link title="Netsys_polysocket" rel="Chapter" href="Netsys_polysocket.html">
<link title="Netsys_global" rel="Chapter" href="Netsys_global.html">
<link title="Nettls_gnutls_bindings" rel="Chapter" href="Nettls_gnutls_bindings.html">
<link title="Nettls_nettle_bindings" rel="Chapter" href="Nettls_nettle_bindings.html">
<link title="Nettls_gnutls" rel="Chapter" href="Nettls_gnutls.html">
<link title="Netunidata" rel="Chapter" href="Netunidata.html">
<link title="Netgzip" rel="Chapter" href="Netgzip.html">
<link title="Rpc_auth_local" rel="Chapter" href="Rpc_auth_local.html">
<link title="Rpc_xti_client" rel="Chapter" href="Rpc_xti_client.html">
<link title="Rpc" rel="Chapter" href="Rpc.html">
<link title="Rpc_program" rel="Chapter" href="Rpc_program.html">
<link title="Rpc_util" rel="Chapter" href="Rpc_util.html">
<link title="Rpc_portmapper_aux" rel="Chapter" href="Rpc_portmapper_aux.html">
<link title="Rpc_packer" rel="Chapter" href="Rpc_packer.html">
<link title="Rpc_transport" rel="Chapter" href="Rpc_transport.html">
<link title="Rpc_client" rel="Chapter" href="Rpc_client.html">
<link title="Rpc_simple_client" rel="Chapter" href="Rpc_simple_client.html">
<link title="Rpc_portmapper_clnt" rel="Chapter" href="Rpc_portmapper_clnt.html">
<link title="Rpc_portmapper" rel="Chapter" href="Rpc_portmapper.html">
<link title="Rpc_server" rel="Chapter" href="Rpc_server.html">
<link title="Rpc_auth_sys" rel="Chapter" href="Rpc_auth_sys.html">
<link title="Rpc_auth_gssapi" rel="Chapter" href="Rpc_auth_gssapi.html">
<link title="Rpc_proxy" rel="Chapter" href="Rpc_proxy.html">
<link title="Rpc_intro" rel="Chapter" href="Rpc_intro.html">
<link title="Rpc_mapping_ref" rel="Chapter" href="Rpc_mapping_ref.html">
<link title="Rpc_intro_gss" rel="Chapter" href="Rpc_intro_gss.html">
<link title="Shell_sys" rel="Chapter" href="Shell_sys.html">
<link title="Shell" rel="Chapter" href="Shell.html">
<link title="Shell_uq" rel="Chapter" href="Shell_uq.html">
<link title="Shell_fs" rel="Chapter" href="Shell_fs.html">
<link title="Shell_intro" rel="Chapter" href="Shell_intro.html">
<link title="Intro" rel="Chapter" href="Intro.html">
<link title="Platform" rel="Chapter" href="Platform.html">
<link title="Foreword" rel="Chapter" href="Foreword.html">
<link title="Ipv6" rel="Chapter" href="Ipv6.html">
<link title="Regexp" rel="Chapter" href="Regexp.html">
<link title="Tls" rel="Chapter" href="Tls.html">
<link title="Crypto" rel="Chapter" href="Crypto.html">
<link title="Authentication" rel="Chapter" href="Authentication.html">
<link title="Credentials" rel="Chapter" href="Credentials.html">
<link title="Gssapi" rel="Chapter" href="Gssapi.html">
<link title="Ocamlnet4" rel="Chapter" href="Ocamlnet4.html">
<link title="Get" rel="Chapter" href="Get.html"><title>Ocamlnet 4 Reference Manual : Netplex_admin</title>
</head>
<body>
<div class="navbar"><a class="pre" href="Netplex_advanced.html" title="Netplex_advanced">Previous</a>
&nbsp;<a class="up" href="index.html" title="Index">Up</a>
&nbsp;<a class="post" href="Netshm.html" title="Netshm">Next</a>
</div>
<h1>Netplex_admin</h1>
<div class="info-desc">
<h2 id="main">Netplex Administration Guide</h2>
<p>Applications created with the Netplex framework all share the
following configuration settings and allow some basic
administration commands. This is only a common minimum - the
applications typically define more than this.</p>

<h2 id="config">Configuration</h2>
<p>The Netplex config file has the following layout:</p>

<pre class="codepre"><code class="code">netplex {
  controller { &lt;settings&gt; };    (* only one controller section *)
  service { &lt;settings&gt; };       (* as many service sections as running services *)
  ...
  service { &lt;settings&gt; };
  (* The application can define further types of sections *)
}
</code></pre>
<h3 id="controller">Configuration: The <code class="code">controller</code> section</h3>
<p>This section configures the controller component. The task of the
controller is to start the containers for the workload, and logging.</p>

<pre class="codepre"><code class="code">netplex {
  controller {
    socket_directory = "&lt;path&gt;";
    max_level = "&lt;debuglevel&gt;";
    logging { &lt;settings&gt; };    (* several logging destinations possible *)
    ...
    logging { &lt;settings&gt; };
  };
  ...
}
</code></pre>
<p>Settings:</p>
<ul>
<li><code class="code">socket_directory</code>: The Netplex framework needs a directory where to
  create Unix domain sockets. These sockets are needed for communication
  between the started containers. If omitted, the directory defaults to
  <code class="code">/tmp/netplex-&lt;id&gt;</code> (where the id part is derived from the file location of
  the configuration). It is not allowed that several running Netplex instances
  share these directories, and hence it is strongly recommended to change
  this default. If the path is not absolute, it is made absolute by
  prepending the path of the working directory at the time Netplex
  is started (usually the program start). Note that the paths of
  Unix domain sockets are limited to 107 bytes for historic reasons,
  so the <code class="code">socket_directory</code> should not be put too deeply into the
  file hierarchy.</li>
<li><code class="code">max_level</code>: This can be set to globally limit the log level. Defaults
  to "debug", i.e. no maximum.</li>
</ul>
<p>Log levels are (same as for syslog):</p>
<ul>
<li>emerg</li>
<li>alert</li>
<li>crit</li>
<li>err</li>
<li>warning</li>
<li>notice</li>
<li>info</li>
<li>debug</li>
</ul>
<p>Every <code class="code">logging</code> section defines a logging destination. Log messages
are written to all destinations that do not filter the messages out.
There are several types of <code class="code">logging</code> sections:</p>

<h4 id="logerr">Logging to stderr</h4>
<p>This type writes log messages to stderr:</p>

<pre class="codepre"><code class="code">netplex {
  controller {
    logging {
      type = "stderr";                        (* mandatory *)
      format = "&lt;format string&gt;";             (* optional *)
      component = "&lt;name_of_component&gt;";      (* optional *)
      subchannel = "&lt;name_of_subchannel&gt;";    (* optional *)
      max_level = "&lt;max_level&gt;";              (* optional *)
    };
    ...
  };
  ...
}
</code></pre>
<p>The settings <code class="code">format</code>, <code class="code">component</code>, <code class="code">subchannel</code>, and <code class="code">max_level</code> may also
occur in the other types of logging definitions, and are explained below.</p>

<h4 id="logfile">Logging to a file</h4>
<p>This writes the log messages to a single file.</p>

<pre class="codepre"><code class="code">netplex {
  controller {
    logging {
      type = "file";                          (* mandatory *)
      file = "&lt;path&gt;";                        (* mandatory *)
      format = "&lt;format string&gt;";             (* optional *)
      component = "&lt;name_of_component&gt;";      (* optional *)
      subchannel = "&lt;name_of_subchannel&gt;";    (* optional *)
      max_level = "&lt;max_level&gt;";              (* optional *)
    };
    ...
  };
  ...
}
</code></pre>
<p>Settings:</p>
<ul>
<li><code class="code">file</code>: The file to which the messages are appended. If not existing,
  the file is created. The file path must be absolute.</li>
</ul>
<p>The settings <code class="code">format</code>, <code class="code">component</code>, <code class="code">subchannel</code>, and <code class="code">max_level</code> may also
occur in the other types of logging definitions, and are explained below.</p>

<h4 id="logmfile">Logging to multiple files</h4>
<p>This logging definition directs to create several files in a common
directory.</p>

<pre class="codepre"><code class="code">netplex {
  controller {
    logging {
      type = "multi_file";                    (* mandatory *)
      directory = "&lt;path&gt;";                   (* mandatory *)
      format = "&lt;format string&gt;";             (* optional *)
      file { &lt;settings&gt; };
      ...
      file { &lt;settings&gt; };
    };
    ...
  };
  ...
}
</code></pre>
<p>The settings in the <code class="code">file</code> section:</p>

<pre class="codepre"><code class="code">  file {
    file = "&lt;name&gt;";                        (* mandatory *)
    format = "&lt;format string&gt;";             (* optional *)
    component = "&lt;name_of_component&gt;";      (* optional *)
    subchannel = "&lt;name_of_subchannel&gt;";    (* optional *)
    max_level = "&lt;max_level&gt;";              (* optional *)
  };
</code></pre>
<p>Settings:</p>
<ul>
<li><code class="code">directory</code>: The absolute path of the directory where to create
  the log files managed by the <code class="code">file</code> subsections</li>
<li><code class="code">file</code>: The name of the file in this directory</li>
</ul>
<p>The settings <code class="code">format</code>, <code class="code">component</code>, <code class="code">subchannel</code>, and <code class="code">max_level</code> may also
occur in the other types of logging definitions, and are explained below.
Note that a <code class="code">format</code> setting in the <code class="code">file</code> section overrides the
definition in <code class="code">logging</code> for the respective file.</p>

<h4 id="logsys">Logging to syslog</h4>
<p>The log messages are sent to the syslog device of the system
(Unix only).</p>

<pre class="codepre"><code class="code">netplex {
  controller {
    logging {
      type = "syslog";                        (* mandatory *)
      identifier = "&lt;identifier&gt;";            (* optional *)
      facility = "&lt;facility&gt;";                (* optional *)
      format = "&lt;format string&gt;";             (* optional *)
      component = "&lt;name_of_component&gt;";      (* optional *)
      subchannel = "&lt;name_of_subchannel&gt;";    (* optional *)
      max_level = "&lt;max_level&gt;";              (* optional *)
    };
    ...
  };
  ...
}
</code></pre>
<p>Settings:</p>
<ul>
<li><code class="code">identifier</code>: A string prefixing each message. Default: empty.</li>
<li><code class="code">facility</code>: The syslog facility name. Defaults to "default".</li>
</ul>
<p>Facility names:</p>
<ul>
<li>authpriv</li>
<li>cron</li>
<li>daemon</li>
<li>ftp</li>
<li>kern</li>
<li>local0 to local7</li>
<li>lpr</li>
<li>mail</li>
<li>news</li>
<li>syslog</li>
<li>user</li>
<li>uucp</li>
<li>default</li>
</ul>
<h4 id="logcommon">Common settings in <code class="code">logging</code></h4>
<p><b><code class="code">format</code>:</b> This parameter defines how the log messages look like.
This is a string containing variables in dollar notation (<code class="code">$name</code> or 
<code class="code">${name}</code>). The following variable specifications are defined:</p>

<ul>
<li><code class="code">timestamp</code>: the time in standard format</li>
<li><code class="code">timestamp:&lt;format&gt;</code> the time in custom format where <code class="code">&lt;format&gt;</code> is a
   <a href="Netdate.html"><code class="code">Netdate</code></a> format string</li>
<li><code class="code">timestamp:unix</code>: the time in seconds since the epoch</li>
<li><code class="code">component</code>: the name of the component emitting the log message</li>
<li><code class="code">subchannel</code>: the name of the subchannel</li>
<li><code class="code">level</code>: the log level</li>
<li><code class="code">message</code>: the log message</li>
</ul>
<p>The standard format string is</p>
<pre class="codepre"><code class="code"> [${timestamp}] [${component}] [${level}] ${message} </code></pre>
<p><b><code class="code">component</code>:</b> This parameter filters messages by the component 
emitting the messages. The component name is here the Netplex
service name, i.e. the <code class="code">name</code> parameter in the <code class="code">service</code> section
(see below). The parameter may be set to the component name, or
to a pattern matching component names. The wildcard <code class="code">*</code> can be used
in the pattern.</p>

<p>Default: <code class="code">*</code></p>

<p><b><code class="code">subchannel</code>:</b> Netplex allows it to have several log channels per
component. There is normally only the main log channel, but components
can define additional channels. For example, a web server may have
a separate log channel for access logging. This parameter filters
messages by the subchannel identifier. Again it is possible to use
the wildcard <code class="code">*</code>.</p>

<p>The main log channel has the empty string as subchannel identifier,
hence <code class="code">subchannel=""</code> restricts the messages to the main channel.</p>

<p>Default: <code class="code">*</code></p>

<p><b><code class="code">max_level</code>:</b> Restricts the log level of the printed messages.
See above for possible levels.</p>

<h4 id="3_Examplesforloggingdefinitions">Examples for logging definitions</h4>
<p>1. Write everything to stderr:</p>

<pre class="codepre"><code class="code">  logging { type="stderr" }
</code></pre>
<p>2. Write a separate file for each log level:</p>

<pre class="codepre"><code class="code">  logging {
    type = "multi_file";
    directory = "/var/log/myapp";
    file {
      max_level = "debug";
      file = "all_debug.log";
    };
    file {
      max_level = "info";
      file = "all_info.log";
    };
    ... (* and so on ... *)
    file {
      max_level = "emerg";
      file = "all_emerg.log";
    };
  }
</code></pre>
<p>3. Write errors to syslog, but write access logs to a file:</p>

<pre class="codepre"><code class="code">  logging {
    type = "syslog";
    max_level = "err";
    subchannel = "";    (* i.e. only the main log channel goes here *)
  };
  logging {
    type = "file";
    file = "/var/log/myapp/access.log";
    subchannel = "access";
  }
</code></pre>
<h3 id="service">Configuration: The <code class="code">service</code> section</h3>
<p>Each service section instructs Netplex to start containers for the
service. If a service type is only defined by the application, but
does not appear in the config file, no containers will be started!</p>

<p>A service section looks like:</p>

<pre class="codepre"><code class="code">netplex {
  service {
    name = "&lt;name&gt;";                 (* mandatory *)
    user = "&lt;user&gt;";                 (* optional *)
    group = "&lt;group&gt;";               (* optional *)
    startup_timeout = &lt;float&gt;;       (* optional *)
    conn_limit = &lt;int&gt;;              (* optional *)
    gc_when_idle = &lt;bool&gt;;           (* optional *)
    protocol { &lt;settings&gt; };         (* at least one *)
    ...
    protocol { &lt;settings&gt; };         (* at least one *)
    processor { &lt;settings&gt; };        (* mandatory *)
    workload_manager { &lt;settings&gt; }; (* mandatory *)
  };
  ...
}
</code></pre>
<p>The <code class="code">name</code> of the service is a freely chosen identifier. It is used
to reference the service, e.g. in log messages.</p>

<p>Each <code class="code">protocol</code> section defines a set of sockets with common
properties. The idea here is that a service may define several
protocols for accessing it, e.g. an HTTP-based protocol and an
RPC-based protocol. For each protocol there can then be several
sockets.</p>

<p>The <code class="code">processor</code> section is the connection to the application
which must have defined the type of processor that is referenced
here. The task of the processor is to accept incoming connections
and to process them.</p>

<p>The <code class="code">workload_manager</code> section defines how many containers (i.e.
subprocesses or threads) are created for serving incoming connections.</p>

<p>Settings:</p>
<ul>
<li><code class="code">user</code>: If the program is started as user <code class="code">root</code>, it is possible to
  change the user for subprocesses. This parameter is the user name
  for all subprocesses created for this service. This is only possible
  when Netplex is running in the multi-processing mode, not in the
  multi-threading mode. Default: do not change the user.</li>
<li><code class="code">group</code>: Same for the group</li>
<li><code class="code">startup_timeout</code>: If a subprocess does not start up within this
  period of time, it is considered as dysfunctional, and killed again.
  This misbehavior usually occurs because the initialization function
  of the subprocess hangs.
  This setting has only an effect in multi-processing mode.
  Default: 60 seconds. A negative value turns this feature off.</li>
<li><code class="code">conn_limit</code>: If set, a container is automatically shut down if
  it has processed this number of connections. This is sometimes
  useful if there is a memory leak in the container, or memory is
  not reclaimed quickly enough. Of course, one can only fight memory
  problems in multi-processing mode this way. Default: no limit.</li>
<li><code class="code">gc_when_idle</code>: If <code class="code">true</code>, the Ocaml garbage collector is run
  if a container is idle for one second.</li>
</ul>
<h4 id="protocol">The <code class="code">protocol</code> subsection</h4>
<p>It looks like:</p>

<pre class="codepre"><code class="code">netplex {
  service {
    protocol {
      name = "&lt;protoname&gt;";      (* mandatory *)
      lstn_backlog = &lt;int&gt;;      (* optional *)
      lstn_reuseaddr = &lt;bool&gt;;   (* optional *)
      so_keepalive = &lt;bool&gt;;     (* optional *)
      tcp_nodelay = &lt;bool&gt;;      (* optional *)
      local_chmod = "...";       (* optional *)
      local_chown = "...";       (* optional *)
      address { &lt;settings&gt; };    (* at least one *)
      ...
      address { &lt;settings&gt; };    (* at least one *)
    };
    ...
  };
  ...
}
</code></pre>
<p>Settings:</p>
<ul>
<li><code class="code">name</code>: The name of the protocol. This is an arbitrary identifier.
  The name is passed to some hook functions.</li>
<li><code class="code">lstn_backlog</code>: The value of the backlog parameter of the <code class="code">listen</code>
  system call. When a TCP connection is being accepted, the kernel does
  this first on its own, and passes the accepted connection to the application
  at the next opportunity (i.e. the <code class="code">accept</code> system call). Because of this
  connections can queue up in the kernel, i.e. connections that are accepted
  but not yet passed to the application. This parameter is the maximum
  length of this queue. Note that there is usually also a kernel-defined
  maximum (e.g. 128 on Linux). If you get spurious <code class="code">EAGAIN</code> errors
  on the client side this might be an indication to increase this parameter.</li>
<li><code class="code">lstn_reuseaddr</code>: Whether to allow immediate reuse of socket addresses.
  Defaults to <code class="code">true</code>.</li>
<li><code class="code">so_keepalive</code>: Whether to enable the TCP keep-alive feature which is
  useful to detect unresponsive TCP connections (after a very long timeout
  only, though). Defaults to <code class="code">false</code>.</li>
<li><code class="code">tcp_nodelay</code>: Whether to disable the Nagle algorithm for TCP. Normally,
  TCP packets are minimally delayed before they are sent to the network
  in the hope that the application makes more data available that could be
  put into
  the same packet. Especially on local networks it is often not important
  how many packets are really sent out, and by enabling this option
  latencies can be, sometimes drastically, reduced. Defaults to <code class="code">false</code>.</li>
<li><code class="code">local_chmod</code>: For Unix Domain sockets, this sets the file permission
  bits. E.g. <code class="code">local_chmod = "0o700"</code></li>
<li><code class="code">local_chown</code>: For Unix Domain sockets, this sets the owner and group
  of the socket. E.g. <code class="code">local_chown = "owner:group"</code>. Both settings can also
  be given numerically.</li>
</ul>
<p>Specifying socket addresses:</p>
<ul>
<li><code class="code">address { type="internet"; bind="&lt;ip&gt;:&lt;port&gt;" }</code>: An IPv4 or IPv6
  socket. The IP address can also given as host name which is looked up
  at Netplex startup. Use <code class="code">0.0.0.0</code> as the IPv4 catch-all address. IPv6
  addresses must be put into brackets. Use <code class="code">[:0]</code> as the IPv6 catch-all
  address.</li>
<li><code class="code">address { type="local"; path="&lt;path&gt;" }</code>: 
  This is a OS-dependent default IPC mechanism for local
  connections. On Unix, <code class="code">local</code> means Unix Domain sockets. On Win32,
  <code class="code">local</code> means the <code class="code">w32_pipe_file</code> mechanism (see below). In <code class="code">path</code>, the name
  of the Unix Domain socket or the file with the pipe name must be
  specified.</li>
<li><code class="code">address { type="unixdomain"; path="&lt;path&gt;" }</code>: 
  Unix domain sockets. In <code class="code">path</code> give the path.</li>
<li><code class="code">address { type="socket_file"; path="&lt;path&gt;" }</code>: 
  An emulation of Unix Domain sockets: A server socket
  bound to <code class="code">127.0.0.1</code> and an anonymous port is used instead. The
  port number is written to a file. The file must be given as <code class="code">path</code>.</li>
<li><code class="code">address { type="w32_pipe"; path="&lt;path&gt;" }</code>: 
  Win32 named pipes. The name of the pipe is given
  as <code class="code">path</code>. This must be a name of the form "\\.\pipe\&lt;name&gt;".
  The pipe server is configured so that only clients on the same
  system can connect to it.</li>
<li><code class="code">address { type="w32_pipe_file"; path="&lt;path&gt;" }</code>:
  An emulation of Unix Domain sockets: A named
  pipe with an unpredictable random name is created instead. The
  name of this pipe is written to the file given by <code class="code">path</code>.</li>
<li><code class="code">address { type="container" }</code>: 
  This special address causes that a separate <code class="code">local</code>
  socket is created for each started container. The name of the
  socket file is automatically chosen. The names of the socket
  files can be queried with <a href="Netplex_cenv.html#VALlookup_container_sockets"><code class="code">Netplex_cenv.lookup_container_sockets</code></a>.
  This type of socket is useful to control the load sent to each
  container directly.</li>
</ul>
<h4 id="processor">The <code class="code">processor</code> subsection</h4>
<p>This section depends on the Netplex processor connected with it.
At minimum, this section has only a parameter <code class="code">type</code> that is the
name of a defined Netplex processor type:</p>

<pre class="codepre"><code class="code">netplex {
  service {
    processor {
      type = "&lt;type&gt;";
      ... (* rest depends on the type *)
    };
    ...
  };
  ...
}
</code></pre>
<p>There are a number of processor types coming with Ocamlnet:</p>

<ul>
<li><a href="Rpc_netplex.html"><code class="code">Rpc_netplex</code></a>: RPC servers</li>
<li><a href="Netcgi_plex.html"><code class="code">Netcgi_plex</code></a>: Web connectors (e.g. FastCGI)</li>
<li><a href="Nethttpd_plex.html"><code class="code">Nethttpd_plex</code></a>: Web servers</li>
</ul>
<p>See these modules for how to configure the processors defined by them.</p>

<h3 id="workload">Configuration: The <code class="code">workload_manager</code> section</h3>
<p>The workload manager determines how many containers (processes or
threads) are running for each service.</p>

<h4 id="constworkload">The constant workload manager</h4>
<p>The constant workload manager starts a fixed number of containers.
If containers are shut down or crash, new containers are automatically
launched to replace the missing ones.</p>

<p>The config section looks like:</p>

<pre class="codepre"><code class="code">netplex {
  service {
    workload_manager {
      type = "constant";
      threads = &lt;n&gt;;
    }
  }
}
</code></pre>
<p>Note that the parameter <code class="code">threads</code> is also interpreted in
multi-processing mode (as number of processes).</p>

<p>Since Ocamlnet-3.5, there are two optional settings:</p>

<ul>
<li><code class="code">max_jobs_per_thread</code>: This number can be set to the maximum number of
  connections a thread or process can be assigned simultaneously. By default
  there is no limit.</li>
<li><code class="code">greedy_accepts</code>: This is a boolean (values <code class="code">true</code> or <code class="code">false</code>). If
  this mode is turned on, processes accept new connections more aggressively.
  This may improve the performance for very high connect rates (e.g.
  for more than 1000 new connections per second). The downside is that
  the load is assigned to processes in a less balanced way.</li>
</ul>
<h4 id="dynworkload">The dynamic workload manager</h4>
<p>The dynamic workload manager starts as many containers as needed to
handle the current load. Initially, a certain minimum number is started.
If it turns out that too many containers become busy, more containers
are started until a maximum is reached. If too many containers become
idle containers are shut down.</p>

<pre class="codepre"><code class="code">netplex {
  service {
    workload_manager {
      type = "dynamic";
      max_jobs_per_thread = &lt;n&gt;;            (* optional, default: 1 *)
      recommended_jobs_per_thread = &lt;n&gt;;    (* optional *)
      min_free_jobs_capacity = &lt;n&gt;;         (* mandatory *)
      max_free_jobs_capacity = &lt;n&gt;;         (* mandatory *)
      max_threads = &lt;n&gt;;                    (* mandatory *)
    }
  }
}
</code></pre>
<p>A thread is here a container, even in multi-processing mode. A job
is a TCP connection processed by a container. It is possible that
a container can process several jobs at the same time (but only a
few service types support this, e.g. RPC servers), and the whole
calculation is based on the job capacity, i.e. the number of jobs
all containers can execute in parallel.</p>

<p>The workload manager adjusts the number of containers so that there
is always free capacity for <code class="code">min_free_jobs_capacity</code>, but the free
capacity does not exceed <code class="code">max_free_jobs_capacity</code>. Also, the number
of containers is capped by <code class="code">max_threads</code>.</p>

<p>As mentioned, in most cases a container can only run one job at a
time (this is meant with <code class="code">max_jobs_per_thread=1</code>). Then
<code class="code">min_free_jobs_capacity</code> is just the minimum number of idle
containers, and <code class="code">max_free_jobs_capacity</code> the maximum number.</p>

<p>If more than one job can be executed, set <code class="code">max_jobs_per_thread</code> to
a value bigger than one. The workload manager assigns the components
then up to this number of TCP connections to process. A component
is filled up with jobs until it is full before jobs are assigned
to the next container.</p>

<p>The latter behavior can be modified by <code class="code">recommended_jobs_per_thread</code>.
This must be a number less than or equal to <code class="code">max_jobs_per_thread</code>,
and it means that the containers normally only get the recommended
number of jobs until they are "full", and only for very high workloads
this scheme is left, and even more jobs are assigned to the containers
until the maximum is reached. A common configuration is to set
<code class="code">recommended_jobs_per_thread=1</code>, so that each container gets first
only up to one job, and only if the maximum number of containers are
running, additional jobs can be assigned.</p>

<p>There are also a few rarely used options for the dynamic workload
manager:</p>

<ul>
<li><code class="code">greedy_accepts</code>: This is a boolean (values <code class="code">true</code> or <code class="code">false</code>). If
  this mode is turned on, processes accept new connections more aggressively.
  This may improve the performance for very high connect rates (e.g.
  for more than 1000 new connections per second). The downside is that
  the load is assigned to processes in a less balanced way. Note that
  this mode only works for asynchronously implemented processors.
  (Since Ocamlnet-3.5.)</li>
</ul>
<h2 id="admin">The <code class="code">netplex-admin</code> command</h2>
<p>Ocamlnet installs a little utility command <code class="code">netplex-admin</code> that can
be used to administer a <b>running</b> Netplex program.</p>

<pre class="codepre"><code class="code">$ netplex-admin -help
Usage: netplex-admin [ options ] [ admin_cmd arg ... ]
  -sockdir &lt;dir&gt;  Set the socket directory of the Netplex to administer
  -conf &lt;file&gt;  Get the socket directory from this config file
  -list   List available Netplex services
  -containers   List available Netplex services with container details
  -enable &lt;name&gt;  Enable service &lt;name&gt;
  -disable &lt;name&gt;  Disable service &lt;name&gt;
  -restart &lt;name&gt;  Restart service &lt;name&gt;
  -restart-all   Restart all services
  -shutdown   Shutdown the whole Netplex
  -reopen-logfiles   Reopen logfiles (if possible)
  -unlink   Unlink persistent kernel objects
  -receiver &lt;pat&gt;  Restrict receivers of admin messages to services matching &lt;pat&gt;
</code></pre>
<p>The utility talks to the running program, and needs the socket directory
for this. Either specify it directly with the <code class="code">-sockdir</code> argument, or
indirectly via the config file (<code class="code">-conf</code>).</p>

<p>The <code class="code">-list</code> and <code class="code">-containers</code> switches allow it to get some introspection
into the running conglomerate of processes or threads. For <code class="code">-list</code>
the services and the socket addresses are printed. For <code class="code">-containers</code>
even more details are emitted, including the process IDs.</p>

<p>The <code class="code">-enable</code>, <code class="code">-disable</code>, and <code class="code">-restart</code> commands allow it to
manage the set of running services. A service can be disabled, which
means that all containers are shut down. Note that this does not mean
that incoming TCP connections are rejected. They are just not processed.
If enabled again, the containers are started again for the service,
and the processing of TCP connections is resumed (including the
connections that were accepted during the downtime). Disabling a
service is useful for temporarily stopping the service, e.g.
because it would interfer with other admin tasks.</p>

<p>A restart means to disable and re-enable the service. It may be
useful for cleanly reinitializing a service.</p>

<p>With <code class="code">-restart-all</code> even all services are restarted that are running
within the Netplex framework.</p>

<p>A <code class="code">-shutdown</code> starts the shutdown sequence. The shutdown is announced
to all containers, and in a second step, the containers are terminated.
Finally, the master process is also stopped.</p>

<p>The command <code class="code">-reopen-logfiles</code> is meaningful for all file-based
logging definitions. The current set of files is closed, and reopened
again. This is useful as post-action after log file rotation (see below).</p>

<p><code class="code">-unlink</code>: see below.</p>

<p><code class="code">netplex-admin</code> can also be used to send so-called admin messages to
the containers. These messages have a name and optionally arguments:</p>

<pre class="codepre"><code class="code">$ netplex-admin ... name arg1 arg2 ...
</code></pre>
<p>Generally, the possible admin commands must be defined by the Netplex
processors. A few commands are defined by default, though:</p>

<ul>
<li><code class="code">netplex.threadlist</code>: Outputs information about threads and processes
  to the log file</li>
<li><code class="code">netplex.logger.set_max_level &lt;level&gt;</code>: Changes the maximum log level
  to the level passed in the argument</li>
<li><code class="code">netplex.debug.enable &lt;module&gt;</code>: Enables debug logging (as controlled
  by <a href="Netlog.Debug.html"><code class="code">Netlog.Debug</code></a> for the module named in the argument. </li>
<li><code class="code">netplex.debug.disable &lt;module&gt;</code>: Disables debug logging (as controlled
  by <a href="Netlog.Debug.html"><code class="code">Netlog.Debug</code></a> for the module named in the argument. </li>
<li><code class="code">netplex.fd_table</code>: prints the file descriptor tracking table to
  the log file</li>
<li><code class="code">netplex.connections</code>: prints information about current TCP
  connections to the log file</li>
<li><code class="code">netplex.mem.major</code>: triggers a major GC run</li>
<li><code class="code">netplex.mem.compact</code>: triggers a GC compaction</li>
<li><code class="code">netplex.mem.pools</code>: output information about Ocamlnet pools to
  the log file</li>
<li><code class="code">netplex.mem.stats</code>: output information about the memory managed by
  the Ocaml runtime to the log file</li>
</ul>
<h2 id="logrotate">How to configure log file rotation</h2>
<p><code class="code">logrotate</code> is a common utility to perform log file rotation. It can
be easily used together with Netplex. The essential point is to
run <code class="code">netplex-admin -reopen-logfiles</code> as post action to the rotation.
This stanza is an example how to configure the rotation in a
<code class="code">logrotate</code> config file:</p>

<pre class="codepre"><code class="code">/var/log/myapp/file.log
{
	weekly
        rotate 10
        missingok
        sharedscripts
        postrotate
                /some/path/bin/netplex-admin \
                        -sockdir /var/lib/myapp/sockdir \
                        -reopen-logfiles
        endscript
}
</code></pre>
<h2 id="unlink">Deleting persistent kernel objects</h2>
<p>For some functionality, Netplex programs allocate persistent kernel
objects:</p>

<ul>
<li>POSIX shared memory</li>
<li>POSIX named semaphores</li>
<li>Temporary regular files</li>
</ul>
<p>These objects are effectively only used temporarily, but the available
system interfaces only allow it to allocate them in a kernel-persisting
manner. This means that the objects are not automatically released if
the program ends, like most other system resources, but that they remain
in memory after termination. If they were just left there behind, they
would consume memory forever.</p>

<p>Of course, most Netplex programs are carefully written, and delete these
objects if the program ends in a regular way. However, after a crash
the programs normally don't have a chance to delete the objects. In order
to allow administrative removal, many Netplex programs write the names
of these objects into a special file <code class="code">netplex.pmanage</code> residing in the
socket directory. The <code class="code">netplex-admin</code> command has a special mode in
order to perform the deletion:</p>

<pre class="codepre"><code class="code">netplex-admin -sockdir /path/to/sockdir -unlink
</code></pre>
<p>Some operating systems have actually means for adminstering the
kind of objects managed this way, but some have not. For example,
Linux reflects the objects as normal files in the <code class="code">/dev/shm</code>
directory. As a counter example, there is no administration possibility
in OS X.</p>

<p>(For programmers: The Netplex interface to access <code class="code">netplex.pmanage</code>
is <a href="Netplex_cenv.html#VALpmanage"><code class="code">Netplex_cenv.pmanage</code></a>.)</p>
</div>
</body></html>