NAME
orb2orb - copy data from one or more input orbservers to one or more output orbservers
SYNOPSIS
CURRENT SYNTAX:
orb2orb [-qvx]
[-m match]
[-p pf]
[-r reject]
[-S statefile]
[-t targetname]
[[orbtag orbname] ...] [starttime [period|end-time]]
LEGACY SYNTAX:
orb2orb [-qvx]
[-m match]
[-p pf]
[-r reject]
[-S statefile]
[-t targetname]
orbin orbout [starttime [period|end-time]]
DESCRIPTION
The
orb2orb program transfers data packets from one or
more input
orbservers to one or more output
orbservers.
In the
CURRENT command-line syntax, these orbservers are specified
on the command-line via
orbtags, which are explained further below.
A
starttime may optionally be specified on the command-line.
Following the
starttime, either a
period or an
end-time may be specified. A
period is most conveniently
specified as
hh:mm, or perhaps
hh:mm:ss (in truth, the
period is parsed through the
str2epoch(3) function, so
any format acceptable to that function will work). The
starttime
and
end-time may be specified in any of the formats understood
by
epoch(1). Another alternative to a specific
endtime
is the word
last, which tells
orb2orb to copy to the
last packet in the ring buffer and then stop. Specifying
last causes
orb2orb to copy until the packet it copies
corresponds to the packet the orbserver reports as the last packet
in the orb when the
orb2orb instance was started.
-
Internal Queues
Unlike predecessors to this program, which transferred data packets
directly from input to output orbservers in one step,
orb2orb transfers in two steps: first from the source
orbserver(s) into orb2orb, then from orb2orb into
the destination orbserver(s). Internally, orb2orb stores
data packets in one or more queues while they are enroute
from input to output.
Each queue is given a nickname inside the orb2orb
parameter-file, for example mainq or statusq. No further
configuration of these queues is necessary other than to refer
to them inside the orb2orb parameter-file. Each queue
referred to in the orb2orb parameter-file is automatically
created by orb2orb.
-
Independent Connections
Configuring orb2orb requires specifying the input and output
connections independently: read connections from source
orbserver to internal queue, then write connections
from internal queue to destination orbserver.
Each connection is either solely a read connection,
or solely a write connection.
-
Orb tags and Orb names
The predecessor to this version of orb2orb (now named
orb2orb_dep(1)) required the user to specify the actual names
(IP:port) of the input and output orbserver(1)s directly
on the command-line. (The LEGACY syntax for this current version of
orb2orb still supports such direct specification of
orbserver(1) names, as long as there is just one input and
one output).
Because the current version of orb2orb may use the same orbserver(1)
name multiple times for multiple different connections (usually
write connections -- see caveat below), the CURRENT-syntax command-line
allows you to specify nicknames called orbtags for
each orbserver(1), followed by the actual name (IP:port) of the orbserver(1)
that each orbtag represents. Common examples of such orbtag
nicknames might be inputorb, outputorb, statusorb,
commandorb, etc. These orbtags are then also used in the
parameter-file to provide details of what is going into and out of
each particular orbserver(1). The orbtags used in the
parameter-file must match the orbtags used on the command-line.
For example, if the parameter-file refers to an orbtag of
inputorb, there must also be an argument pair on the command-line
assigning the orbtag of inputorb to the name
(IP:port, i.e. orbname) of a specific orbserver(1).
Each connection listed in the parameter-file must specify the
orbserver(1) from which the connection is reading or to which
it is writing. Usually this is done by specifying
(inside the parameter-file array for the connection) either the
parameter read_from_orbtag or the parameter write_to_orbtag
for the connection. (It is this choice of read_from... or
write_to... that determines whether the connection is a read or write
connection).
These orbtags cited in the parameter-file
must then also appear in the orb2orb command-line, where they
are assigned to specific orbname values (IP:port). This
same mechanism is also used in the q3302orb(1) program.
For situations where one instance of orb2orb is managing
connections to many different orbservers, for example to a
whole suite of Kinemetrics Rock dataloggers, specifying tens
to hundreds of individual orbtags in the parameter-file and
on the command-line could become prohibitive. For this reason,
another mechanism is supported: the operator may give the actual
orbname, as an IP:port address, of an orbserver(1) directly in
the parameter-file. In this case, instead of the parameters
read_from_orbtag or write_to_orbtag in the parameter-file
array for each connection, the operator should use the parameters
read_from_orbname or write_to_orbname. These latter
should be followed by the actual IP:port to
which to connect. The orb2orb program does not allow the user
to specify both an orbtag and an orbname for a connection
(i.e. you may not specify both read_from_orbtag and
read_from_orbname in the same connection array, nor may you specify
both write_to_orbtag and write_to_orbname in the same
connection array, otherwise orb2orb will get confused and
refuse to run).
Since orbnames may be specified explicitly in the parameter-file,
it is actually possible to set up orb2orb to run without using
any orbtags or orbnames at all on the command-line. In other words,
with an appropriately matching parameter-file, orb2orb
will start and run with no command-line arguments. This mode is only
recommended for orb2orb instances that are interacting with large numbers
of stations, however. For clarity, the default configuration (default
parameter-file) is for orb2orb to expect the two default
orbtags of inputorb and outputorb, which must
then be specified on the command-line.
Legacy Mode
orb2orb supports both
CURRENT and
LEGACY modes for
command-line syntax and parameter-file contents.
When used with the
CURRENT command-line syntax, shown above,
orb2orb requires the
CURRENT-format parameter-file with
connections table etc. as described below in the
PARAMETER
FILE section.
The
orb2orb program is also backwards compatible with the
command-line syntax of
orb2orb. When
orb2orb is launched
with a command-line matching the
LEGACY syntax, the parameter-file
is also assumed to be in the the
LEGACY format used by
orb2orb.
For further information on the
LEGACY command-line and parameter-file
format, see the man-page
orb2orb_dep(1).
OPTIONS
-
-m match
Copy only packets which match the regular expression match.
If specified, this option overrides any match expression set
in the parameter-file.
-
-p pf
Specify parameter-file name. The default is orb2orb.pf.
-
-q
Quiet mode, for the entire program. All verbosity including notify messages is suppressed.
Verbosity may also be controlled via the verbose
parameter for each connection in the parameter-file. For any given task thread, verbosity is governed by
the highest verbosity setting from the command-line or from the parameter-file for that task.
-
-r reject
Exclude packets which match the regular expression reject.
If specified, this option overrides any reject expression set
in the parameter-file.
-
-S statefile
Specify the name of a file in which to track acquisition state for
non-volatile restarts. With this option, whenever orb2orb
quits abnormally or due to a signal it attempts to save
into the statefile the time and pktid of the last packet it copied.
When
restarted, (if the -S option is again specified), orb2orb
attempts to read this statefile and reposition itself to
the same packet, so that there are no gaps in the copied data.
-
-t targetname
This name is used to uniquely identify this particular instance
of orb2orb. The targetname is placed in status- and log-packet source
names. Typically, this name would specify the network or
facility where orb2orb is running. If not specified, this
defaults to orb2orb.
-
-v
Verbose mode, for the entire program. This option may be specified between one and five times,
with more instances increasing the verbosity level. Verbosity may also be controlled via the verbose
parameter for each connection in the parameter-file. For any given task thread, verbosity is governed by
the highest verbosity setting from the command-line or from the parameter-file for that task.
-
-x
When this option is specified, orb2orb requests confirmation from the receiving
orbserver of each packet sent (via the orbputx(3) function call) for all connections. This is
primarily useful in push-style orb2orb connections in which the orb2orb
instance is running on the same machine as the orbserver that is the source of the transmitted packets.
This behavior may be controlled on a per-connection basis, rather than program-wide, via the acknowledge
parameter for each connection in the parameter-file. If -x is specified on the command-line, it
overrides any setting of acknowledge in the parameter-file for individual connections.
# .SS Options Used in Legacy Mode Only
FILES
orb2orb uses the
statefile, if one is specified with the
-S option, to track times and packet id's for the last packet
acquired from each orbserver.
COMMANDS
The
orb2orb supports orb-based commands via the mechanism described in
dlcmd(1). As described in that
man-page,
dlcmd(1) may be used to issue commands to
orb2orb that are read from an
orbserver
by
orb2orb (conventionally with the
orbtag of
cmdorb). After
orb2orb takes action on
a given command, depending on the contents of the incoming command it optionally writes a response packet back to the
command
orbserver indicating the disposition of the completed command.
In the parlance of
dlcmd(1), the
dltype should be set to
orb; the
target corresponds to the
target name of the
orb2orb instance (defaulting to
orb2orb if not specified); and the
dlname
corresponds to the connection task or tasks to be affected by the command.
All changes made via
orb2orb commands are transient, persisting only until changed by other commands or until
the current process instance of the
orb2orb executable is terminated. No updates are made to the
orb2orb
parameter-file to reflect configuration changes invoked by orb commands.
Available Commands
-
pingt
Return a response packet to dlcmd(1) to indicate that the orb2orb instance is alive.
-
quit
Alias for program quit.
-
program quit
Shut down gracefully and terminate the current instance of the orb2orb executable.
-
program set verbose <level>
Set the verbosity <level> for the entire orb2orb instance. Available levels are
quiet, notify, verbose, very, extremely, dump, and torrentially.
If both program and task verbosities are specified, the highest takes precedence for any given task.
Detailed explanations of these modes are given in Oorb::LogMgrTask(3).
-
task <taskname> pause
Pause the task given by <taskname>. The task stops all processing until resumed via a continue command
or until the termination of the orb2orb instance.
-
task <taskname> continue
Continue normal processing for the task given by <taskname>.
-
task <taskname> quit
Shut down gracefully and quit the task given by <taskname>.
-
task <taskname> set verbose <level>
Set the verbosity <level> for the task given by <taskname>. Available levels are
quiet, notify, verbose, very, extremely, dump, and torrentially.
If both program and task verbosities are specified, the highest takes precedence for any given task.
PARAMETER FILE
Parameter Descriptions
-
connections
The connections parameter is a table of arrays. Each array
specifies one connection that orb2orb will make, either
a read connection to bring data into orb2orb from an input
orbserver, or a write connection to send data from
orb2orb to an output orbserver.
Whether a connection is read or write is determined
automatically by orb2orb based on the parameters specified
in the array for the connection. Read connections have either
read_from_orbtag or read_from_orbname; write connections
have either write_to_orbtag or write_to_orbname.
Once the nature of a connection is determined, the default parameters for that
type of connection are read from the sub-arrays of the connections_defaults
array. Read connections read the read and shared parameters
out of connections_defaults; write connections read the write
and shared parameters out of connections_defaults. See the
Parameter-file Example section below for an example.
After the defaults are read for a given connection, any other parameters
for the connection are read out of the parameter-file array for the
connection. In this way, any of the defaults may be overridden by settings
specific for a given connection.
-
connections_defaults
The connections_defaults array holds default values for different
types of connections.
-
connections_defaults{read}
Parameters in the connections_defaults{read} are applied to
all read connections.
-
connections_defaults{write}
Parameters in the connections_defaults{write} are applied to
all write connections.
-
connections_defaults{shared}
Parameters in the connections_defaults{shared} are applied to
all connections, both read and write.
-
connections_defaults{shared}{name}
All connections have a name, which must be unique within the given instance of
orb2orb. This name is used in log messages, state files, and in
orb status packets.
-
connections_defaults{shared}{run}
The boolean run parameter determines whether the connection is enabled.
If run is set to false, all other parameters for this connection are ignored
and the connection is not activated.
-
connections_defaults{shared}{match}
The match regular-expression is used to choose which packets are
acquired or written. Packet source names are compared against this expression.
Although this parameter is allowed for both read and write connections,
generally it is best to put it on the read connection to avoid wasted bandwidth.
The value of this parameter will be overridden by anything specified on the
command=line via the -m option.
-
connections_defaults{shared}{reject}
The reject regular-expression is used to exclude packets from being
acquired or written. Packet source names are compared against this expression.
Although this parameter is allowed for both read and write connections,
generally it is best to put it on the read connection to avoid wasted bandwidth.
The value of this parameter will be overridden by anything specified on the
command=line via the -r option.
-
connections_defaults{shared}{verbose}
This parameter controls the verbosity of the connection. Valid settings
are quiet, notify, verbose, very, extremely, dump, and
torrentially. The actual verbosity of a task is determined by the highest of: (a) the
verbosity set on the orb2orb command-line; or (b) the verbosity set in the parameter-file
for that task.
-
connections_defaults{read}{read_from_orbname}
If read_from_orbname is specified, the connection reads data from the named orbserver.
A read connection must specify either read_from_orbname or read_from_orbtag
but may not specify both.
-
connections_defaults{read}{read_from_orbtag}
If read_from_orbtag is specified, orb2orb expects the named orbtag
to appear on the command-line along with the name of the orbserver(1) to which
it corresponds. Finding that, orb2orb reads from the indicated orbserver(1).
-
connections_defaults{read}{write_to_queue}
This parameter names the internal orb2orb queue to which acquired
data are written. The orb2orb program automatically creates the named
queue if necessary: no further configuration of queues is necessary
beyond naming them here, and making sure that the queues thus instantiated are used
in at least one write connection also (via the read_from_queue parameter described
below).
-
connections_defaults{read}{starttime}
If starttime is specified, orb2orb attempts to start reading packets
at the corresponding timestamp. The starttime parameter may be entered in any
time-string format acceptable to epoch2str(3), including a raw epoch time.
A starttime specified on the command=line will override this parameter-file value.
-
connections_defaults{read}{endtime}
If endtime is specified, orb2orb stops reading packets
whenever a packet with timestamp greater than or equal to endtime is encountered.
The endtime parameter may be entered in any
time-string format acceptable to epoch2str(3), including a raw epoch time.
An endtime specified on the command-line will override this parameter-file value.
-
connections_defaults{read}{too_old}
If too_old is specified, all packets with timestamps more than too_old
seconds before the current system time are discarded. If this parameter is left blank, no such
filtering is performed. Under normal conditions, too_old should be a positive
number. (Negative values of too_old will be honored, but will have an effect
on packets timestamped in the future rather than on packets timestamped in the past).
-
connections_defaults{read}{too_new}
If too_new is specified, all packets with timestamps more than too_new
seconds after the current system time are discarded. If this parameter is left blank, no such
filtering is performed. Under normal conditions, too_new should be a positive
number. (Negative values of too_new will be honored, but will have an effect
on packets timestamped in the past rather than on packets timestamped in the future).
-
connections_defaults{read}{check_unstuff}
If this boolean parameter is set to true, orb2orb checks whether acquired
packets successfully unstuff, by invoking the unstuffPkt(3) function on them.
If check_unstuff is true, packets failing this test are discarded. If
check_unstuff is false, this test is not performed.
-
connections_defaults{read}{suppress_unstuff_errors}
If this boolean parameter is set to false, orb2orb will create error messages
for any packets that fail to unstuff. For packet streams that are known to entrain
numerous packets that do not unstuff, it may be advantageous to set this parameter to
true to suppress error messages about the unstuff failures. Note that in Legacy Mode,
the suppress_unstuff_errors parameter is automatically set to true.
-
connections_defaults{write}{read_from_queue}
This parameter names the internal orb2orb queue from which
data are taken in order to put them on the specified output orbserver(1).
The orb2orb program automatically creates the named
queue if necessary: no further configuration of queues is necessary
beyond naming them here, and making sure that the queues thus instantiated are used
in at least one read connection also (via the write_to_queue parameter described
above).
-
connections_defaults{write}{write_to_orbname}
If write_to_orbname is specified, the connection reads data from the named orbserver.
A write connection must specify either write_to_orbname or write_to_orbtag
but may not specify both.
-
connections_defaults{write}{write_to_orbtag}
If write_to_orbtag is specified, orb2orb expects the named orbtag
to appear on the command-line along with the name of the orbserver(1) to which
it corresponds. Finding that, orb2orb writes to the indicated orbserver(1).
-
connections_defaults{write}{max_queue}
If the max_queue parameter is set to 0, internal
queues will grow without bound (this is rarely a good idea).
If set to a positive integer, max_queue will limit internal
queue growth to the specified number of packets. Once that
specified number of packets is reached in the internal queue,
read connections are blocked from writing to it until the
attached write connections drain the queue to contain
fewer than the specified max_queue number of packets. In Legacy Mode,
max_queue is set to 10000 packets.
-
connections_defaults{write}{acknowledge}
If this parameter is set to a yes or true, orb2orb requests acknowledgment
via orbputx(3) from the orbserver(1) for each packet written. This feature is the same
as the -x option on the command-line, which takes precedence over any parameter-file settings.
-
connections_special
This array manages tasks inside of orb2orb that are special
because the data packets from them are generated by orb2orb itself rather than
being acquired from external orbservers, and/or because they handle umbrella functions
such as command-and-control and statefile management.
-
connections_special{status}
The status task generates /pf/st status packets from
within orb2orb. These status packets provide metadata information on
the state-of-health of orb2orb connections. Internal to the program, this task
is actually an instance of Oorb::StatusMgrTask(3).
-
connections_special{status}{run}
If this boolean parameter is false, the status task
is turned off and no status packets are generated.
-
connections_special{status}{write_to_queue}
This parameter names the queue to which status should write
the status packets it generates.
-
connections_special{status}{verbose}
This parameter controls the verbosity of the status task. Valid settings
are quiet, notify, verbose, very, extremely, dump, and torrentially.
The actual verbosity of a task is determined by the highest of: (a) the verbosity set on the
orb2orb command-line; or (b) the verbosity set in the parameter-file for that task.
-
connections_special{logs}
The logs task generates /log log packets from
within orb2orb. These log packets provide diagnostic information on
run-time conditions within orb2orb. Internal to the program, this task is actually
an instance of Oorb::LogMgrTask(3).
-
connections_special{logs}{run}
If this boolean parameter is false, the logs task
is turned off and no log packets are generated.
-
connections_special{logs}{verbose}
This parameter controls the verbosity of the logs task. Valid settings
are quiet, notify, verbose, very, extremely, dump, and torrentially.
The actual verbosity of a task is determined by the highest of: (a) the verbosity set on the
orb2orb command-line; or (b) the verbosity set in the parameter-file for that task.
-
connections_special{logs}{write_to_queue}
This parameter names the queue to which the logs pseudo-connection
should write the messages it receives, so they can in turn be written to an orbserver
as /log packets. The source-name of these output packets will be the configured
targetname of the orb2orb instance followed by the /log suffix. To
prevent self-amplifying message cascades, only messages with Oorb::LogMsg::Severity(3)
of very or below will be written to the write_to_queue.
-
connections_special{commands}
The commands pseudo-connection reads dlcmd(1) command packets and
generates responses.
-
connections_special{commands}{run}
If this boolean parameter is false, the commands task
is turned off and no status packets are generated.
-
connections_special{commands}{orbtag}
This parameter names the orbtag from and to which commands should
read and write command packets and responses.
-
connections_special{commands}{verbose}
This parameter controls the verbosity of the commands task. Valid settings
are quiet, notify, verbose, very, extremely, dump, and torrentially.
The actual verbosity of a task is determined by the highest of: (a) the verbosity set on the
orb2orb command-line; or (b) the verbosity set in the parameter-file for that task.
-
connections_special{state}
The state pseudo-connection reads and generates state information for orb2orb
if a statefile is specified on the command-line.
-
connections_special{state}{verbose}
This parameter controls the verbosity of the state task. Valid settings
are quiet, notify, verbose, very, extremely, dump, and torrentially.
The actual verbosity of a task is determined by the highest of: (a) the verbosity set on the
orb2orb command-line; or (b) the verbosity set in the parameter-file for that task.
-
time_intervals_sec
This array specifies several time intervals, as numbers of seconds, used
by orb2orb.
-
time_intervals_sec{pfstatusreport}
The pfstatusreport parameter declares how often orb2orb
issues /pf/st status packets to an orbserver for the dlmon(1)
program.
-
time_intervals_sec{internal_timeout}
The internal_timeout parameter determines such things as how often
statefile information is saved, how long the timeout is on
pmtmanagedfifo(3) reads, and how long the timeout is for
orbreap_timeout(3) calls. Generally this parameter should not be modified.
-
time_intervals_sec{shutdown_grace_period}
After a shutdown is initiated, e.g. by issuing a SIGTERM to
orb2orb, individual connection threads are given a short period of
time, specified by shutdown_grace_period, to exit normally before they
are summarily terminated. There is one exception to this, which is that if any
connections are still attempting to connect to their target orbserver(1),
that timeout is governed by the setting of the BNS_TIMEOUT environment
variable, which defaults to 60 seconds and is documented in the bns(3)
man-page.
-
time_intervals_sec{datarate_interval}
This is the averaging duration in seconds for computing data rate averages.
This interval is also used for computing packet rate averages.
-
time_intervals_sec{thruput_interval}
This is the averaging duration in seconds for computing thruput averages.
Thruput in the case of orb2orb means the ratio of seconds of waveform
data ingested to seconds of real-time clock elapsed. (orb2orb
averages thruput over all waveform sourcenames being ingested).
This interval is also used for computing the average number of sourcenames,
and the average number of waveform sourcenames.
-
time_intervals_sec{retain_unused_stateinfo}
This is the number of seconds to retain state-file information blocks for connections
that are not in use. Note that this version of orb2orb preserves legacy state-information
from older versions of orb2orb, time-stamping such information upon orb2orb startup
with the current wall-clock time. This legacy information can then be purged on subsequent runs
if said information remains unused and expires past this interval.
Parameter-file Example
connections &Tbl{
&Arr{
name reader_main
read_from_orbtag inputorb
}
&Arr{
name writer_main
write_to_orbtag outputorb
}
}
connections_defaults &Arr{
read &Arr{
read_from_orbname
read_from_orbtag
write_to_queue mainq
starttime
endtime
too_old
too_new
check_unstuff true
suppress_unstuff_errors true
}
write &Arr{
read_from_queue mainq
write_to_orbname
write_to_orbtag
max_queue 10000
acknowledge no
}
shared &Arr{
run true
match
reject
verbose notify
}
}
connections_special &Arr{
status &Arr{
run true
write_to_queue mainq
verbose notify
}
logs &Arr{
write_to_queue mainq
verbose notify
}
commands &Arr{
run true
orbtag inputorb
verbose notify
}
state &Arr{
verbose notify
}
}
time_intervals_sec &Arr{
pfstatusreport 2
internal_timeout 1
shutdown_grace_period 15
datarate_interval 60.0
thruput_interval 120.0
retain_unused_stateinfo 604800 # 604800 sec = 1 week
}
Parameter-file Connections Table Example: Multiple dataloggers
If a single
orb2orb instance connects to multiple dataloggers
by specifying an individual connection for each datalogger
directly in the parameter-file, the
connections table of
the parameter file may look something like this:
connections &Tbl{
&Arr{
name reader_KCAN
read_from_orbname KCAN.example.com:9500
}
&Arr{
name reader_KACQ
read_from_orbname KACQ.example.com:9500
}
&Arr{
name reader_KALD
read_from_orbname KALD.example.com:9500
run false # Turn this station off for the moment
}
&Arr{
name reader_KAMT
read_from_orbname KAMT.example.com:9500
}
....
....
}
EXAMPLE
% orb2orb -v inputorb bbarray.ucsd.edu:gsn outputorb :
% dlcmd :gsn orb2orb orb - task reader_main pause
orb2orb:0 &Arr{
command task reader_main pause
disposition done
sequence .*_snowmass.brtt.com_3239_0
sequence_target snowmass_2439_0
target orb2orb
thostname snowmass
tip
tpid 2439
tusername kent
type orb
}
% dlcmd :gsn orb2orb orb - task reader_main continue
orb2orb:0 &Arr{
command task reader_main continue
disposition done
sequence .*_snowmass.brtt.com_3574_0
sequence_target snowmass_2439_1
target orb2orb
thostname snowmass
tip
tpid 2439
tusername kent
type orb
}
% dlcmd :gsn orb2orb orb - program quit
orb2orb:0 &Arr{
command program quit
disposition done
sequence .*_snowmass.brtt.com_3860_0
sequence_target snowmass_2439_2
target orb2orb
thostname snowmass
tip
tpid 2439
tusername kent
type orb
}
%
To read packets out of an
forbserver(1) file as input:
% orb2orb inputorb ./packets_data.forb outputorb :
DIAGNOSTICS
Many diagnostics are available either as output to
stderr, and/or as
/log
packets put on an
orbserver(1).
SEE ALSO
orb2orb_dep(1), dlmon(1), pmtmanagedfifo(3)
BUGS AND CAVEATS
Due to complexities with proper
statefile tracking in the current version of
orb2orb, the setting of
auto for the per-connection
name parameter
is no longer allowed. All connections must be given a unique
name in the parameter-file.
If a
statefile is specified and also present,
orb2orb ignores
any configured
starttime. The
starttime parameter is honored
if there is no
statefile specified, or if one is specified but not present.
If a
statefile is specified and reconnection discovers that the
orbserver
has already lapped past the data timestamp specified in the
statefile,
orb2orb
attempts to restart acquisition at the oldest packet in the orbserver.
The current version of
orb2orb will do its best to use
statefile information from
previous versions of
orb2orb, updating the state file to current format as
orb2orb runs.
Not all features of
statefile and starttime management that are available for the current version
command-line syntax are available when using legacy command-line syntax. Going forward, not all new
features added to
orb2orb will be supported under the legacy command-line syntax. Please switch to the
current version of the command-line syntax for the most up-to-date features and
orb2orb behavior.
When
orb2orb is given an
forbserver(1) file as input, all specified
starttime
information for that orb will be ignored. Instead, the named
forbserver(1) file will be read
from beginning to end, or until the endtime specified. Specifically, it is not necessary to specify on the
command=line an
endtime of
last for an
forbserver(1) file.
The output of log-message packets to an
orbserver(1) is limited to messages having
Oorb::LogMsg::Severity(3)
of
very or below, in order to prevent self-amplifying message cascades. Also, not all shutdown-related
messages are able to be echoed to an
orbserver(1) due to chicken-and-egg problems.
It is in principle possible to configure orb2orb such that a particular queue gets filled in by
a read task (or packet-creation process such as the status-monitoring task), without that
queue getting emptied by any corresponding write task. This can result in a growth in memory usage
of the program, which should be avoided by proper configuration.
The
connections_special{logs} and
connections_special{status} parameters were formerly named
log_create and
status_create. They have been renamed to align better with current and future
expansions.
When running in
extremely verbose mode and above, the log files for
orb2orb running
under an
rtexec(1)-based system can fill exceedingly quickly. While this is once again
not recommended for operational use, if
extremely verbose mode is needed for any length of
time, it may be necessary to invoke an
rtexec(1) cron procedure such as
cleanlogs LOCAL 0,15,30,45 * * * * truncate_log -v -f -m 10000 -r logs/orb2orb
Per the
rtexec(1) man-page, the above in the
crontab table of
rtexec.pf
would limit the orb2orb process log to the order of 10 Megabytes.
AUTHOR
Kent Lindquist