These programs follow the usual GNU command line syntax, with long options
starting with two dashes (`-').
The options available to searchd on all builds are:
--configCONFIGFILE, -cCONFIGFILE
Tell searchd to use the given file as its
configuration, just as with indexer.
--console
Force
searchd into console mode; typically it will
be running as a conventional server application, and will aim to dump
information into the log files (as specified in sphinx.conf). Sometimes
though, when debugging issues in the configuration or the daemon itself, or
trying to diagnose hard-to-track-down problems, it may be easier to force it
to dump information directly to the console/command line from which it is
being called. Running in console mode also means that the process will not be
forked (so searches are done in sequence) and logs will not be written to. (It
should be noted that console mode is not the intended method for running
searchd.)
You can invoke it as such:
$ searchd --config /home/myuser/sphinx.conf --console
--cpustats
Used to provide actual CPU time report (in addition to
wall time) in both query log file (for every given query) and status report
(aggregated). It depends on
clock_gettime() system call and might
therefore be unavailable on certain systems.
You might start searchd thus:
$ searchd --config /home/myuser/sphinx.conf --cpustats
--help, -h, --?, -?
List all of the parameters that can be called in your
particular build of searchd.
--index INDEX,
-i INDEX
Serve only the specified index. Like
--port, this
is usually for debugging purposes; more long-term changes would generally be
applied to the configuration file itself.
Usage example:
$ searchd --index myindex
--iostats
Used in conjuction with the logging options (the
query_log will need to have been activated in sphinx.conf) to provide
more detailed information on a per-query basis as to the input/output
operations carried out in the course of that query, with a slight performance
hit and of course bigger logs. Further details are available under the query
log format section.
You might start searchd thus:
$ searchd --config /home/myuser/sphinx.conf --iostats
--listen, -l ( address ":" port
| port | path ) [ ":" protocol ]
Works as --port, but allow you to specify not only
the port, but full path, as IP address and port, or Unix-domain socket path,
that searchd will listen on. Otherwords, you can specify either an IP
address (or hostname) and port number, or just a port number, or Unix socket
path. If you specify port number but not the address, searchd will listen on
all network interfaces. Unix path is identified by a leading slash. As the
last param you can also specify a protocol handler (listener) to be used for
connections on this socket. Supported protocol values are 'sphinx' (Sphinx
0.9.x API protocol) and 'mysql41' (MySQL protocol used since 4.1 upto at least
5.1).
--logdebug, --logdebugv, --logdebugvv
Enable additional debug output in the daemon log. Should
only be needed rarely, to assist with debugging issues that could not be
easily reproduced on request. --logdebug causes daemon to fire general
debug messages. --logdebugv and --logdebugvv points to 'verbose'
and 'very verbose' debug info. The last could really flood your logfile.
--nodetach
Do not 'daemonize', or, do not detach into background.
Apart debug purposes, this switch is useful when you manage sphinx with
upstart init daemon. In this case actual 'daemonizing' will be done by upstart
itself, and also all tasks like starting, stopping, reloading the config and
respawning on crash will be done by the system, not the sphinx.
--pidfile PIDFILE
Explicitly state a PID file, where the process
information is stored regarding
searchd, used for inter-process
communications (for example,
indexer will need to know the PID to
contact
searchd for rotating indexes). Normally,
searchd would
use a PID if running in regular mode (i.e. not with
--console), but it
is possible that you will be running it in console mode whilst the index is
being updated and rotated, for which a PID file will be needed.
Example:
$ searchd --config /home/myuser/sphinx.conf --pidfile /home/myuser/sphinx.pid
--replay-flags OPTIONS
Specify a list of extra binary log replay options. The
supported options are:
•accept-desc-timestamp, ignore descending
transaction timestamps and replay such transactions anyway (the default
behavior is to exit with an error).
Example:
$ searchd --replay-flags=accept-desc-timestamp
--port PORT, -p PORT
Specify the
port that
searchd should listen
on, usually for debugging purposes. This will usually default to
9312,
but sometimes you need to run it on a different port. Specifying it on the
command line will override anything specified in the configuration file. The
valid range is 0 to 65535, but ports numbered 1024 and below usually require a
privileged account in order to run. Look also the
--listen option, it
will give you more possibilities to tune here.
An example of usage:
--safetrace
Forces searchd to only use system backtrace() call
in crash reports. In certain (rare) scenarios, this might be a
"safer" way to get that report. This is a debugging option.
--status
Query running
searchd instance status, using the
connection details from the (optionally) provided configuration file. It will
try to connect to the running instance using the first configured UNIX socket
or TCP port. On success, it will query for a number of status and performance
counter values and print them. You can use
Status() API call to access
the very same counters from your application.
Examples:
$ searchd --status
$ searchd --config /home/myuser/sphinx.conf --status
--stop
Asynchronously stop
searchd, using the details of
the PID file as specified in the sphinx.conf file, so you may also need to
confirm to
searchd which configuration file to use with the
--config option. NB, calling
--stop will also make sure any
changes applied to the indexes with
UpdateAttributes() will be applied
to the index files themselves.
Example:
$ searchd --config /home/myuser/sphinx.conf --stop
--stopwait
Synchronously stop
searchd.
--stop
essentially tells the running instance to exit (by sending it a
SIGTERM) and then immediately returns.
--stopwait will also
attempt to wait until the running
searchd instance actually finishes
the shutdown (eg. saves all the pending attribute changes) and exits.
Example:
$ searchd --config /home/myuser/sphinx.conf --stopwait
Possible exit codes are as follows:
•0 on success;
•1 if connection to running searchd daemon
failed;
•2 if daemon reported an error during
shutdown;
•3 if daemon crashed during shutdown
--strip-path
Strip the path names from all the file names referenced
from the index (stopwords, wordforms, exceptions, etc).
This is useful for picking up indexes built on another machine with possibly
different path layouts.
Visit the GSP FreeBSD Man Page Interface.