mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-29 10:12:41 +01:00
9e0a299b06
Summary: Ref T1670. Prepare for the overseers to talk directly to the database instead of using Conduit. See T1670 for discussion. This shouldn't impact anything, except it has a very small chance of destabilizing the overseers. Test Plan: Ran `phd launch`, `phd debug`, `phd start`. Ran with `--trace-memory` and verified elevated but mostly steady memory usage (8MB / overseer). This climbed by 0.05KB / sec (4MB / day) but the source of the leaks seems to be the cURL calls we're making over Conduit so this will actually fix that. Disabling `--conduit-uri` reported steady memory usage. I wasn't able to identify anything leaking within code we control. This may be something like a dynamic but capped buffer in cURL, since we haven't seen any issues in the wild. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6534
29 lines
855 B
PHP
Executable file
29 lines
855 B
PHP
Executable file
#!/usr/bin/env php
|
|
<?php
|
|
|
|
$root = dirname(dirname(dirname(__FILE__)));
|
|
require_once $root.'/scripts/__init_script__.php';
|
|
|
|
PhabricatorDaemonManagementWorkflow::requireExtensions();
|
|
|
|
$args = new PhutilArgumentParser($argv);
|
|
$args->setTagline('manage daemons');
|
|
$args->setSynopsis(<<<EOSYNOPSIS
|
|
**phd** __command__ [__options__]
|
|
Manage Phabricator daeons.
|
|
|
|
EOSYNOPSIS
|
|
);
|
|
$args->parseStandardArguments();
|
|
$workflows = array(
|
|
new PhabricatorDaemonManagementListWorkflow(),
|
|
new PhabricatorDaemonManagementStatusWorkflow(),
|
|
new PhabricatorDaemonManagementStartWorkflow(),
|
|
new PhabricatorDaemonManagementStopWorkflow(),
|
|
new PhabricatorDaemonManagementRestartWorkflow(),
|
|
new PhabricatorDaemonManagementLaunchWorkflow(),
|
|
new PhabricatorDaemonManagementDebugWorkflow(),
|
|
new PhutilHelpArgumentWorkflow(),
|
|
);
|
|
|
|
$args->parseWorkflows($workflows);
|