No OneTemporary
Actions

Size

28 KB

Referenced Files

None

Subscribers

None

View Options

	diff --git a/src/applications/almanac/application/PhabricatorAlmanacApplication.php b/src/applications/almanac/application/PhabricatorAlmanacApplication.php
	index 76caa3a06b..27b41e9cd0 100644
	--- a/src/applications/almanac/application/PhabricatorAlmanacApplication.php
	+++ b/src/applications/almanac/application/PhabricatorAlmanacApplication.php
	@@ -1,112 +1,111 @@
	<?php

	final class PhabricatorAlmanacApplication extends PhabricatorApplication {

	public function getBaseURI() {
	return '/almanac/';
	}

	public function getName() {
	return pht('Almanac');
	}

	public function getShortDescription() {
	return pht('Service Directory');
	}

	public function getIcon() {
	return 'fa-server';
	}

	public function getTitleGlyph() {
	return "\xE2\x98\x82";
	}

	public function getApplicationGroup() {
	return self::GROUP_UTILITIES;
	}

	public function getHelpDocumentationArticles(PhabricatorUser $viewer) {
	return array(
	array(
	'name' => pht('Almanac User Guide'),
	'href' => PhabricatorEnv::getDoclink('Almanac User Guide'),
	),
	);
	}

	public function getRoutes() {
	return array(
	'/almanac/' => array(
	'' => 'AlmanacConsoleController',
	'(?P<objectType>service)/' => array(
	$this->getQueryRoutePattern() => 'AlmanacServiceListController',
	$this->getEditRoutePattern('edit/') => 'AlmanacServiceEditController',
	'view/(?P<name>[^/]+)/' => 'AlmanacServiceViewController',
	),
	'(?P<objectType>device)/' => array(
	$this->getQueryRoutePattern() => 'AlmanacDeviceListController',
	$this->getEditRoutePattern('edit/') => 'AlmanacDeviceEditController',
	'view/(?P<name>[^/]+)/' => 'AlmanacDeviceViewController',
	),
	'interface/' => array(
	'edit/(?:(?P<id>\d+)/)?' => 'AlmanacInterfaceEditController',
	'delete/(?:(?P<id>\d+)/)?' => 'AlmanacInterfaceDeleteController',
	),
	'binding/' => array(
	'edit/(?:(?P<id>\d+)/)?' => 'AlmanacBindingEditController',
	'disable/(?:(?P<id>\d+)/)?' => 'AlmanacBindingDisableController',
	'(?P<id>\d+)/' => 'AlmanacBindingViewController',
	),
	'network/' => array(
	$this->getQueryRoutePattern() => 'AlmanacNetworkListController',
	'edit/(?:(?P<id>\d+)/)?' => 'AlmanacNetworkEditController',
	'(?P<id>\d+)/' => 'AlmanacNetworkViewController',
	),
	'namespace/' => array(
	$this->getQueryRoutePattern() => 'AlmanacNamespaceListController',
	$this->getEditRoutePattern('edit/')
	=> 'AlmanacNamespaceEditController',
	'(?P<id>\d+)/' => 'AlmanacNamespaceViewController',
	),
	'property/' => array(
	'delete/' => 'AlmanacPropertyDeleteController',
	'update/' => 'AlmanacPropertyEditController',
	),
	),
	);
	}

	protected function getCustomCapabilities() {
	$cluster_caption = pht(
	'This permission is very dangerous. %s',
	phutil_tag(
	'a',
	array(
	- 'href' => PhabricatorEnv::getDoclink(
	- 'User Guide: Phabricator Clusters'),
	+ 'href' => PhabricatorEnv::getDoclink('Clustering Introduction'),
	'target' => '_blank',
	),
	pht('Learn More')));

	return array(
	AlmanacCreateServicesCapability::CAPABILITY => array(
	'default' => PhabricatorPolicies::POLICY_ADMIN,
	),
	AlmanacCreateDevicesCapability::CAPABILITY => array(
	'default' => PhabricatorPolicies::POLICY_ADMIN,
	),
	AlmanacCreateNetworksCapability::CAPABILITY => array(
	'default' => PhabricatorPolicies::POLICY_ADMIN,
	),
	AlmanacCreateNamespacesCapability::CAPABILITY => array(
	'default' => PhabricatorPolicies::POLICY_ADMIN,
	),
	AlmanacManageClusterServicesCapability::CAPABILITY => array(
	'default' => PhabricatorPolicies::POLICY_NOONE,
	'caption' => $cluster_caption,
	),
	);
	}

	}
	diff --git a/src/applications/almanac/controller/AlmanacController.php b/src/applications/almanac/controller/AlmanacController.php
	index c23e99591d..e4d9921660 100644
	--- a/src/applications/almanac/controller/AlmanacController.php
	+++ b/src/applications/almanac/controller/AlmanacController.php
	@@ -1,214 +1,214 @@
	<?php

	abstract class AlmanacController
	extends PhabricatorController {

	protected function buildAlmanacPropertiesTable(
	AlmanacPropertyInterface $object) {

	$viewer = $this->getViewer();
	$properties = $object->getAlmanacProperties();

	$this->requireResource('almanac-css');
	Javelin::initBehavior('phabricator-tooltips', array());

	$can_edit = PhabricatorPolicyFilter::hasCapability(
	$viewer,
	$object,
	PhabricatorPolicyCapability::CAN_EDIT);

	$properties = $object->getAlmanacProperties();

	$icon_builtin = id(new PHUIIconView())
	->setIcon('fa-circle')
	->addSigil('has-tooltip')
	->setMetadata(
	array(
	'tip' => pht('Builtin Property'),
	'align' => 'E',
	));

	$icon_custom = id(new PHUIIconView())
	->setIcon('fa-circle-o grey')
	->addSigil('has-tooltip')
	->setMetadata(
	array(
	'tip' => pht('Custom Property'),
	'align' => 'E',
	));

	$builtins = $object->getAlmanacPropertyFieldSpecifications();
	$defaults = mpull($builtins, null, 'getValueForTransaction');

	// Sort fields so builtin fields appear first, then fields are ordered
	// alphabetically.
	$properties = msort($properties, 'getFieldName');

	$head = array();
	$tail = array();
	foreach ($properties as $property) {
	$key = $property->getFieldName();
	if (isset($builtins[$key])) {
	$head[$key] = $property;
	} else {
	$tail[$key] = $property;
	}
	}

	$properties = $head + $tail;

	$delete_base = $this->getApplicationURI('property/delete/');
	$edit_base = $this->getApplicationURI('property/update/');

	$rows = array();
	foreach ($properties as $key => $property) {
	$value = $property->getFieldValue();

	$is_builtin = isset($builtins[$key]);

	$delete_uri = id(new PhutilURI($delete_base))
	->setQueryParams(
	array(
	'key' => $key,
	'objectPHID' => $object->getPHID(),
	));

	$edit_uri = id(new PhutilURI($edit_base))
	->setQueryParams(
	array(
	'key' => $key,
	'objectPHID' => $object->getPHID(),
	));

	$delete = javelin_tag(
	'a',
	array(
	'class' => ($can_edit
	? 'button grey small'
	: 'button grey small disabled'),
	'sigil' => 'workflow',
	'href' => $delete_uri,
	),
	$is_builtin ? pht('Reset') : pht('Delete'));

	$default = idx($defaults, $key);
	$is_default = ($default !== null && $default === $value);

	$display_value = PhabricatorConfigJSON::prettyPrintJSON($value);
	if ($is_default) {
	$display_value = phutil_tag(
	'span',
	array(
	'class' => 'almanac-default-property-value',
	),
	$display_value);
	}

	$display_key = $key;
	if ($can_edit) {
	$display_key = javelin_tag(
	'a',
	array(
	'href' => $edit_uri,
	'sigil' => 'workflow',
	),
	$display_key);
	}

	$rows[] = array(
	($is_builtin ? $icon_builtin : $icon_custom),
	$display_key,
	$display_value,
	$delete,
	);
	}

	$table = id(new AphrontTableView($rows))
	->setNoDataString(pht('No properties.'))
	->setHeaders(
	array(
	null,
	pht('Name'),
	pht('Value'),
	null,
	))
	->setColumnClasses(
	array(
	null,
	null,
	'wide',
	'action',
	));

	$phid = $object->getPHID();
	$add_uri = id(new PhutilURI($edit_base))
	->setQueryParam('objectPHID', $object->getPHID());

	$can_edit = PhabricatorPolicyFilter::hasCapability(
	$viewer,
	$object,
	PhabricatorPolicyCapability::CAN_EDIT);

	$add_button = id(new PHUIButtonView())
	->setTag('a')
	->setHref($add_uri)
	->setWorkflow(true)
	->setDisabled(!$can_edit)
	->setText(pht('Add Property'))
	->setIcon('fa-plus');

	$header = id(new PHUIHeaderView())
	->setHeader(pht('Properties'))
	->addActionLink($add_button);

	return id(new PHUIObjectBoxView())
	->setHeader($header)
	->setBackground(PHUIObjectBoxView::BLUE_PROPERTY)
	->setTable($table);
	}

	protected function addClusterMessage(
	$positive,
	$negative) {

	$can_manage = $this->hasApplicationCapability(
	AlmanacManageClusterServicesCapability::CAPABILITY);

	$doc_link = phutil_tag(
	'a',
	array(
	'href' => PhabricatorEnv::getDoclink(
	- 'User Guide: Phabricator Clusters'),
	+ 'Clustering Introduction'),
	'target' => '_blank',
	),
	pht('Learn More'));

	if ($can_manage) {
	$severity = PHUIInfoView::SEVERITY_NOTICE;
	$message = $positive;
	} else {
	$severity = PHUIInfoView::SEVERITY_WARNING;
	$message = $negative;
	}

	$icon = id(new PHUIIconView())
	->setIcon('fa-sitemap');

	return id(new PHUIInfoView())
	->setSeverity($severity)
	->setErrors(
	array(
	array($icon, ' ', $message, ' ', $doc_link),
	));

	}

	protected function getPropertyDeleteURI($object) {
	return null;
	}

	protected function getPropertyUpdateURI($object) {
	return null;
	}

	}
	diff --git a/src/docs/user/cluster/cluster.diviner b/src/docs/user/cluster/cluster.diviner
	index a05381af92..24f4261329 100644
	--- a/src/docs/user/cluster/cluster.diviner
	+++ b/src/docs/user/cluster/cluster.diviner
	@@ -1,57 +1,181 @@
	@title Clustering Introduction
	@group cluster

	Guide to configuring Phabricator across multiple hosts for availability and
	performance.

	Overview
	========

	WARNING: This feature is a very early prototype; the features this document
	describes are mostly speculative fantasy.

	Phabricator can be configured to run on mulitple hosts with redundant services
	to improve its availability and scalability, and make disaster recovery much
	easier.

	Clustering is more complex to setup and maintain than running everything on a
	single host, but greatly reduces the cost of recovering from hardware and
	network failures.

	Each Phabricator service has an array of clustering options that can be
	configured independently. Configuring a cluster is inherently complex, and this
	is an advanced feature aimed at installs with large userbases and experienced
	operations personnel who need this high degree of flexibility.

	The remainder of this document summarizes how to add redundancy to each
	service and where your efforts are likely to have the greatest impact.

	+For additional guidance on setting up a cluster, see "Overlaying Services"
	+and "Cluster Recipes" at the bottom of this document.
	+

	Cluster: Databases
	=================

	Configuring multiple database hosts is moderately complex, but normally has the
	highest impact on availability and resistance to data loss. This is usually the
	most important service to make redundant if your focus is on availability and
	disaster recovery.

	Configuring replicas allows Phabricator to run in read-only mode if you lose
	the master, and to quickly promote the replica as a replacement.

	For details, see @{article:Cluster: Databases}.


	Cluster: Repositories
	=====================

	-Configuring multiple repository hosts is complex.
	+Configuring multiple repository hosts is complex, but is required before you
	+can add multiple daemon or web hosts.

	Repository replicas are important for availability if you host repositories
	on Phabricator, but less important if you host repositories elsewhere
	(instead, you should focus on making that service more available).

	The distributed nature of Git and Mercurial tend to mean that they are
	naturally somewhat resistant to data loss: every clone of a repository includes
	the entire history.

	For details, see @{article:Cluster: Repositories}.
	+
	+
	+Cluster: Daemons
	+================
	+
	+Configuring multiple daemon hosts is straightforward, but you must configure
	+repositories first.
	+
	+With daemons running on multiple hosts, you can transparently survive the loss
	+of any subset of hosts without an interruption to daemon services, as long as
	+at least one host remains alive. Daemons are stateless, so spreading daemons
	+across multiple hosts provides no resistance to data loss.
	+
	+For details, see @{article:Cluster: Daemons}.
	+
	+
	+Cluster: Web Servers
	+====================
	+
	+Configuring multiple web hosts is straightforward, but you must configure
	+repositories first.
	+
	+With multiple web hosts, you can transparently survive the loss of any subset
	+of hosts as long as at least one host remains alive. Web hosts are stateless,
	+so putting multiple hosts in service provides no resistance to data loss.
	+
	+For details, see @{article:Cluster: Web Servers}.
	+
	+
	+Overlaying Services
	+===================
	+
	+Although hosts can run a single dedicated service type, certain groups of
	+services work well together. Phabricator clusters usually do not need to be
	+very large, so deploying a small number of hosts with multiple services is a
	+good place to start.
	+
	+In planning a cluster, consider these blended host types:
	+
	+Everything: Run HTTP, SSH, MySQL, repositories and daemons on a single
	+host. This is the starting point for single-node setups, and usually also the
	+best configuration when adding the second node.
	+
	+Everything Except Databases: Run HTTP, SSH, repositories and daemons on one
	+host, and MySQL on a different host. MySQL uses many of the same resources that
	+other services use. It's also simpler to separate than other services, and
	+tends to benefit the most from dedicated hardware.
	+
	+Just Databases: Separating MySQL onto dedicated nodes
	+
	+Database nodes tend to benefit the most from
	+
	+Repositories and Daemons: Run repositories and daemons on the same host.
	+Repository hosts //must// run daemons, and it normally makes sense to
	+completely overlay repositories and daemons. These services tend to use
	+different resources (repositories are heavier on I/O and lighter on CPU/RAM;
	+daemons are heavier on CPU/RAM and lighter on I/O).
	+
	+Repositories and daemons are also both less latency sensitive than other
	+service types, so there's a wider margin of error for underprovisioning them
	+before performance is noticably affected.
	+
	+These nodes tend to use system resources in a balanced way. Individual nodes
	+in this class do not need to be particularly powerful.
	+
	+Frontend Servers: Run HTTP and SSH on the same host. These are easy to set
	+up, stateless, and you can scale the pool up or down easily to meet demand.
	+Routing both types of ingress traffic through the same initial tier can
	+simplify load balancing.
	+
	+These nodes tend to need relatively little RAM.
	+
	+
	+Cluster Recipes
	+===============
	+
	+This section provides some guidance on reasonable ways to scale up a cluster.
	+
	+The smallest possible cluster is two hosts. Run everything (web, ssh,
	+database, repositories, and daemons) on each host. One host will serve as the
	+master; the other will serve as a replica.
	+
	+Ideally, you should physically separate these hosts to reduce the chance that a
	+natural disaster or infrastructure disruption could disable or destroy both
	+hosts at the same time.
	+
	+From here, you can choose how you expand the cluster.
	+
	+To improve scalability and performance, separate loaded services onto
	+dedicated hosts and then add more hosts of that type to increase capacity. If
	+you have a two-node cluster, the best way to improve scalability by adding one
	+host is likely to separate the master database onto its own host.
	+
	+Note that increasing scale may //decrease// availability by leaving you with
	+too little capacity after a failure. If you have three hosts handling traffic
	+and one datacenter fails, too much traffic may be sent to the single remaining
	+host in the surviving datacenter. You can hedge against this by mirroring new
	+hosts in other datacenters (for example, also separate the replica database
	+onto its own host).
	+
	+After separating databases, separating repository + daemon nodes is likely
	+the next step.
	+
	+To improve availability, add another copy of everything you run in one
	+datacenter to a new datacenter. For example, if you have a two-node cluster,
	+the best way to improve availability is to run everything on a third host in a
	+third datacenter. If you have a 6-node cluster with a web node, a database node
	+and a repo + daemon node in two datacenters, add 3 more nodes to create a copy
	+of each node in a third datacenter.
	+
	+You can continue adding hosts until you run out of hosts.
	+
	+
	+Next Steps
	+==========
	+
	+Continue by:
	+
	+ - learning how Phacility configures and operates a large, multi-tenant
	+ production cluster in ((cluster)).
	diff --git a/src/docs/user/cluster/cluster_daemons.diviner b/src/docs/user/cluster/cluster_daemons.diviner
	new file mode 100644
	index 0000000000..19e7e37f6d
	--- /dev/null
	+++ b/src/docs/user/cluster/cluster_daemons.diviner
	@@ -0,0 +1,59 @@
	+@title Cluster: Daemons
	+@group intro
	+
	+Configuring Phabricator to use multiple daemon hosts.
	+
	+Overview
	+========
	+
	+WARNING: This feature is a very early prototype; the features this document
	+describes are mostly speculative fantasy.
	+
	+You can run daemons on multiple hosts. The advantages of doing this are:
	+
	+ - you can completely survive the loss of multiple daemon hosts; and
	+ - worker queue throughput may improve.
	+
	+This configuration is simple, but you must configure repositories first. For
	+details, see @{article:Cluster: Repositories}.
	+
	+Since repository hosts must run daemons anyway, you usually do not need to do
	+any additional work and can skip this entirely.
	+
	+
	+Adding Daemon Hosts
	+===================
	+
	+After configuring repositories for clustering, launch daemons on every
	+repository host according to the documentation in
	+@{article:Cluster: Repositories}. These daemons are necessary: repositories
	+will not fetch, update, or synchronize properly without them.
	+
	+If your repository clustering is redundant (you have at least two repsoitory
	+hosts), these daemons are also likely to be sufficient in most cases. If you
	+want to launch additional hosts anyway (for example, to increase queue capacity
	+for unusual workloads), see "Dedicated Daemon Hosts" below.
	+
	+
	+Dedicated Daemon Hosts
	+======================
	+
	+You can launch additional daemon hosts without any special configuration.
	+Daemon hosts must be able to reach other hosts on the network, but do not need
	+to run any services (like HTTP or SSH). Simply deploy the Phabricator software
	+and configuration and start the daemons.
	+
	+Normally, there is little reason to deploy dedicated daemon hosts. They can
	+improve queue capacity, but generally do not improve availability or increase
	+resistance to data loss on their own. Instead, consider deploying more
	+repository hosts: repository hosts run daemons, so this will increase queue
	+capacity but also improve repository availability and cluster resistance.
	+
	+
	+Next Steps
	+==========
	+
	+Continue by:
	+
	+ - returning to @{article:Clustering Introduction}; or
	+ - configuring repositories first with @{article:Cluster: Repositories}.
	diff --git a/src/docs/user/cluster/cluster_webservers.diviner b/src/docs/user/cluster/cluster_webservers.diviner
	new file mode 100644
	index 0000000000..a1ebc9491b
	--- /dev/null
	+++ b/src/docs/user/cluster/cluster_webservers.diviner
	@@ -0,0 +1,42 @@
	+@title Cluster: Web Servers
	+@group intro
	+
	+Configuring Phabricator to use multiple web servers.
	+
	+Overview
	+========
	+
	+WARNING: This feature is a very early prototype; the features this document
	+describes are mostly speculative fantasy.
	+
	+You can run Phabricator on multiple web servers. The advantages of doing this
	+are:
	+
	+ - you can completely survive the loss of multiple web hosts; and
	+ - performance and capacity may improve.
	+
	+This configuration is simple, but you must configure repositories first. For
	+details, see @{article:Cluster: Repositories}.
	+
	+
	+Adding Web Hosts
	+================
	+
	+After configuring repositories in cluster mode, you can add more web hosts
	+at any time: simply deploy the Phabricator software and configuration to a
	+host, start the web server, and then add the host to the load balancer pool.
	+
	+Phabricator web servers are stateless, so you can pull them in and out of
	+production freely.
	+
	+You may also want to run SSH services on these hosts, since the service is very
	+similar to HTTP, also stateless, and it may be simpler to load balance the
	+services together.
	+
	+
	+Next Steps
	+==========
	+
	+Continue by:
	+
	+ - returning to @{article:Clustering Introduction}.
	diff --git a/src/docs/user/configuration/cluster.diviner b/src/docs/user/configuration/cluster.diviner
	deleted file mode 100644
	index c11565dc4d..0000000000
	--- a/src/docs/user/configuration/cluster.diviner
	+++ /dev/null
	@@ -1,50 +0,0 @@
	-@title User Guide: Phabricator Clusters
	-@group config
	-
	-Guide on scaling Phabricator across multiple machines.
	-
	-Overview
	-========
	-
	-IMPORTANT: Phabricator clustering is in its infancy and does not work at all
	-yet. This document is mostly a placeholder.
	-
	-IMPORTANT: DO NOT CONFIGURE CLUSTER SERVICES UNLESS YOU HAVE **TWENTY YEARS OF
	-EXPERIENCE WITH PHABRICATOR AND A MINIMUM OF 17 PHABRICATOR PHDs**. YOU
	-WILL BREAK YOUR INSTALL AND BE UNABLE TO REPAIR IT.
	-
	-See also @{article:Almanac User Guide}.
	-
	-
	-Managing Cluster Configuration
	-==============================
	-
	-Cluster configuration is managed primarily from the Almanac application.
	-
	-To define cluster services and create or edit cluster configuration, you must
	-have the Can Manage Cluster Services application permission in Almanac. If
	-you do not have this permission, all cluster services and all connected devices
	-will be locked and not editable.
	-
	-The Can Manage Cluster Services permission is stronger than service and
	-device policies, and overrides them. You can never edit a cluster service if
	-you don't have this permission, even if the Can Edit policy on the service
	-itself is very permissive.
	-
	-
	-Locking Cluster Configuration
	-=============================
	-
	-IMPORTANT: Managing cluster services is dangerous and fragile.
	-
	-If you make a mistake, you can break your install. Because the install is
	-broken, you will be unable to load the web interface in order to repair it.
	-
	-IMPORTANT: Currently, broken clusters must be repaired by manually fixing them
	-in the database. There are no instructions available on how to do this, and no
	-tools to help you. Do not configure cluster services.
	-
	-If an attacker gains access to an account with permission to manage cluster
	-services, they can add devices they control as database servers. These servers
	-will then receive sensitive data and traffic, and allow the attacker to
	-escalate their access and completely compromise an install.
	diff --git a/src/docs/user/configuration/managing_daemons.diviner b/src/docs/user/configuration/managing_daemons.diviner
	index 4382e12c8a..0a732d5836 100644
	--- a/src/docs/user/configuration/managing_daemons.diviner
	+++ b/src/docs/user/configuration/managing_daemons.diviner
	@@ -1,140 +1,131 @@
	@title Managing Daemons with phd
	@group config

	Explains Phabricator daemons and the daemon control program `phd`.

	= Overview =

	Phabricator uses daemons (background processing scripts) to handle a number of
	tasks:

	- tracking repositories, discovering new commits, and importing and parsing
	commits;
	- sending email; and
	- collecting garbage, like old logs and caches.

	Daemons are started and stopped with phd (the Phabricator Daemon
	launcher). Daemons can be monitored via a web console.

	You do not need to run daemons for most parts of Phabricator to work, but some
	features (principally, repository tracking with Diffusion) require them and
	several features will benefit in performance or stability if you configure
	daemons.

	= phd =

	phd is a command-line script (located at `phabricator/bin/phd`). To get
	a list of commands, run `phd help`:

	phabricator/ $ ./bin/phd help
	NAME
	phd - phabricator daemon launcher
	...

	Generally, you will use:

	- phd start to launch all daemons;
	- phd restart to restart all daemons;
	- phd status to get a list of running daemons; and
	- phd stop to stop all daemons.

	If you want finer-grained control, you can use:

	- phd launch to launch individual daemons; and
	- phd debug to debug problems with daemons.

	NOTE: When you upgrade Phabricator or change configuration, you should restart
	the daemons by running `phd restart`.

	= Daemon Console =

	You can view status and debugging information for daemons in the Daemon Console
	via the web interface. Go to `/daemon/` in your install or click
	Daemon Console from "More Stuff".

	The Daemon Console shows a list of all the daemons that have ever launched, and
	allows you to view log information for them. If you have issues with daemons,
	you may be able to find error information that will help you resolve the problem
	in the console.

	NOTE: The easiest way to figure out what's wrong with a daemon is usually to use
	phd debug to launch it instead of phd start. This will run it without
	daemonizing it, so you can see output in your console.

	= Available Daemons =

	You can get a list of launchable daemons with phd list:

	- libphutil test daemons are not generally useful unless you are
	developing daemon infrastructure or debugging a daemon problem;
	- PhabricatorTaskmasterDaemon performs work from a task queue;
	- PhabricatorRepositoryPullLocalDaemon daemons track repositories, for
	more information see @{article:Diffusion User Guide}; and
	- PhabricatorTriggerDaemon schedules event triggers and cleans up old
	logs and caches.

	= Debugging and Tuning =

	In most cases, phd start handles launching all the daemons you need.
	However, you may want to use more granular daemon controls to debug daemons,
	launch custom daemons, or launch special daemons like the IRC bot.

	To debug a daemon, use `phd debug`:

	phabricator/bin/ $ ./phd debug <daemon>

	You can pass arguments like this (normal arguments are passed to the daemon
	control mechanism, not to the daemon itself):

	phabricator/bin/ $ ./phd debug <daemon> -- --flavor apple

	In debug mode, daemons do not daemonize, and they print additional debugging
	output to the console. This should make it easier to debug problems. You can
	terminate the daemon with `^C`.

	To launch a nonstandard daemon, use `phd launch`:

	phabricator/bin/ $ ./phd launch <daemon>

	This daemon will daemonize and run normally.

	== General Tips ==

	- You can set the maximum number of taskmasters that will run at once
	by adjusting `phd.taskmasters`. If you have a task backlog, try increasing
	it.
	- When you `phd launch` or `phd debug` a daemon, you can type any unique
	substring of its name, so `phd launch pull` will work correctly.
	- `phd stop` and `phd restart` stop all of the daemons on the machine, not
	just those started with `phd start`. If you're writing a restart script,
	have it launch any custom daemons explicitly after `phd restart`.
	- You can write your own daemons and manage them with `phd` by extending
	@{class:PhabricatorDaemon}. See @{article@phabcontrib:Adding New Classes}.
	- See @{article:Diffusion User Guide} for details about tuning the repository
	daemon.

	-== Multiple Machines ==

	-If you have multiple machines, you should use `phd launch` to tweak which
	-daemons launch, and split daemons across machines like this:
	+Multiple Hosts
	+==============

	- - `PhabricatorRepositoryPullLocalDaemon`: Run one copy on any machine.
	- On each web frontend which is not running a normal copy, run a copy
	- with the `--no-discovery` flag.
	- - `PhabricatorTriggerDaemon`: Run one copy on any machine.
	- - `PhabricatorTaskmasterDaemon`: Run as many copies as you need to keep
	- tasks from backing up. You can run them all on one machine or split them
	- across machines.
	+For information about running daemons on multiple hosts, see
	+@{article:Cluster: Daemons}.

	-A gratuitously wasteful install might have a dedicated daemon machine which
	-runs `phd start` with a large pool of taskmasters set in the config, and then
	-runs `phd launch PhabricatorRepositoryPullLocalDaemon -- --no-discovery` on each
	-web server. This is grossly excessive in normal cases.

	-= Next Steps =
	+Next Steps
	+==========

	Continue by:

	- learning about the repository daemon with @{article:Diffusion User Guide};
	or
	- writing your own daemons with @{article@phabcontrib:Adding New Classes}.

File Metadata

Mime Type: text/x-diff
Expires: Mon, Jul 28, 11:45 PM (1 w, 4 d ago)
Storage Engine: blob
Storage Format: Raw Data
Storage Handle: 187638
Default Alt Text: (28 KB)

No OneTemporaryActions

View Options

File Metadata

Event Timeline

No OneTemporary
Actions