Achtung! Der deutschsprachige Inhalt ist wegen fehlenden Betreuerinnen und Betreuern veraltet. Verwenden Sie bitte die englischsprachige Version!
Attention! Current pages describe CBSD version 13.0.x. If you are using an older version, please update first.
Attention! I apologize for the automatic translation of this text. You can improve it by sending me a more correct version of the text or fix html pages via GITHUB repository.
Starting with version 10.0.6, in CBSD is functional, allowing you to create all single tasks to perform (usually deferred for a while or just long).
Partially, this functionality uses itself CBSD for making their own internal problems for the local or remote node, however, you can also use this feature.
The storage queue of tasks and their parameters is SQLite3 database. You can configure different behavior and processing tasks:
- Specify the user who will run
- Specify the remote node. In this case, CBSD automatically enters task taskd-queue remote server and will monitor its implementation.
- Specify an alternate logfile or disable logging altogether.
- Get result of working on the problem Email.
- Configure log rotation policy (delete the log automatically if code execution - 0 successfully, delete the log automatically in any case, delete the log records automatically after X or N aging time).
- Indicate dependence (chain) of a problem from the other - a particular task will be located in Pending until another dependence.
For a list of the current task queue, use the command cbsd taskls:
root@dev:~ # cbsd taskls ID STATUS OWNER CMD LOGFILE ERRCODE 1 Complete root cd /usr/ports && svn up /tmp/taskd.1.log 32512 2 Complete root cbsd repo action=get sources=base /tmp/taskd.2.log 0 3 Complete root cbsd svnup /tmp/taskd.3.log 0 4 Complete root cbsd buildworld /tmp/taskd.4.log 0 5 Complete root cbsd installworld /tmp/taskd.5.log 0 6 Complete root cd /usr/ports && svn up /tmp/taskd.6.log 0 7 In Progress root cbsd j2slave jname=owncloud /tmp/taskd.7.log 0
- ID - serial number and unique tasks assigned by the system when entering
- STATUS - can have 3 states: Pending (waiting to be processed), In progress - during operation, Complete - task is completed
- OWNER - who set the task. Can contain either the user name or the name of the remote node that set the task on this server
- CMD -directly task
- LOGFILE - log mining tasks by default stored in /tmp/taskd.$ID.log. You can specify when you create an alternate Job log on or off at all
- ERRCODE - code of completed tasks
Tasks are run in parallel, but a configuration file, $etcdir/taskd.conf is governed by a limit on the number of concurrent tasks that the system can perform simultaneously.
New tasks are started immediately upon receipt, however, if the limit is exceeded concurrent tasks, tasks of the latter will be found in the status Pending waiting their turn.
through the parameter after in the formulation of a problem, you can specify the JOB ID of the task before execution of which a new task will not run. In addition, upon completion of the new task dependent, will start only if the code is complete the task dependencies - 0 (worked without error), otherwise the new task inherits errcode and will not be activated. This functionality is useful when you need to perform a number of interdependent tasks sequentially, eg:
cbsd task mode=new cbsd svnup //run the update source cbsd task mode=new after=1 cbsd world //Builds the world after working svnup, if it job=1 cbsd task mode=new after=2 cbsd kernel // Builds core after working world, if it job=2 cbsd task mode=new cbsd jcoldmigrate jname=jail1 node=n1.node.org // run cold migration for jail1 to a node n1.node.org cbsd task mode=new cbsd after=5 jremove jail1 // remove slave-jail jail1 from current node, if migration (job 5) is success.
ID job-and a new task can be derived from SQL, or process output when the problem - tied her ID output to stdout.
You can configure the notification by email for their tasks through a file $etcdir/taskd.conf, overwriting the default settings of $etcdir/defaults/taskd.conf
root_rcpt="root@localhost" # default contact for mail notification or root owner lastoutput_num="10" # how many last strins from the log send to mail max_simul_jobs="10" # max run simultaneous proccesses of nexttask loop_timeout="60" # timeout between forced checking the queue if no events, in seconds
- root_rcpt - contact email (separated by commas for multiple) which will be notified upon completion of the task. For example, if you want to receive email for a certain letter on the tasks, owner which cbsdweb, you must add an entry: cbsdweb_rcpt="email@example.com"
- lastoutput_num - insert in a letter last N lines task performed.
- max_simul_jobs - limit the number of parallel tasks, if the number of tasks is exceeded - the last task will wait for the first execution.
- loop_timeout - interval between the forced checking queue new challenges.
In fact the task you will receive letters similar to the following:
---------- Forwarded Message ---------- Subject: CBSD dev.my.domain: task 6 is completed Date: Thursday 29 May 2014, 00:54:06 From: Charlie Root
To: firstname.lastname@example.org cmd: cd /usr/ports && svn up runtime: 14 minutes errcode: 0 last 10 lines of task log (/tmp/taskd.6.log): Restored 'audio/zynaddsubfx/pkg-plist' Restored 'audio/zynaddsubfx/Makefile' Restored 'audio/zynaddsubfx/distinfo' Restored 'audio/zynaddsubfx/pkg-descr' D graphics/py-gvgen/pkg-plist U graphics/py-gvgen/distinfo U graphics/py-gvgen/pkg-descr U graphics/py-gvgen/pkg-message U graphics/py-gvgen/Makefile Updated to revision 355654. -----------------------------------------
Notification of system tasks, which puts CBSD itself locally or on a remote node, to come to the email will not be, in addition, the director of tasks in this case keeps track of the end of the task, analyzes and removes the log refinement problem
For the formulation of the problem, use the command cbsd task. If the specified argument node=XXXX, task is created on a remote node, while, in the task list on the local machine you can track its status.