Configuring the number of Taskmaster daemons


I’m trying to reduce the number of Taskmaster daemons on our install. When I look at /config/edit/phd.taskmasters/, it says:

  • Database: 10
  • Local Config: (No Value Configured)
  • Global Default: 4

The database row is highlighted, so I assume this is the one that is actually used. I am unable to change the database value, because it is a locked configuration option. Setting a local config using the bin/config tool does not seem to override the database config.

What is the recommended way to set this configuration?


Some older config was previously configurable via the web UI, but became locked and can only be configured via the CLI now.

  • Use bin/config delete --database phd.taskmasters to remove the database value.
  • Then, use bin/config set phd.taskmasters <value> to set a new value.

Usually, config was locked (changed from UI-editable to CLI-editable-only) because:

  • we identified some sort of security issue or attack that an administrator could use to escalate their access by editing the config; or
  • it became possible (or we identified a way) to lock yourself out of Phabricator by changing the config value.

For example, administrators can’t normally log in as other users, but if they could edit cluster.mailers from the web UI, they could send password reset email to a mail server they control, then take over user accounts. So, cluster.mailers is not editable from the web UI.

In this case, the option was locked a while ago in because it does not actually take effect until you restart the daemons, so you needed to have CLI access anyway. It’s also mildly possible to do undesirable things by setting it to a huge number.

When you bin/config set a configuration value that also has a database value, we should probably warn you that your setting is not the strongest setting, and provide a hint about how to remove the database value.

Ideally, I’d like to change Phabricator’s behavior so that it does not read database values for locked config. The current behavior creates a risk that an attacker who finds a SQL injection hole or a bug in Config can use it to modify dangerous Config values (like cluster.mailers) and escalate their attack. It would be safer to refuse to read locked config from the database, not just refuse to write new values to the database.

However, this change would potentially be disruptive, and probably needs to happen in two parts: first, a new warning that the value exists, with instructions to bin/config delete it. Then, some time later, after installs have had a chance to upgrade, an actual change to stop reading these configuration values.




See for a new setup warning.

See also for more details. In about 24 hours, once D20159 lands and the documentation regenerates, that will include some more information about this particular state.

closed #5