1. core
  2. mysql
  3. network
  4. processmanager
  5. workflowinstance
  6. logger
  7. gc


evQueue core process configuration

core.gid (numeric) : 33

core.uid (numeric) : 33

Numeric UID and GID of the process. If you want the process to change user or group, you must run evqueue as root. Use uid/gid of www-data if you want to use web board (or change apache uid/gid)

core.pidfile (string) : /var/run/evqueue/

Filename of the pidfile created by evqueue at startup


MySQL configuration

mysql.database (string) (string)

mysql.password (string)

mysql.user (string)


TCP configuration

network.bind.ip (string)

IP which will be used to bind. Use "*" to bind on all interfaces.

network.bind.port (numeric) : 5000

Port to listen on.

network.bind.path : /var/run/evqueue/evqueue.socket

Path of the UNIX socket. This socket can be used in combination with the IP socket. Leave blank if not needed.

network.listen.backlog (numeric) : 64

Size of the listen backlog : this is the maximum number of pending connections.

network.rcv.timeout (numeric) : 30

Receive timeout in seconds

network.snd.timeout (numeric) : 30

Send timeout in seconds


processmanager.errlogs.enable (boolean) : no (string)

Error logs are used when a process returns 0 (no error) but the XML is invalid. This is often caused by a task not detecting properly error cases. These logs are very useful to troubleshoot failed executions. It is normaly safe to enable this as very few logs should be created (string) : /tmp

Where to store tasks outputs. These files are used to temporarily store stdout and stderr until task exit. They might be deleted on exit (this behaviour is controlled by processmanager.logs.delete).

processmanager.logs.delete (boolean) : yes

Delete logs at the end of task execution. It is strongly recommended to delete logs as the can quickly grow up

processmanager.monitor.path (string) : /usr/bin/evqueue_monitor

Path to the evqueue monitor. The monitor is installed by evQueue core package. It is used to control task execution and notify evQueue core engine. (string) : .

Path to prepend when task filename is relative. When a task is created with a relative filename (not beginning with a “/”), this path is prepended before execution. This is useful if you have custom developed tasks, stored on different locations on different environment. This prevents from storing hard coded paths into database. Using this trick you can dump databases from one environment to another, even if paths are different.

processmanager.monitor.ssh_key (string)

processmanager.monitor.ssh_path (string) : /usr/bin/ssh

SSH configuration is used for remote task execution. If no key is specified, default SSH key of the user running evQueue will be used. If you want to use the default key you must comment "processmanager.monitor.ssh_key"


workflowinstance.saveparameters (boolean) : yes

Save workflow parameters in database. This is required if you want to use search on parameters values within the web control interface. As on line is inserted for each parameter of each workflow instance, the table t_workflow_instance_parameters can grow quickly. You should be careful when using this option on high loaded platforms. If you disable this, you won't be able to filter workflow instances based on their input parameters. This however only impacts web control interface, and not the core engine.

workflowinstance.savepoint.level (numeric) : 2

The savepoint level determines how evQueue synchronizes with the database. This affects performance, as well as the web control interface.

Note that the level 0 or 1 will also affect workflowinstance.saveparameters and disable it (whatever its value was).

workflowinstance.savepoint.retry.enable (boolean) : yes

workflowinstance.savepoint.retry.times (numeric) : 2

workflowinstance.savepoint.retry.wait (numeric) : 2

Retry controls what to do on database errors when saving workflows state (savepoint). If retry is disactivated, a database error will prevent the workflow instance from being archived into the database. However, this does not prevent correct execution of the workflows. The will not be shown in the web board as terminated workflows, also they have been well executed. If you enable retry, evQueue will try database requests “times” with a backup time of “wait” seconds. This prevents you from loosing data on tamporary database failure (for example restart).


logger.syslog.enable (boolean) : yes

Log errors to syslog. It is recommended to always keep this active.

logger.syslog.filter : LOG_NOTICE

Only log events with a priority greater or equels to this filter

logger.db.enable (boolean) : no

Log errors to database. This is required if you want to access logs from the web board. This can slow down the engine on busy systems and thus it is recommanded to keep the filter on LOG_WARNING in production.

logger.db.filter : LOG_WARNING

Only log events with a priority greater or equels to this filter


Garbage collector

The garbage collector is used to reduce the size of the evQueue database. It will delete workflow instances after a period of time. Disabling garbage collector will give you an infinite history of terminated workflow instances. This can however cause serious slowdowns on web board (and on search particularily).

gc.enable (boolean) : yes

Whether or not to enable the garbage collector

gc.interval (numeric) : 43200

Interval in seconds between executions of the GC

gc.limit = 1000

If entries are to be removed, GC will not free more than this limit at once. You should really use this to avoid long locks on your database.

gc.delay = 2

If the limit is reached, GC will wait this interval (in seconds) before trying to free again up to gc.limit

gc.logs.retention = 7

Clean database logs older than (in days)

gc.workflowinstance.retention = 30

Clean terminated workflow instances older than (in days)