Field

Purpose

Enable Event Logging

Toggle logging by FireDaemon Pro to the Event Log.

Enable Debugging

Toggle debugging by FireDaemon Pro to nominated text file.

Append Logs

When this option is enabled, entries are always appended to the Debug, Stdout and Stderr log files.  When this option is disabled, the Debug, Stdout and Stderr log files are overwritten when the service starts. If the sub-process crashes and FireDaemon Pro has to restart it, the Stdout and Stderr log files are overwritten when Append Logs is unchecked. Note that if FireDaemon Pro cannot write to the any of the specified log files it will write an error event to the Windows Applicatoin Event Log.

Debug Log File

The full path and name of the file to log to. Environment variables can be used in the name.

Job Type

Determines whether the sub-process is to be placed in a Job Group. By placing the sub-process in either a Local or Global group, any child processes spawned by the sub-process will be terminated when the service is stopped. Further, the Process Priority is propagated to all processes in the Job. The actual scope of the Job Type is only relevant when the Windows Terminal Services server component is installed. A Terminal Services server has multiple namespaces for a variety of named kernel objects including job objects. By default, all services are created in Global scope. Local Jobs exist in the current client session namespace only so as to not interfere with other instances of the same application in other sessions. Generally, choose No Job if your service runs a single application instance. Choose Global Job if your service spawns multiple sub-processes or you have Windows Terminal Services running. Local Job scope is of dubious use and has been only included for the sake of completeness.

Ignore Control Flags

FireDaemon Pro can be controlled via writing directly to the registry. FireDaemon Pro will stop any process it is running if the Control registry key is set. It can be set globally or on a per-service basis. FireDaemon Pro will monitor the control flags as follows (remember the relationship is inverse so if no control flags are ignored then both will be monitored):

The registry keys that can be modified are as follows:

Global Level (32-bit FireDaemon Pro on x86 hardware or 64-bit FireDaemon Pro on x64 hardware):

HKLM\Software\

       FireDaemon Technologies\FireDaemon\Control

               DWORD 0 or 1

Global Level (32-bit FireDaemon Pro on x64 hardware):

HKLM\Software\Wow6432Node\

       FireDaemon Technologies\FireDaemon\Control

               DWORD 0 or 1

Service Level (both x86 and x64):

HKLM\SYSTEM\

       CurrentControlSet\Services\<Service>\Parameters

               \Control

                       DWORD 0 or 1

0 = Process running 1 = Process will stop

Field

Purpose

Capture Stdout in File

Enables the capture of Stdout (Standard Output – the console text output stream from the application being run as a service). Nominate the full path and name of the file to log to. Note: Output is captured to file only when the application's output buffer is flushed. FireDaemon Pro cannot force this to happen. Thus, the successful capture of output is dependent upon the application's behavior. The end of the capture file may potentially be artificially truncated. This applies to Stdout and Stderr.

Capture Stderr in Stdout

Enables Stderr (Standard Error – the console text output stream specifically marked as errors from the application being run as a service) to be captured alongside Stdout into the same log file.

Or Capture in File

Enables Stderr to be captured in a separate file from Stdout.

Field

Purpose

Pre-Launch Delay

The number of milliseconds after the FireDaemon Pro service has entered the running state before the sub-process is launched.

Priority

The scheduling priority of the sub-process and all child processes. The use of Real Time priority should be avoided as it actually pre-empts the kernel scheduler.

CPU Bindings

Allows the sub-process to be bound to specific CPUs or cores on multi-CPU or multi-core machines. Upto 32 cores are supported. You can directly enter the Affinity Mask as a binary, decimal or hexadecimal value. The base is specified in the Service Manager Options. If no CPUs are checked or all are checked then the sub-process can potentially run on any CPU and the CPU actually in use will be decided by the Windows scheduler from one moment to the next.