work_queue_worker(1) | Cooperative Computing Tools | work_queue_worker(1) |
work_queue_worker - worker process for executing tasks dispatched through Work Queue
work_queue_worker [options] <masterhost> <port>
work_queue_worker [options] <masterhost:port]>
work_queue_worker [options] "<masterhost:port;[masterhost:port;masterhost:port;...]>"
work_queue_worker [options] -M <projectname>
work_queue_worker is the worker process for executing tasks dispatched from a master application built using the Work Queue API. work_queue_worker connects to the master application, accepts, runs, and returns tasks dispatched to it.
The masterhost and port arguments specify the hostname and port number of the master application for work_queue_worker to connect. Several masterhosts and ports may be specified, separated with a semicolon (;), with the worker connecting to any of the masters specified (When specifying multiple masters, remember to escape the ; from shell interpretation, for example, using quotes.)
Alternatevely, the master may be specified by name, using the -M option.
work_queue_worker can be run locally or deployed remotely on any of the grid or cloud computing environments such as SGE, Amazon EC2, Condor using sge_submit_workers(1), ec2_submit_workers(1), condor_submit_workers(1) respectively.
work_queue_worker can also be run in foreman mode, in which it connects to a master as a worker while acting as a master itself. Any tasks the foreman receives from its master are sent to its subordinate worker processes.
Foreman mode is enabled by either specifying a port to listen on using the -f <port> option or by setting the mode directly with the --foreman option. The foreman can be directed to advertise its presence on the catalog_server() with the -N <project name> flag, which other workers can use to contact the foreman.
work_queue_worker can be run with container. Docker is the default management tool and docker deamon should be enabled in computing nodes. Tasks received from master can be run with container based on user specified docker image.
Container mode is enable by either specifying a image name using the --docker <image> option, which enable workers running each tasks with an independent container or by using the --docker-preserve <image> option, which enable workers running all tasks with a shared container. The default way to manage the image is using docker hub, which means user has to push the container image into the docker hub in advance. If the image is saved in a tarball and cached in the computing node, --docker-tar <tarball> option can be adopted to load the image from the tarball.
On success, returns zero. On failure, returns non-zero.
To run work_queue_worker to join a specific master process running on host master.somewhere.edu port 9123:
% work_queue_worker master.somewhere.edu 9123
To run work_queue_worker in auto mode with debugging turned on for all subsystems and to accept tasks only from a master application with project name set to project_A:
% work_queue_worker -a -d all -M project_A
To run work_queue_worker as a foreman working for project_A and advertising itself as foreman_A1 while listening on port 9123:
% work_queue_worker --foreman -M project_A -N foreman_A1 -f 9123
The Cooperative Computing Tools are Copyright (C) 2003-2004 Douglas Thain and Copyright (C) 2005-2015 The University of Notre Dame. This software is distributed under the GNU General Public License. See the file COPYING for details.
CCTools 7.0.9 FINAL |