Page tree
Skip to end of metadata
Go to start of metadata

Overview

System properties are Java virtual machine level options that allow you to configure advanced pulse™ variables. They serve a similar purpose to environment variables at the operating system level.

Setting System Properties

There are multiple ways to set system properties, depending on how you launch pulse™ and whether you want the properties to persist.

system.properties

The easiest way to set a property that will persist for all invocations of pulse™ is to use the file:

$PULSE_DATA/config/system.properties

where $PULSE_DATA is the location of the data directory. You may need to create the file if it does not exist. The file uses the standard Java property file format, with properties specified as <key>=<value> pairs, one per line. Special characters such as backslashes must be escaped with a backslash.

This file is loaded at startup time. If you make an edit to the file while pulse™ is running, it will not take effect until you restart pulse™. A handful of properties cannot be set via this file as they are used before the file can be loaded: in particular properties relating to the internal web server (Jetty).

JAVA_OPTS

If you run pulse™ using the pulse start command (see Server Commands), you can specify JVM options using the environment variable JAVA_OPTS. By default, this variable has the following value:

JAVA_OPTS=-Xmx1024m -XX:MaxPermSize=128m

This value configures the JVM to allow pulse™ to use up to 1GB of memory, and 128MB of permgen space. You can add system properties to this value in the form -D<key>=<value>, for example:

JAVA_OPTS=-Xmx1024m -XX:MaxPermSize=128m -Dmy-system-property=property-value

Properties set in this way only last for the invocation of pulse™. To use the properties for all invocations, you can set the environment variable at the system level, for example:

  • In the pulse user's profile,
  • In /etc/zutubi-pulse (or /etc/zutubi-pulse-agent) when running via systemd.
  • By editing /etc/init/pulse.conf and then running initctl reload-configuration when running via Upstart.

If you're unsure whether your environment or system property changes are taking effect, you can check the server > info tab in the Pulse UI to see all environment and system variables.

SysV-style init

If you are running pulse™ via the SysV-style init script then JAVA_OPTS is not supported. Instead, the script uses the PULSE_OPTS variable for passing extra arguments to the jsvc wrapper. Common options, including all -D and -X flags, are passed through to the JVM by jsvc.

Windows Service

If you are running pulse™ as a service on Windows, you can specify JVM parameters using commons daemon service GUI. This can be launched from the start menu or by running $PULSE_HOME/bin/PulseServerw.exe directly ($PULSE_HOME/bin/PulseAgentw.exe on agents). JVM options are specified on the "Java" tab.

Available Properties

Note that some server properties are only configured on the master (although they may or may not affect the agents). Properties that need to be set individually on each agent are indicated in the "Configured On" column below. There are also properties that are only configured on a developer tools installation.

Property

Description

Configured On

Default

Example

pulse.agent.upgrade.status.timeout

Maximum number of seconds to wait between status events before timing out an agent upgrade.

master only

600

1200

pulse.agent.upgrade.reboot.timeout

Maximum number of seconds to wait between receiving the reboot status and a successful ping before timing out an agent upgrade.

master only

600

1200

pulse.agent.upgrade.reboot.ping.interval

The time, in seconds, between agent pings when waiting for an upgraded agent to reboot.

master only

5

8

pulse.archive.command

The external command to run to create zip archives if external archiving is turned on. See CB - Using External Archive Tools for details.

master and agents

zip -qry ${zipfile} ${files}

myzip -o ${zipfile} ${files}

pulse.debug.result.collection

If set to true, debugging of the collection of recipe results via zips is enabled. This outputs information to the logs and retains zip files for inspection. New in 2.5.19.

master and agents

false

true

pulse.delete.outside.data

Normally, pulse™ will not clean up directories outside of the data directory, even if project's have been configured to use such directories. Set this property to true to disable this defence. Note: prior to pulse™ 2.7.4 this property was also used on agents, but it has been superseded by an option in agent storage configuration.

master only

false

true

pulse.disable.browse.consistency

Set to true to disable transactions that are used to ensure a consistent view on the browse and dashboard views. This is an experimental performance tuning feature. New in 2.6.16.

master only

 

true

pulse.echo.passwords

If set to any value, pulse™ will echo passwords when they are entered via the command line. Typically only used for debugging.

tools only

 

true

pulse.email.queue.capacity

The maximum number of emails pulse™ will queue waiting for delivery. If this limit is exceeded emails will start to be dropped.

master only

4096

8192

pulse.enable.request.logging

If set to true, pulse™ will log web UI requests in NCSA format to files in the $PULSE_HOME/logs directory. Note that these logs can be large if there are many users (see also pulse.extended.request.logging and pulse.request.logging.retain.days).

master only

false

true

pulse.extended.request.logging

If true and request logging is enabled, requests will be logged in extended NCSA format.

master only

false

true

pulse.feature.limit

If non-zero, limits the number of each type (error, warning, etc) of message that will appear in result notification messages (e.g. emails).

master only

100

0 (to disable)

pulse.fs.rmdir.command

If set, specifies the external command to run to remove a directory and its contents. The property ${dir} will be replaced with the absolute path of the directory. New in 2.5.18.

master and agents

 

cmd /c rmdir /s /q ${dir}

pulse.fs.robust.delay.millis

Delay in milliseconds between retries of failed file system operations (renames and deletes). New in 2.3.3.

master and agents

100

200

pulse.fs.robust.retries

Maximum number of retries of failed file system operations (renames and deletes). New in 2.3.3.

master and agents

3

5

pulse.hessian.read.timeout

If non-zero, the number of seconds after which to timeout idle connections between master and agents.

master and agents

60

0 (to disable)

pulse.hook.command.directory.whitelist

If set, this is a semicolon-separated list of directories, and only commands within these directories may be run in hook tasks executed on the master. Hook tasks run on agents are not restricted by the whitelist. Hook commands may be specified as absolute or relative to a whitelisted directory, but once resolved and canonicalised their parent directory must be in the whitelist or the hook will fail with an error without attempting to execute the command. New in 2.5.29.

master only

 

/jail/bin;/jail/usr/bin

pulse.jabber.length.limit

The maximum number of bytes to send as the content of a Jabber message. New in 2.5.21.

master only

16384

8192

pulse.jetty.idle.timeout

The number of seconds after which to time out idle connections to the master or from the master to the agents on the receiving end.

master and agents

60

30

pulse.jetty.max.threads

The maximum number of threads to allocate for handling of HTTP requests (made by users of the web UI, remote API and agents to talk to the master).

master only

250

500

pulse.jetty.min.threads

The minimum number of idle threads to keep ready for handling of HTTP requests.

master only

25

50

pulse.notification.test.failure.limit

The maximum number of test failures to show in notifications.

master only

20

100

pulse.output.event.flush.intervalThe maximum time (in milliseconds) to wait for a command output event buffer to fill before just sending the output that has collected. Since 2.6.21.agents only100005000
pulse.output.event.min.sizeThe minimum size (in bytes) of command output events sent from an agent to the master. Agents will buffer at least this much output before sending it over the network (unless the wait is too long). Since 2.6.21.agents51200102400
pulse.p4.changelist.file.limitMaximum number of files to include in changelists loaded from Perforce. Note that changelists that hit this limit will not be filtered using included/excluded paths (as the full list of paths in the change is not known to pulse™). Since 2.7.14.master onlyNot set (unlimited)10000

pulse.p4.client.prefix

The prefix used for all Perforce clients created by pulse™.

master and agents

pulse-

my-prefix-

pulse.p4.client.suffix

The suffix used to ensure a unique name for Perforce clients created by pulse™. If pulse™ needs to concurrently access Perforce for the same project (or build stage) on the same host then it needs to ensure the access uses different clients. Where necessary this string is appended to client names to ensure they are unique (it may be appended multiple times). Since 2.7.18.

master and agents

$

_

pulse.p4.client.command.timeout

Maximum running time, in seconds, for a Perforce client name generation command before that command is killed.

master and agents

300

600

pulse.p4.command

Path (or name if in the PATH) of the command to execute as the Perforce command-line client.

master and agents

p4

/usr/local/bin/p4

pulse.p4.command.<sub-command>

Path (or name if in the PATH) of the command to execute as the Perforce command-line client for the particular Perforce sub-command. This allows overriding of the command-line for a single Perforce sub-command, e.g. sync by setting pulse.p4.command.sync.

master and agents

 

mysync

pulse.p4.inactivity.timeout

Maximum period of inactivity (i.e. no output detected), in seconds, for a p4 child process before that process is killed. Note: as of 2.1.19 using the corresponding field in the Perforce configuration is preferred – this property is only used for projects that have that field set to zero.

master and agents

300

600

pulse.p4.skip.flush

Superceded by the ability to customise this command via the p4 resource.

master and agents

false

true

pulse.recipe.dispatch.pool.size

Number of threads to use for dispatching recipe requests to agents.

master only

5

10

pulse.request.logging.retain.days

If request logging is enabled, the number of days request logs will be retained for (older logs are deleted).

master only

30

10

pulse.retain.environment.case

If set to any value, environment variables will not be normalised to upper case when converted to pulse™ file properties.

master and agents

 

true

pulse.suppress.bootstrap.output

If set to true, output from the bootstrap is not captured to the build logs.

master and agents

false

true

pulse.suppressed.environment.variables

A space-separated list of environment variables that should not have their values recorded in logs etc.

master and agents

P4PASSWD

SECRET1 SECRET2

pulse.test.failure.limit

The maximum number of failed test cases to show in build summaries in the UI.

master only

100

50

pulse.unarchive.command

The external command to run to unpack zip archives if external archiving is turned on. See CB - Using External Archive Tools for details.

master and agents

unzip -qq ${zipfile}

myunzip ${zipfile}

pulse.use.external.archiving

If true, external zip/unzip tools will be used where available to create and extract archives. See CB - Using External Archive Tools for details.

master and agents

true

false

pulse.use.external.copy

If true, forces pulse™ to use the cp command when copying files. This property only needs to be explicitly set to true on Windows, it will default to true on other platforms where cp is found. For external copying to work, there must be a GNU-compatible cp command in the PATH of pulse™. For large copies, this can improve copy performance.

master and agents

true where cp is in the PATH, except on Windows

true

pulse.xmlrpc.max.threadsIf set, the maximum number of concurrent clients that will be serviced by the XML-RPC Remote API. If the limit is reached new clients are rejected with 500 errors until an RPC worker thread becomes free. New in 2.7.7.master only100200
  • No labels