home | help 
SEARCHD(8)			  Sphinxsearch			      SEARCHD(8)

NAME
     searchd - Sphinxsearch network daemon.

SYNOPSIS
     searchd   [--config CONFIGFILE]  [--cpustats]  [--iostats]  [--index INDEX]
	     [--port PORT]

     searchd --status [--config CONFIGFILE] [--pidfile PIDFILE]

     searchd --stop [--config CONFIGFILE] [--pidfile PIDFILE]

DESCRIPTION
     Sphinx is a collection of programs that aim to provide high  quality  full-
     text search.

     Searchd  is  the  second  of  the	two  principle	tools as part of Sphinx.
     searchd is the part of the system which actually handles searches; it func-
     tions as a server and is responsible for receiving queries, processing them
     and returning a dataset back to the different APIs for client applications.

     Unlike indexer, searchd is not designed to be run	either	from  a  regular
     script or command-line calling, but instead either as a daemon to be called
     from  init.d  (on Unix/Linux type systems) or to be called as a service (on
     Windows-type systems). so not all of the command line options  will  always
     apply, and so will be build-dependent.

OPTIONS
     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 con-
	 ventional server application, and will aim to dump information into the
	 log  files (as specified in sphinx.conf). Sometimes though, when debug-
	 ging issues in the configuration or the daemon itself, or trying to di-
	 agnose 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  (aggre-
	 gated).  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 debug-
	 ging 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 informa-
	 tion 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 repro-
	 duced	on request.  --logdebug causes daemon to fire general debug mes-
	 sages.  --logdebugv and --logdebugvv points to 'verbose' and 'very ver-
	 bose' debug info. The last could really flood your logfile.

     --nodetach
	 Do not 'daemonize', or, do not detach into background. Apart debug pur-
	 poses, this switch is useful when you manage sphinx with  upstart  init
	 daemon.  In  this case actual 'daemonizing' will be done by upstart it-
	 self, 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 in-
	 dexes). 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 op-
	 tions 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:

	     $ searchd --port 9313

     --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 re-
	 port. 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 con-
	 nect to the running instance using the first configured UNIX socket  or
	 TCP  port. On success, it will query for a number of status and perfor-
	 mance 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 spec-
	 ified	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  in-
	 stance  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.

SIGNALS
     Last  but	not  least,  as every other daemon, searchd supports a number of
     signals.

     SIGTERM
	 Initiates a clean shutdown.  New  queries  will  not  be  handled;  but
	 queries that are already started will not be forcibly interrupted.

     SIGHUP
	 Initiates  index  rotation.  Depending  on the value of seamless_rotate
	 setting, new queries might be shortly	stalled;  clients  will  receive
	 temporary errors.

     SIGUSR1
	 Forces reopen of searchd log and query log files, letting you implement
	 log file rotation.

AUTHOR
     Andrey  Aksenoff  (shodan@sphinxsearch.com). This manual page is written by
     Alexey Vinogradov (klirichek@sphinxsearch.com), using the	one  written  by
     Christian	Hofstaedtler  ch+debian-packages@zeha.at  for  the Debian system
     (but may be used by others). Permission  is  granted  to  copy,  distribute
     and/or  modify  this document under the terms of the GNU General Public Li-
     cense, Version 2 any later version published by the Free  Software  Founda-
     tion.

     On  Debian systems, the complete text of the GNU General Public License can
     be found in /usr/share/common-licenses/GPL.

SEE ALSO
     indexer(1), search(1), indextool(1)

     Sphinx and it's programs are documented fully by the Sphinx reference  man-
     ual available in /usr/share/doc/sphinxsearch.

2.2.11-release			   07/19/2016			      SEARCHD(8)
home | help