The Chef server has a built in process supervisor, which ensures that all of the required services are in the appropriate state at any given time. The supervisor starts two processes per service.
This command has a built in process supervisor that ensures all of the required services are in the appropriate state at any given time. The supervisor starts two processes per service and provides the following subcommands for managing services: hup
, int
, kill
, once
, restart
, service-list
, start
, status
, stop
, tail
, and term
.
The hup
subcommand is used to send a SIGHUP
to all services. This command can also be run for an individual service by specifying the name of the service in the command.
This subcommand has the following syntax:
$ chef-server-ctl hup SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand.
The int
subcommand is used to send a SIGINT
to all services. This command can also be run for an individual service by specifying the name of the service in the command.
This subcommand has the following syntax:
$ chef-server-ctl int SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand.
The kill
subcommand is used to send a SIGKILL
to all services. This command can also be run for an individual service by specifying the name of the service in the command.
This subcommand has the following syntax:
$ chef-server-ctl kill SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand.
The supervisor for the Chef server is configured to restart any service that fails, unless that service has been asked to change its state. The once
subcommand is used to tell the supervisor to not attempt to restart any service that fails.
This command is useful when troubleshooting configuration errors that prevent a service from starting. Run the once
subcommand followed by the status
subcommand to look for services in a down state and/or to identify which services are in trouble. This command can also be run for an individual service by specifying the name of the service in the command.
This subcommand has the following syntax:
$ chef-server-ctl once SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand.
The restart
subcommand is used to restart all services enabled on the Chef server or to restart an individual service by specifying the name of that service in the command.
Warning
When running the Chef server in a high availability configuration, restarting all services may trigger failover.
This subcommand has the following syntax:
$ chef-server-ctl restart SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand. When a service is successfully restarted the output should be similar to:
$ ok: run: service_name: (pid 12345) 1s
The service-list
subcommand is used to display a list of all available services. A service that is enabled is labeled with an asterisk (*).
This subcommand has the following syntax:
$ chef-server-ctl service-list
The start
subcommand is used to start all services that are enabled in the Chef server. This command can also be run for an individual service by specifying the name of the service in the command.
This subcommand has the following syntax:
$ chef-server-ctl start SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand. When a service is successfully started the output should be similar to:
$ ok: run: service_name: (pid 12345) 1s
The supervisor for the Chef server is configured to wait seven seconds for a service to respond to a command from the supervisor. If you see output that references a timeout, it means that a signal has been sent to the process, but that the process has yet to actually comply. In general, processes that have timed out are not a big concern, unless they are failing to respond to the signals at all. If a process is not responding, use a command like the kill
subcommand to stop the process, investigate the cause (if required), and then use the start
subcommand to re-enable it.
The status
subcommand is used to show the status of all services available to the Chef server. The results will vary based on the configuration of a given server. This subcommand has the following syntax:
$ chef-server-ctl status
and will return the status for all services. Status can be returned for individual services by specifying the name of the service as part of the command:
$ chef-server-ctl status SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand.
When service status is requested, the output should be similar to:
$ run: service_name: (pid 12345) 12345s; run: log: (pid 1234) 67890s
where
run:
is the state of the service (run:
or down:
)service_name:
is the name of the service for which status is returned(pid 12345)
is the process identifier12345s
is the uptime of the service, in secondsFor example:
$ down: opscode-erchef: (pid 35546) 10s
By default, runit will restart services automatically when the services fail. Therefore, runit may report the status of a service as run:
even when there is an issue with that service. When investigating why a particular service is not running as it should be, look for the services with the shortest uptimes. For example, the list below indicates that the opscode-erchef should be investigated further:
run: oc-id run: opscode-chef: (pid 4327) 13671s; run: log: (pid 4326) 13671s run: opscode-erchef: (pid 5383) 5s; run: log: (pid 4382) 13669s run: opscode-expander: (pid 4078) 13694s; run: log: (pid 4077) 13694s run: opscode-expander-reindexer: (pid 4130) 13692s; run: log: (pid 4114) 13692s
On back-end servers in a high availability topology, Keepalived is used by the clustering service to determine whether a service should be running. If the status
subcommand is run against any of these nodes, a few things change:
A sample status line for a service that is running on the master server in a high availability topology:
run: opscode-solr4: (pid 25341) 239s, normally down; run: log: (pid 5700) 145308s
A typical status line for a service that is running any of the Chef server front-end services is similar to the following:
run: name_of_service: (pid 1486) 7819s; run: log: (pid 1485) 7819s
where:
run
describes the state in which the supervisor attempts to keep processes. This state is either run
or down
. If a service is in a down
state, it should be stoppedname_of_service
is the service name, for example: opscode-solr4
(pid 1486) 7819s;
is the process identifier followed by the amount of time (in seconds) the service has been runningrun: log: (pid 1485) 7819s
is the log process. It is typical for a log process to have a longer run time than a service; this is because the supervisor does not need to restart the log process in order to connect the supervised processIf the service is down, the status line will appear similar to the following:
down: opscode-solr4: 3s, normally up; run: log: (pid 1485) 8526s
where
down
indicates that the service is in a down state3s, normally up;
indicates that the service is normally in a run state and that the supervisor would attempt to restart this service after a rebootThe stop
subcommand is used to stop all services enabled on the Chef server. This command can also be run for an individual service by specifying the name of the service in the command.
This subcommand has the following syntax:
$ chef-server-ctl stop SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand. When a service is successfully stopped the output should be similar to:
$ ok: diwb: service_name: 0s, normally up
For example:
$ chef-server-ctl stop
will return something similar to:
ok: down: nginx: 393s, normally up ok: down: opscode-chef: 391s, normally up ok: down: opscode-erchef: 391s, normally up ok: down: opscode-expander: 390s, normally up ok: down: opscode-expander-reindexer: 389s, normally up ok: down: opscode-solr4: 389s, normally up ok: down: postgresql: 388s, normally up ok: down: rabbitmq: 388s, normally up ok: down: redis_lb: 387s, normally up
The tail
subcommand is used to follow all of the Chef server logs for all services. This command can also be run for an individual service by specifying the name of the service in the command.
This subcommand has the following syntax:
$ chef-server-ctl tail SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand.
The term
subcommand is used to send a SIGTERM
to all services. This command can also be run for an individual service by specifying the name of the service in the command.
This subcommand has the following syntax:
$ chef-server-ctl term SERVICE_NAME
where SERVICE_NAME
represents the name of any service that is listed after running the service-list
subcommand.
The following services are part of the Chef server:
The oc_bifrost service ensures that every request to view or manage objects stored on the Chef server is authorized.
To view the status for the service:
$ chef-server-ctl status bifrost
to return something like:
$ run: bifrost: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start bifrost
To stop the service:
$ chef-server-ctl stop bifrost
To restart the service:
$ chef-server-ctl restart bifrost
to return something like:
$ ok: run: bifrost: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill bifrost
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once bifrost
To follow the logs for the service:
$ chef-server-ctl tail bifrost
The bookshelf service is an Amazon Simple Storage Service (S3)-compatible service that is used to store cookbooks, including all of the files—recipes, templates, and so on—that are associated with each cookbook.
To view the status for the service:
$ chef-server-ctl status bookshelf
to return something like:
$ run: bookshelf: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start bookshelf
To stop the service:
$ chef-server-ctl stop bookshelf
To restart the service:
$ chef-server-ctl restart bookshelf
to return something like:
$ ok: run: bookshelf: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill bookshelf
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once bookshelf
To follow the logs for the service:
$ chef-server-ctl tail bookshelf
The keepalived service manages the virtual IP address (VIP) between the backend machines in a high availability topology that uses DRBD.
To view the status for the service:
$ chef-server-ctl status keepalived
to return something like:
$ run: keepalived: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start keepalived
To stop the service:
$ chef-server-ctl stop keepalived
To restart the service:
$ chef-server-ctl restart keepalived
to return something like:
$ ok: run: keepalived: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill keepalived
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once keepalived
To follow the logs for the service:
$ chef-server-ctl tail keepalived
The nginx service is used to manage traffic to the Chef server, including virtual hosts for internal and external API request/response routing, external add-on request routing, and routing between front- and back-end components.
To view the status for the service:
$ chef-server-ctl status nginx
to return something like:
$ run: nginx: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start nginx
To stop the service:
$ chef-server-ctl stop nginx
To restart the service:
$ chef-server-ctl restart nginx
to return something like:
$ ok: run: nginx: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill nginx
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once nginx
To follow the logs for the service:
$ chef-server-ctl tail nginx
The opscode-erchef service is an Erlang-based service that is used to handle Chef server API requests to the following areas within the Chef server:
To view the status for the service:
$ chef-server-ctl status opscode-erchef
to return something like:
$ run: opscode-erchefs: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start opscode-erchef
To stop the service:
$ chef-server-ctl stop opscode-erchef
To restart the service:
$ chef-server-ctl restart opscode-erchef
to return something like:
$ ok: run: opscode-erchef: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill opscode-erchef
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once opscode-erchef
To follow the logs for the service:
$ chef-server-ctl tail opscode-erchef
The opscode-expander service is used to process data (pulled from the rabbitmq service’s message queue) so that it can be properly indexed by the opscode-solr4 service.
To view the status for the service:
$ chef-server-ctl status opscode-expander
to return something like:
$ run: opscode-expander: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start opscode-expander
To stop the service:
$ chef-server-ctl stop opscode-expander
To restart the service:
$ chef-server-ctl restart opscode-expander
to return something like:
$ ok: run: opscode-expander: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill opscode-expander
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once opscode-expander
To follow the logs for the service:
$ chef-server-ctl tail opscode-expander
The opscode-solr4 service is used to create the search indexes used for searching objects like nodes, data bags, and cookbooks. (This service ensures timely search results via the Chef server API; data that is used by the Chef platform is stored in PostgreSQL.)
To view the status for the service:
$ chef-server-ctl status opscode-solr
to return something like:
$ run: opscode-solr: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start opscode-solr
To stop the service:
$ chef-server-ctl stop opscode-solr
To restart the service:
$ chef-server-ctl restart opscode-solr
to return something like:
$ ok: run: opscode-solr: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill opscode-solr
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once opscode-solr
To follow the logs for the service:
$ chef-server-ctl tail opscode-solr
The postgresql service is used to store node, object, and user data.
To view the status for the service:
$ chef-server-ctl status postgresql
to return something like:
$ run: postgresql: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start postgresql
To stop the service:
$ chef-server-ctl stop postgresql
To restart the service:
$ chef-server-ctl restart postgresql
to return something like:
$ ok: run: postgresql: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill postgresql
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once postgresqls
To follow the logs for the service:
$ chef-server-ctl tail postgresql
The rabbitmq service is used to provide the message queue that is used by the Chef server to get search data to Apache Solr so that it can be indexed for search. When Chef Analytics is confiugred, the rabbitmq service is also used to send data from the Chef server to the Chef Analytics server.
To view the status for the service:
$ chef-server-ctl status rabbitmq
to return something like:
$ run: rabbitmq: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start rabbitmq
To stop the service:
$ chef-server-ctl stop rabbitmq
To restart the service:
$ chef-server-ctl restart rabbitmq
to return something like:
$ ok: run: rabbitmq: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill rabbitmq
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once rabbitmq
To follow the logs for the service:
$ chef-server-ctl tail rabbitmq
Key-value store used in conjunction with Nginx to route requests and populate request data used by the Chef server.
To view the status for the service:
$ chef-server-ctl status redis
to return something like:
$ run: redis: (pid 1234) 123456s; run: log: (pid 5678) 789012s
To start the service:
$ chef-server-ctl start redis
To stop the service:
$ chef-server-ctl stop redis
To restart the service:
$ chef-server-ctl restart redis
to return something like:
$ ok: run: redis: (pid 1234) 1234s
To kill the service (send a SIGKILL
command):
$ chef-server-ctl kill name_of_service
To run the service, but not restart it (if the service fails):
$ chef-server-ctl once redis
To follow the logs for the service:
$ chef-server-ctl tail name_of_service
© Chef Software, Inc.
Licensed under the Creative Commons Attribution 3.0 Unported License.
The Chef™ Mark and Chef Logo are either registered trademarks/service marks or trademarks/servicemarks of Chef, in the United States and other countries and are used with Chef Inc's permission.
We are not affiliated with, endorsed or sponsored by Chef Inc.
https://docs-archive.chef.io/release/server_12-8/server_services.html