Repository Configuration¶

Overview¶

There are a wide variety of Repository options that can be configured. These options can be modified at any time from the Deadline Monitor while in Super User Mode by selecting Tools -> Configure Repository Options. If you want to restore all the Repository Options to their defaults, simply click the Reset Settings button.

Note that long-running applications like the Launcher, Slave, and Pulse only update these settings every 10 minutes, so after making changes, it can take up to 10 minutes for all machines to recognize them. You can restart these applications to have them recognize the changes immediately.

Client Setup¶

These settings affect the Deadline Client installed on each machine.

• Remote Administration: Enabling Remote Administration allows the Deadline Clients to be controlled remotely from the Monitor running on another machine. Note that this can be a security risk if you are not behind a firewall.
• Use Event Timeouts: Enabling Event Timeouts will cause event triggers to time out if all Event Plugins do not finish in the specified amount of time.
• Application Plugins Enabled By Default: Enabling this setting will cause new Application Plugins added to the Repository to be enabled. It is recommended that this setting be turned off for security reasons.

Monitor Settings¶

These settings affect the Deadline Monitor application on each machine.

Monitor Layouts¶

Existing Monitor layouts can be added here. These layouts can be assigned to User Groups as a user’s default layout. If the Pinned option is enabled, they can also be chosen from the Pinned Layouts menu in the Monitor. The order of the layouts here will be the same in the Pinned Layouts menu.

To add a new layout, simply press the Add button, and then choose an existing Monitor layout file, or use the current Monitor’s layout. Note that Monitor layout files can be saved from the Monitor by selecting View -> Save Layout.

Update Settings¶

Enable Manual Refreshing

If your Auto Refreshing Intervals are set to longer intervals, manual refreshing in the Monitor can be enabled to allow users to get the most up to date data immediately. To prevent users from abusing manual refreshing, a minimum interval between manual refreshes can be configured.

Sorting and Filtering

For farms that have a large number of jobs (10,000+) or slaves (1000+), disabling Automatic Sorting and Filtering in the lists in the Monitor can improve the Monitor’s overall performance. This option in the Repository Options can be used to disable Automatic Sorting and Filtering by default, and users can enable it later in their Monitors if desired.

Slave Settings¶

These settings affect the Deadline Slave application on each machine.

Slave Settings¶

General

• Limit the number of characters per line for standard output handling: Lines of standard output that are longer than the specified limit will be ignored by the Slave’s stdout handling.
• Delete Offline/Stalled Slaves from the Repository after this many days: Slaves that are Offline or Stalled will be removed from the Repository after this many days.
• Gather System Resources (CPU and RAM) When Rendering Tasks On Linux/Mac: If enabled, the Slave will collect CPU and RAM usage for a task while it is rendering. We have seen cases where this can cause the Slave to crash on Linux or Mac, so you should only disable this feature if you run into this problem.
• Use fully qualified domain name (FQDN) for Machine Name instead of host name: If enabled, the Slave will try to use the machine’s fully qualified domain name (FQDN) when setting its Machine Name instead of using the machine’s host name. The FQDN will then be used for Remote Control, which can be useful if the remote machine name isn’t recognized in the local network. If the Slave can’t resolve the FQDN, it will just use the host name instead.
• Use Slave’s IP Address for Remote Control: If enabled, the Slave’s IP address will be used for remote control instead of trying to resolve the Slave’s host name.
• Exclude Jobs in the ‘none’ Pool: Prevents the Slaves from picking up jobs that have been submitted to the ‘none’ pool.
• Exclude Jobs in the ‘none’ Group: Prevents the Slaves from picking up jobs that have been submitted to the ‘none’ group.
• Disable Plugin Sandboxing: If Plugin Sandboxing is disabled, each plugin will run in the Slave’s context, rather than in its own clean environment. This setting is mostly used for debugging purposes.

Wait Times

• Number of Minutes Before An Unresponsive Slave is Marked as Stalled: If a Slave has not provided a status update in this amount of time, it will be marked as stalled.
• Number of Seconds To Wait For a Response When Connecting to Pulse: The number of seconds a Slave that is connected to Pulse will wait for Pulse to respond when querying for a job.
• Number of Seconds Between Thermal Shutdown Checks if Pulse is Offline: The number of seconds between thermal shutdown checks. The Slave only does this check if Pulse is not running.

Extra Properties¶

Extra arbitrary properties can be set for slaves, and these properties can be given user friendly names so that they can easily be identified and used to filter and sort slaves in the Monitor.

Throttling¶

Throttling can be used to limit the number of slave applications that are copying over the job files at the same time. This can help network performance if large scene files are being submitted with the jobs. Note that a Slave only copies over the job files when it starts up a new job. When it goes to render subsequent tasks for the same job, it will not be affected by the throttling feature.

• Enable Throttling: Allow throttling to occur.
• Maximum Number of Slaves That Can Copy Job Files at The Same Time: The maximum number of Slaves that can copy a scene file at the same time.
• The Interval a Slave Waits Between Updates To See If It Can Start Copying Job Files: The amount of time (in seconds) a Slave will wait to perform throttle checks and updates.
• Throttle Update Timeout Multiplier (based on the Slave Interval): The interval a slave waits between updates is multiplied by this value to determine the timeout value.

Performance Settings¶

These settings are used to influence the performance of Deadline by modifying update intervals.

The auto adjust option will try to choose the best interval settings based on the number of Slaves in your farm. These should act as a good base that you can modify later as necessary. Press the Auto Adjust button to bring up the interval settings. Note that this will show you what your current settings are, and what they’ll be changed to based on the number of slaves you entered.

Monitor Intervals

The Monitor periodically polls the Database for up-to-date information to populate its various panels. These intervals each control how often the Monitor checks for updates on particular items.

• Number of seconds Between Job Updates: This controls how often the Monitor reads in new job updates.
• Number of seconds Between Slave Updates: This controls how often the Monitor reads in new slave updates.
• Number of seconds Between Pulse Updates: This controls how often the Monitor reads in new pulse updates.
• Number of seconds Between Limit Updates: This controls how often the Monitor reads in new limit updates.
• Number of seconds Between Settings Updates: This controls how often the Settings such as groups, pools and users are updated.
• Number of seconds Between Cloud Updates: This controls how often the Monitor updates the Cloud Panel.
• Number of seconds Between Balancer Updates: This controls how often the Monitor reads in new Balancer updates.
• Number of seconds Between Proxy Server Updates: This controls how often the Monitor updates the Proxy Server Panel.

Slave Intervals

These intervals control how often the Slave updates its information in the Database and how often it polls the Database for available tasks.

• Number of seconds Between Slave Information Updates: This controls how often the Slave updates the information that’s shown in the Slave list in the Monitor. In addition to these regular updates, the Slave also updates its information when it changes status and before shutting down.
• Number of seconds Between Queries For New Tasks While the Slave is Rendering: The number of seconds a Slave will wait after it finishes a task before moving on to another. This delay is not applied when the Slave is idle.
• Multiplier to determine seconds between queries while the Slave is Idle: This multiplier is applied to the number of slaves and will determine how long a slave will wait between polls to the Repository for tasks when it is idle. This is used to regulate network traffic by ensuring that the more idle Slaves there are, the less frequently they each poll the Repository. The value of this multiplier controls the strength of this effect.
• Maximum number of seconds between Job queries while the Slave is Idle: The maximum number of seconds a slave will wait between polls to the Repository for tasks when it is idle.
• Minimum number of seconds between Job queries when the Slave is Idle: The minimum number of seconds a slave will wait between polls to the Repository for tasks when it is idle.

Event Intervals

The time interval between checks if the Event Plugins need to be updated. The Event Plugins are marked as needing to be updated if any of the Event files are modified.

Pulse Settings¶

These settings control how the Slaves connect to Pulse, and are also used by the Slave to determine if Pulse is running.

General¶

• Maximum Incoming Connections: The maximum number of Slaves that can connect to Pulse at any given time.
• Connection Timeout (in milliseconds): The number of milliseconds messages to and from Pulse have to complete before they timeout.
• Maximum Connection Attempts: The maximum number of times a Slave will attempt to connect to Pulse before giving up.
• Stalled Pulse Threshold (in minutes): Deadline determines if a Pulse has stalled by checking the last time that the Pulse has provided a status update. If a Pulse has not updated its state in the specified amount of time, it will be marked as Stalled.
• Use Pulse’s IP Address When Slaves Connect To Pulse and For Remote Control: If enabled, the Pulse’s IP address will be used when the slaves connect to pulse, and for remote control, instead of trying to resolve the Pulse’s host name.

Power Management¶

• Power Management Check Interval: How often Pulse performs Power Management operations.

Balancer Settings¶

These settings control general settings for the Balancer.

• Balancer Update Interval: How often the Balancer performs a balancing cycle.
• Stalled Balancer Threshold (in minutes): Deadline determines if a Balancer has stalled by checking the last time that the Balancer has provided a status update. If a Balancer has not updated its state in the specified amount of time, it will be marked as Stalled.
• Current Algorithm Logic: The Balancer Plugin to use for determining balancing targets.
• Error Limit: How many cycles the Balancer is allowed to error for before it restarts.
• Global Remote Command Port Override: If enabled, this port will be used by all Balancers for remote commands. Otherwise, the port used will be randomly assigned on each Balancers’ startup.
• Use Balancer’s IP Address for Remote Control: If enabled, the Balancer’s IP address will be used for remote control instead of trying to resolve the Balancer’s host name.
• Enable Group Switching: If there are group mappings that have the same image and hardware types instances will move between groups as needed. If it’s not enabled instances will shutdown and startup like normal.

The settings for the currently selected Algorithm Logic will be shown here as well.

Region Settings¶

This is where you can set up Regions in Deadline. Regions are logical groupings for slaves and users. Cross Platform Rendering and Balancer Settings can be unique to each region. For example a slave that’s in the ‘thinkbox_west’ Region will use the path mapping settings for that Region. The list on the right shows the Cloud Regions and the list on the left shows the general Regions. Regions must have a unique name.’all’ and ‘none’ are reserved names that cannot be used. See Regions for more information.

This section handles all email related settings within the repository.

Primary and Secondary Server¶

Set up a primary SMTP server to send email notifications. You can set up an optional secondary SMTP server for Deadline to use if the primary server is unavailable.

• SMTP Server: The SMTP server used by Deadline to send emails.
• Sender Account: The email account that Deadline will use to send emails from.
• Port: The SMTP port to use.
• Use SSL: The email account from which the notifications will be sent.
• SMTP Server Requires Authentication: Enable if the SMTP server requires a user name and password to authenticate.
• Testing: Send a test email to the specified email address.
• Automatically Generate Email Addresses for New Users: Generates new email address for new users in the form username@postfix, where ‘postfix’ is the value entered in the Email Address Postfix field.

Note that if you have SSL enabled, you may need to configure your Linux and Mac OS X machines for SSL to work. The process for doing this is explained in Mono’s Security Documentation.

If you using Google Mail to send emails (smtp.gmail.com), you will typically use port 25 if SSL is disabled, and port 465 if SSL is enabled. See Google’s documentation on Sending Emails for more information.

• Job Completed: When a job completes, an email will be sent to these email addresses.
• Job Timed Out: When a job times out, an email will be sent to these email addresses.
• Job Error Warning: When a job accumulates a certain number of errors, a warning email will be sent to these email addresses. You can configure the warning limit in the Failure Detection settings.
• Job Failed: When a job fails, an email will be sent to these email addresses.
• Slave Error Warning: When a slave accumulates a certain number of errors in one session, a warning email will be sent to these email addresses. You can configure the warning limit in the Failure Detection settings.
• Stalled Applications: When a stalled Slave, Pulse, Balancer or Proxy Server is detected, an email will be sent to these email addresses.
• System Administrator: When users use the option in the Error Report Viewer to report error messages to their system administrator, those emails will be sent to these email addresses.
• Low Database Connections: Low Database connection notification emails will be sent to these email addresses. See Database Resource Limits for more information on this issue.
• Database Connection Thresholds: When the number of available database connections is below the set threshold a warning email will be sent.

• Idle Shutdown: Notifications for Idle Shutdown operations will be sent to these email addresses.
• Machine Startup: Notifications for Machine Startup operations will be sent to these email addresses.
• Thermal Shutdown: Notifications for Thermal Shutdown operations will be sent to these email addresses.
• Machine Restart: Notifications for Machine Restart operations will be sent to these email addresses.

House Cleaning¶

Pending Job Scan¶

The Pending Job Scan determines if any pending jobs should be released, or if any pending job events should be processed. If Pulse is running, it will perform the Pending Job Scan every interval. If Pulse is not running, the Slaves will perform the Pending Job Scan between tasks if the interval has passed.

• Pending Job Scan Interval: The maximum amount of time between Pending Job Scans in seconds.

• Allow Slaves to Perform the Pending Job Scan If Pulse is not Running: If enabled, the Slaves will perform the pending job scan if Pulse is not running. If disabled, only Pulse can perform the pending job scan.

• Run Pending Job Scan in a Separate Process: If enabled, the pending job scan will be run in a separate process. This can be useful when using dependency scripts to ensure that a crash caused by the script doesn’t cause the main application (Pulse, Slave, or Monitor) to crash.

• Write Pending Job Scan Output to Separate Log File: If enabled, all output from the pending job scan will be placed into a separate log file.
• Pending Job Scan Process Timeout: If running the pending job scan in a separate process, this is the maximum amount of time the process can take before it is aborted.
• Asynchronous Job Events: If enabled, many job events will be processed asynchronously by the Pending Job Scan operation, which can help improve improve the performance of the Monitor when performing operations on batches of jobs. If this is enabled, the OnJobSubmitted event will still be processed synchronously to ensure that any updates to the job are committed before the job can be picked up by Slaves.

• Maximum Job Events Per Session: The maximum number of pending job events that can be processed per scan.

House Cleaning¶

House Cleaning is responsible for purging old jobs, slaves, and reports, and for regular maintenance of the repository and database. If Pulse is running, it will perform House Cleaning every interval. If Pulse is not running, the Slaves will perform House Cleaning between tasks if the interval has passed.

• House Cleaning Interval: The maximum amount of time between House Cleaning operations in seconds.

• Allow Slaves to Perform House Cleaning If Pulse is not Running: If enabled, the Slaves will perform house cleaning if Pulse is not running. If disabled, only Pulse can perform house cleaning.

• Run House Cleaning in a Separate Process: If enabled, the house cleaning operation will be run in a separate process.

• Write House Cleaning Output to Separate Log File: If enabled, all output from the house cleaning will be placed into a separate log file.
• House Cleaning Process Timeout: If running the house cleaning in a separate process, this is the maximum amount of time the process can take before it is aborted.
• House Cleaning Maximum Per Session

• Maximum Deleted Jobs: The maximum number of deleted jobs that can be purged per session.
• Maximum Archived Jobs: The maximum number of jobs that can be archived per session.
• Maximum Auxiliary Folders: The maximum number of job auxiliary folders that can be deleted per session.
• Maximum Job Reports: The maximum number of jobs report files that can be deleted per session.

Repository Repair¶

Repository Repair is responsible for finding orphaned tasks and limit stubs, and checking for stalled slaves. If Pulse is running, it will perform a Repository Repair every interval. If Pulse is not running, the Slaves will perform the Repository Repair between tasks if the interval has passed.

• Repository Repair Interval: The maximum amount of time between Repository Repair operations in seconds.

• Allow Slaves to Perform the Repository Repair If Pulse is not Running: If enabled, the Slaves will perform the repository repair if Pulse is not running. If disabled, only Pulse can perform the repository repair.

• Run Repository Repair in a Separate Process: If enabled, the repository repair operation will be run in a separate process.

• Write Repository Repair Output to Separate Log File: If enabled, all output from the repository repair will be placed into a separate log file.
• Repository Repair Process Timeout: If running the repository repair in a separate process, this is the maximum amount of time the process can take before it is aborted.
• Automatic Primary Election: If enabled, the Repository Repair operation will elect another running Pulse/Balancer instance as the Primary if the current Primary instance is no longer running.

Auto Configuration¶

This allows you to configure your Slaves from a single location. When a Slave starts up, it will automatically pull this configuration from Pulse and apply it before fully initializing. See the Auto Configuration documentation for more information.

User Security¶

• Super User Password: The password needed to access Super User Mode in the Monitor. Leave blank for no password.

• Enhanced User Security: When using the System User for the Deadline User, the only way to switch Deadline users is to log off the system and log back in as someone else. This helps improve Deadlines’s user security, as it prevents users from impersonating others to modify their jobs.

• Use The System User For The Deadline User: Enable to use enhanced user security, which prevents users from impersonating others.
• Rendering Jobs As User: By default, the rendering process will run under the same user account that the Slave is running as. If Render Jobs As User is enabled, the rendering process will run under the user account associated with the user that submitted the job. Each Deadline user must have their Render Jobs As User settings configured properly for this to work. On Windows, the user’s Run As Name, Domain, and Password settings will be used to start the rendering process as that user. On Linux and Mac OS X, only the user’s Run As Name setting will be used with ‘su’ or ‘sudo’ to start the rendering process as that user. Note that on Linux and Mac OS X, the Slave must be running as root for this to work properly.

• Render Jobs As User: Enable to have jobs render as the user that submitted them.

• Use ‘su’ Instead Of ‘sudo’ On Linux and Mac OS X: If enabled, ‘su’ will be used to run the process as another user instead of ‘sudo’. This setting is ignored on Windows.

• Preserve Environment On Linux and Mac OS X: If enabled, the user environment will be preserved when running the process as another user using ‘su’ or ‘sudo’. This setting is ignored on Windows, and is ignored on Mac OS X when using ‘su’ instead of ‘sudo’. Note that when this option is disabled, any environment variables that are set for the process by the render plugin are ignored because su or sudo will reset the environment.

• Simulate Login (‘su’ only): If enabled, the ‘-l’ option will be passed to ‘su’ in order to simulate a user login. This has no effect when running ‘sudo’.

Note

The behaviour of this ‘-l’ option can vary based on the OS, and the target user’s default SHELL. For bash based shell environments, this setting should be enabled if you are relying on ~/.bashrc to be sourced in the target user’s SHELL. This ‘-l’ option is not required for tcsh shell environments which source ~/.tcshrc regardless.

• Set HOME variable to user’s home directory (‘sudo’ only): If enabled, the HOME environment variable will be set to the user’s home directory when running ‘sudo’. This has no effect when running ‘su’.

• Execute Remote Commands As User (Only On Linux and Mac OS X): By default, remote commands will be executed under the same user account that the Launcher is running as on the machine receiving the command. If Execute Remote Commands As User is enabled, the command will run using ‘su’ to change the user to the Deadline user that submitted the command. Note that the Launcher must be running as root for this to work properly.

• Execute Remote Commands As User (‘su’ only): Enable to have remote commands execute as the user that submitted them.
• Preserve Environment (Linux only): If enabled, the user environment will be preserved when running the process as another user using ‘su’. This option is only available on Linux.

Job Settings¶

Job Scheduling¶

Scheduling Order

• Job Scheduling Order: The order of priority that Deadline uses to schedule jobs. See the Job Scheduling documentation for more details.
• Priority Weight: Weight given to job priority when using a Weighted scheduling order.
• Submission Time Weight: Weight given to job submission time when using a Weighted scheduling order.
• Error Weight: Weight given to the number of errors a job has when using a Weighted scheduling order.
• Rendering Task Weight: Weight given to the number of rendering tasks a job has when using a Weighted scheduling order.
• Rendering Task Buffer: A buffer that is used by slaves to give their job extra priority on the farm.
• Enhanced Balancing Logic: If enabled, a more enhanced method of balancing slave between jobs is used, which should prevent slaves from jumping between jobs as much. This feature is still considered experimental.

Submission Limitations

• Task Limit For Jobs: The maximum number of tasks a job can have. Note that this does not impose a frame limit so you you can always increase the number of frames per task to stay below this limit.
• Maximum Job Priority: The maximum priority value a job can have.

Automatic Job Timeout

Configure Deadline to automatically determine a timeout for a job based on the render times of tasks that have already completed. If a task goes longer than that timeout, a timeout error will occur and the task will be requeued.

• Minimum number of completed tasks required before calculating a timeout: The minimum number of tasks that must be completed before Auto Job Timeout Checking occurs.
• Minimum percent of completed tasks required before calculating a timeout: The minimum percent of tasks that must be completed before Auto Job Timeout Checking occurs.
• Enforce an automatic job timeout for all jobs: If enabled, the Auto Job Timeout will be enabled for all jobs overriding the per job specification of the value.
• Timeout Multiplier: To calculate the Auto Job Timeout, the longest render time of the completed tasks is multiplied by this value to determine the timeout time.

Failure Detection¶

Job Failure Detection

Sends warnings and fail jobs or tasks if they generate too many errors.

• Send a warning to the job’s user after it has generated this many errors: A warning will be sent to the job’s notification list once its error count has reach. By default, the submitting user is automatically added to this list.
• Mark a job as failed after it has generated this many errors: The number of errors a job must throw before it is marked as failed.
• Mark a task as failed after it has generated this many errors: The number of errors a task must throw before it is marked as failed.
• Automatically delete corrupted jobs from the Repository: If enabled, if a job is found to be corrupted it will it will be automatically removed from the the Repository.
• Maximum Number of Job Error Reports Allowed: This is the maximum number of error reports each job can generate. Once a job generate this many errors it will fail and can not be resumed until some of it’s error reports are deleted or this value is increased.

Slave Failure Detection

Sends warnings and prevent Slaves from reattempting jobs that keep generating errors.

• Pick next available task for a job if the job’s previous task generated an error: If the slave reports an error for a task, and this option is enabled, it will try to pick up the next available task for the job instead of the one it just reported an error for. This prevents the slave from failing to render the same task repeatedly. Note that this setting is ignored by Sequential jobs.
• Send a warning after a Slave has generated this many errors for a job in a row: The maximum number of errors that can occur before email warnings are sent to the users specified in the Email Notification section.
• Mark a Slave as bad after it has generated this many errors for a job in a row: If a Slave hits this many errors, it will be marked as bad for its current job.
• Frequency at which a slave will attempt a job that it has been marked bad for: The percentage of time a Slave will attempt a task it has been marked bad for if no good jobs are available.

Cleanup¶

Automatic Job Cleanup

• Cleanup Jobs After This Many Days: If enabled, this is the number of days to wait before cleaning up completed jobs.
• Cleanup Mode: Whether the cleanup should archive the jobs found or delete them.
• You can also set the number of hours since the job was last modified before cleaning it up.

Deleted Job Purging

• Set the number of hours after a job has been deleted before it is purged from the database.
• Suppress the Archive/Delete On Job Completion if there are Error reports: If enabled error messages don’t get lost to auto complete.

Auxiliary Files¶

Many jobs have an option to submit the scene file and other auxiliary files with the job. This can be useful because it stores a copy of the scene file with the job that can be referred to later. However, if the size of these files are large and the Repository server isn’t designed to handle this load, it can seriously impact the Repository machine’s performance. This problem can be avoided by storing these files in a location on a different server that is designed to handle the load.

• Store job auxiliary files in a different location: If enabled, job auxiliary files submitted to Deadline will be stored at a location specified and not the Repository.

Note: If you are hosting more than one Repository, you should not point them to use the same auxiliary file location. As part of housecleaning, auxiliary files belonging to deleted, archived, or otherwise missing jobs are routinely deleted from this location. Since housecleaning cannot determine if an auxiliary folder belongs to a job from a different Repository, each Repository should have its own separate auxiliary file location to avoid deleting another Repository’s auxiliary files.

Extra Properties¶

Extra arbitrary properties known as Job Extra Info values can be submitted with a job, and these properties can be given user friendly column names so that they can easily be identified and used to filter and sort jobs in the Monitor job’s panel. Job Extra Info properties are very useful if you want to inject and track metadata per job, which is specific to certain jobs in your farm. These extra arbitrary properties form the backbone of our production tracking support for solutions such as Shotgun, FTrack and NIM, but remains highly customizable for your own in-house solution as well.

Extra arbitrary task properties known as Task Extra Info values can be submitted with a job, and these properties can be given user friendly column names so that they can easily be identified and used to filter and sort tasks in the Monitor task’s panel. Task Extra Info properties are very useful if you want to inject and track metadata per task, which is specific to a certain job type in your farm.

Application Data¶

Application Cleanup

• Delete Monitor logs after this many days: The number of days before a Monitor log will be deleted.
• Delete Slave logs after this many days: The number of days before a Slave log will be deleted.
• Delete Pulse logs after this many days: The number of days before a Pulse log will be deleted.
• Delete Balancer logs after this many days: The number of days before a Balancer log will be deleted.
• Delete Launcher logs after this many days: The number of days before a Launcher log will be deleted.
• Delete Proxy Server logs after this many days: The number of days before a Proxy Server log will be deleted.
• Delete Web Service logs after this many days: Number of days to keep Web Service logs before deleting them.
• Delete Temporary files after this many days: The number of days to keep files in the Deadline Temp folder before deleting them.

Logging Verbosity

• Slave Verbose Logging: If enabled, more information will be written to the Slave log while it is running.
• Pulse Verbose Logging: If enabled, more information will be written to the Pulse log while it is running.
• Balancer Verbose Logging: If enabled, more information will be written to the Balancer log while it is running.
• Web Service Verbose Logging: If enabled, more information will be written to the Web Service log while it is running.
• Proxy Server Verbose Logging: If enabled, more information will be written to the Proxy Server log while it is running.

History Entries

• Maximum Number of Repository History Entries: The maximum number of repository history entries that are stored before old entries are overwritten.
• Maximum Number of Job History Entries: The maximum number of job history entries that are stored before old entries are overwritten.
• Maximum Number of Slave History Entries: The maximum number of slave history entries that are stored before old entries are overwritten.
• Maximum Number of Pulse History Entries: The maximum number of pulse history entries that are stored before old entries are overwritten.
• Maximum Number of Balancer History Entries: The maximum number of balancer history entries that are stored before old entries are overwritten.

Statistics Gathering¶

Configure Deadline to keep track of job and farm statistics. Note that Pulse must be running to gather Slave and Repository statistics. Job statistics will be gathered regardless if Pulse is running or not.

• Enable Statistics Gathering: If enabled, Deadline will gather statistical information.
• Slave Statistics Gathering Interval(in minutes): The amount of time between polling Slaves for statistical information.
• Repository Statistics Gathering Interval(in minutes): The amount of time between polling the Repository for statistical information.
• Delete Job Statistics After This Many Days: The number of days from generation that job statistics will be kept before they are deleted.
• Delete Slave Statistics After This Many Days: The number of days from generation that Slave statistics will be kept before they are deleted.
• Delete Repository Statistics After This Many Days: The number of days from generation that Repository statistics will be kept before they are deleted.

Mapped Paths¶

Paths to be mapped before rendering (based on Operating System). You may add, remove, or edit paths as well as modify the order in which they will be mapped. See the Cross Platform Rendering section for more details.

Mapped Drives¶

It is recommended to always configure any Windows mapped drives you may have globally available in your pipeline to provide another level of resilence in case your login scripts / AD domain based GPO fails on occasion to apply any mapped drive letters typically as a user logs on. Deadline Slave attempts to map any drive letters at the beginning of each job it renders, but can be configured to skip if the drive letter is already in place via the Only Map If Unmapped setting. For more complicated configurations, our Script API provides functions such as PathUtils.MapNetworkPath() so you can adhoc map drive letters to network paths.

Drives to be mapped before rendering (Windows Only).

• Drive: The drive to be mapped.
• Remote Path: The remote path for the drive.
• Only Map If Unmapped: Enable to only map the drive if it is unmapped. Disabled by default.
• Requires Authentication: (Optional) Enable if the drive requires authentication. If unchecked, the existing logged in user account credentials will be used.

Note, drives can be mapped when running as a service. Beware that if a user is logged in and has mapped drives set up for them, the Deadline Slave service won’t see them because they run in a different environment. However, if the drives are mapped in the service’s environment (which is what the slave is doing), then they will work fine. Using the following setting can help remove this potential situation.

• Only map drives when the Slave is running as a service: If checked, the slave will only map the drives if it’s running as a service. If unchecked, it will also do it when the slave is running as a normal application.

Python Settings¶

A list of additional paths to be added to the Python search paths. Specify one path per line, and use the Add Path button to browse for paths.

Wake On Lan Settings¶

Deadline’s Power Management uses Wake On Lan to wake up machines, and you can configure which port(s) the WOL packet is sent over. If no ports are listed here, Deadline will use port 9 by default.

Network Whitelist¶

The Network Whitelist is a security feature that applies to both the Web Service and the Proxy Server. If the Network Whitelist is enabled, these applications will only accept communications from IP addresses that are specified in this list. Both individual IP addresses and ranges of IP addresses (in CIDR notation) are allowed.

Note

Only IPv4 addresses and CIDR ranges are allowed. An IPv4 address may look like 52.232.87.63. An IPv4 CIDR range may look like 192.168.0.0/16.

Web Service and Proxy Server¶

Both the Web Service and the Proxy Server listening over an HTTP connection. You must ensure that they are listening on different ports in order to use them together.

Web Service

The Web Service allows you to execute commands and scripts from a browser, and must be enabled to use Deadline’s Mobile applications. The Web Service can be run as a console application. Note that only one instance of the Web Service can run on a machine at a time. Also note that all changes to the Web Service settings require the Web Service to be restarted before they will be implemented.

• Listening Port: The port on which the Web Service will listen.
• Connection Limit: The maximum number of concurrent connections allowed for the Web Service.
• Connection Timeout (in seconds): The amount of time in between sending and receiving messages to and from the Web Service before a timeout occurs.

If the Web Service requires authentication, users would use their Deadline user name along with the password stored in their User Settings. If empty passwords are allowed, they can leave their password setting blank.

• Require Authentication: If enabled, the Web Service will require a username and password. These are stored in the user settings.
• Allow Empty Passwords: If enabled, the Web Service will accept empty passwords.

Proxy Server

The Proxy Server allows remote clients to connect to the repository on this machine.

• IP Address: The IP Address the Proxy Server will bind to.
• Listening Port: The Port the Proxy Server binds to.

Usage Based Licensing¶

If you are using Usage Based Licensing, you must specify the information that the Deadline Slaves will use to connect to your Cloud License Server.

• URL: This is the URL that is used to connect to your Cloud License Server. It can be in one of two forms, depending on if you’re using a Cloud License Server or a Cloud License Server Proxy. Here are a couple of examples (where XXXXXXXXXXXXis the ID of your Cloud License Server):