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:
Tell searchd to use the given file as its
configuration, just as with indexer.
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
You can invoke it as such:
$ searchd --config /home/myuser/sphinx.conf --console
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.
show version information of your particular build of
Serve only the specified index. Like --port
is usually for debugging purposes; more long-term changes would generally be
applied to the configuration file itself.
$ searchd --index myindex
Used in conjunction with the logging options (the
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 up to at
--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.
Do not 'daemonize', or, do not detach into background.
Apart debug purposes, this switch is useful when you manage Manticore Search
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
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
for rotating indexes). Normally, searchd
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.
$ searchd --config /home/myuser/sphinx.conf --pidfile /home/myuser/sphinx.pid
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).
$ searchd --replay-flags=accept-desc-timestamp
--port PORT, -p PORT
Specify the port
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
will give you more possibilities to tune here.
An example of usage:
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.
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.
$ searchd --status
$ searchd --config /home/myuser/sphinx.conf --status
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
option. NB, calling --stop
will also make sure any
changes applied to the indexes with UpdateAttributes()
will be applied
to the index files themselves.
$ searchd --config /home/myuser/sphinx.conf --stop
Synchronously stop searchd
essentially tells the running instance to exit (by sending it a
) and then immediately returns. --stopwait
attempt to wait until the running searchd
instance actually finishes
the shutdown (eg. saves all the pending attribute changes) and exits.
$ searchd --config /home/myuser/sphinx.conf --stopwait
Possible exit codes are as follows:
•0 on success;
•1 if connection to running searchd daemon
•2 if daemon reported an error during
•3 if daemon crashed during shutdown
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.