brianlmoon / gearmanmanager Goto Github PK

Please guide me in order to convert GearmanManager to a usable library (or anything else) for CodeIgniter framework. I'm going nuts :)

If you have spaces in your worker_dir configuration:

worker_dir=/path/to/dir_1, /path/to/dir_2

the daemon can't be started because file_exists() fails in GearmanManager.php on line 452. You might do this:

Might be nice to see this all packaged together as a composer bundle so that people can start new projects with it easily.

Not sure how much of an overhaul it might entail.

Hi, could you please add the SET_CLIENT_ID request and make it either use the FQDN or a user-configurable name in the config? Thanks!

On a large architecture, you may want to have your workers restart when new code is deployed. Currently GM only restarts when workers change. If non-worker code that is already loaded in GM changes, it is not able to detect that.

The GM helper process could listen on TCP or UDP and take requests. The least of which is a reload command.

Wondering if you know why this issue would be caused by $thisWorker->work() ?

4703 DEBUG  Registering signals for parent
 4703 INFO   Loading workers in /var/www/GearmanManager/pecl-workers
 4703 INFO   Loading workers in /var/www/GearmanManager/pecl-worker-classes
 4705 PROC   Helper forked
 4705 INFO   Loading workers in /var/www/GearmanManager/pecl-workers
 4705 INFO   Loading workers in /var/www/GearmanManager/pecl-worker-classes
 4703 PROC   Started with pid 4703
 4703 PROC   Started child 4706 (reverse_string)
 4703 DEBUG  Registering signals for child
 4706 WORKER Adding server 127.0.1.1
 4706 WORKER Adding job reverse_string
 4703 PROC   Started child 4707 (reverse_string)
PHP Fatal error:  Uncaught exception 'GearmanException' with message 'Failed to set exception option' in /var/www/GearmanManager/pecl-manager.php:51
Stack trace:
#0 /var/www/GearmanManager/pecl-manager.php(51): GearmanWorker->work()
#1 /var/www/GearmanManager/GearmanManager.php(877): GearmanPeclManager->start_lib_worker(Array)
#2 /var/www/GearmanManager/GearmanManager.php(820): GearmanManager->start_worker('reverse_string')
#3 /var/www/GearmanManager/GearmanManager.php(250): GearmanManager->bootstrap()
#4 /var/www/GearmanManager/pecl-manager.php(219): GearmanManager->__construct()
#5 {main}
  thrown in /var/www/GearmanManager/pecl-manager.php on line 51

Hello
Could you help us with a problem which we got using Gearman manager.
If worker is died suddenly (for example segmentation fault) Gearman server gets stick and stop answer on any requests.

We wrote simple test code to reproduce this problem (see below).
If we run with standalone workers (without Gearman Manager) this problem is not reproduced (see below).
Please help us to solve this problem. Thank you in advance.

We are using Gearman Manager with Gearman Server v1.0.6, PHP 5.5.1, pecl-gearman v1.1.2, ubuntu 12.04.2 LTS

Code to reproduce problem:

To run test execute the next command:

for i in `seq 1 20` ;do echo $i; date; php /GearmanManager/pecl-manager.php -P /var/run/gearman/manager.pid -u gearman -d -c  /GearmanManager/config.ini -vvv ; php /GearmanManager/pecl-client/runReverse.php ;date; gearadmin --status; sleep 2; echo kill; killall -9 php ; sleep 1 ; gearadmin --status; sleep 1; done

/GearmanManager/config.ini:

[GearmanManager]
count = 0
dedicated_count = 1
host = localhost:4730
worker_dir=/GearmanManager/workers
log_file = /var/log/gearman-manager/workers.log
max_worker_lifetime = 7200
timeout=3600
auto_update=0

worker code:

<?php
function revstr($job, &$log) {
    $workload = $job->workload();
    $result = strrev($workload);
    $log[] = "Success";
    return $result;
}
?>

runReverse.php:

<?php
$client= new GearmanClient();
$client->addServer();
for ($i = 1; $i <= 5000; $i++) {
    $client->addTask("revstr", "Hello World! ".$i);
}
if (! $client->runTasks())
{
    echo "ERROR " . $client->error() . "\n";
    exit;
}
echo "DONE\n";
?>

To try to reproduce the problem without GearmanManager we run the next command:

for i in `seq 1 200` ;do echo $i; date; for i in `seq 1 20` ;do php t1.php & done ; php runReverse.php ;date; gearadmin -h gearman-srv --status; killall -9 php ; gearadmin -h gearman-srv --status; done

t1.php:

<?php
# get a gearman worker
$worker= new GearmanWorker();

# add the default server (localhost)
$worker->addServer();

# define a variable to hold application data
$worker->addOptions(GEARMAN_WORKER_NON_BLOCKING);;
$worker->setTimeout(5000);

# add the "reverse" function
$worker->addFunction("revstr", "reverse_cb");

# start the worker
while (1) {
            if(@$worker->work() ||
               $worker->returnCode() == GEARMAN_IO_WAIT ||
               $worker->returnCode() == GEARMAN_NO_JOBS) {

                if ($worker->returnCode() == GEARMAN_SUCCESS) continue;

                if (!@$worker->wait()){
                    if ($worker->returnCode() == GEARMAN_NO_ACTIVE_FDS){
                        sleep(1);
                    }
                }

            }


}

function reverse_cb($job)
{
  return strrev($job->workload());
}

?>

How do you set timeout and host for a specific worker. I have read the document and these configurations seems global. Is there a way to set this for a specific function?

new worker file can't start

Is there a way to know which worker file is a culprit . That's hindering the gearman-manager to startup correctly?

Hi,
I'm using Gearman Manager with the PECL extension for Gearman.

I turned on verbose logging (-vvvvv), and for some jobs I send once, I see this output:

[2011-09-11 21:29:37] 9805 WORKER (H:server:133) Starting Job: my_job
[2011-09-11 21:29:37] 9805 DEBUG (H:server:133) Workload: MY_WORKLOAD_IS_HERE
[2011-09-11 21:29:37] 9804 WORKER (H:server:133) Starting Job: my_job
[2011-09-11 21:29:37] 9804 DEBUG (H:server:133) Workload: MY_WORKLOAD_IS_HERE
[2011-09-11 21:29:37] 9806 WORKER (H:server:133) Starting Job: my_job
[2011-09-11 21:29:37] 9806 DEBUG (H:server:133) Workload: MY_WORKLOAD_IS_HERE
[2011-09-11 21:29:37] 10140 WORKER (H:server:133) Starting Job: my_job
[2011-09-11 21:29:37] 10140 DEBUG (H:server:133) Workload: MY_WORKLOAD_IS_HERE
[2011-09-11 21:29:37] 9320 PROC Child 9804 exited (my_job)
[2011-09-11 21:29:37] 9320 PROC Started child 10155 (my_job)
[2011-09-11 21:29:37] 9320 DEBUG Registering signals for child
[2011-09-11 21:29:37] 10155 WORKER Adding server 127.0.0.1:4730
[2011-09-11 21:29:37] 10155 WORKER Adding job my_job
[2011-09-11 21:29:37] 9320 PROC Child 9805 exited (my_job)
[2011-09-11 21:29:37] 9320 PROC Started child 10156 (my_job)
[2011-09-11 21:29:37] 9320 DEBUG Registering signals for child
[2011-09-11 21:29:37] 10156 WORKER Adding server 127.0.0.1:4730
[2011-09-11 21:29:37] 10156 WORKER Adding job my_job
[2011-09-11 21:29:37] 9320 PROC Child 9806 exited (my_job)
[2011-09-11 21:29:37] 9320 PROC Started child 10157 (my_job)
[2011-09-11 21:29:37] 9320 DEBUG Registering signals for child
[2011-09-11 21:29:37] 10157 WORKER Adding server 127.0.0.1:4730
[2011-09-11 21:29:37] 10157 WORKER Adding job my_job
[2011-09-11 21:29:38] 10140 DEBUG (H:server:133) THIS IS MY RETURN VALUE {"a":800,"b":500,"c":400,"d":300}

So, it seems like the actual job is only done once (because I can only see the return value once), but it seems like the job is started and then stopped on 4 worker processes instead of just one. Any idea?

Thanks in advance,
Bar.

Hi

I get it only when workers are updated:

PHP Notice: Undefined index: log_file in /usr/local/share/gearman-manager/GearmanManager.php on line 1053

Quick solution is use of $this->log_file instead of $this->config['log_file'] in line #1049:

$this->log_file_handle = @fopen($this->log_file, "a");

Or define it in your config.ini:

log_file=/var/log/gearman-manager.log

I'm running:
Gearman 0.33 (latest) compiled from source
pecl gearman (latest)
PHP 5.3.2

Everytime I start gearman-manager it prints indefinitely the following:
php: libgearman/universal.cc:615: bool gearman_request_option(gearman_universal_st&, gearman_string_t&): Assertion `con->recv_state == GEARMAN_CON_RECV_UNIVERSAL_NONE' failed.

I did previously have gearman-manager working before I changed my worker files etc, I've tried reverting but still get the errors so I seem to be stuck in a bad state. Does gearman-manager have any persistance/cache that I can clear?

Thanks,
Sam
EDIT: Just to clarify, my client doesn't ever load etc either. (Its not just the console spam). Gearman itself is working fine (just with the basic test on gearman getting started Wiki)

I use syslog for putting log data and get error in console during worker's auto-update:

ERROR:
Could not open log file syslog

I suppose that problem can be in line 1024, because it doesn't check if $this->log_file == 'syslog'

case SIGHUP:
    $this->log("Restarting children", GearmanManager::LOG_LEVEL_PROC_INFO);
    if ($this->log_file) {
        $this->open_log_file();
    }
    $this->stop_children();
    break;

Furthermore, it leads to GearmanManager paralysis: after max_worker_lifetime workers perform exit and GM doesn't restart them again. I think it occures because of "echo" statements that GM produces in php daemon mode.
Here is example from "tail -f gearman-manager.log" history:

Aug 30 10:02:34 gearman-manager[15631]: (H:server:6777) App: D8FFF9
Aug 30 10:02:34 gearman-manager[15631]: (H:server:6777) in_mail
Aug 30 10:02:38 gearman-manager[15629]: (H:server:6773) App: 3D1F53
Aug 30 10:02:50 gearman-manager[15629]: (H:server:6778) Starting Job: long_curl
Aug 30 10:02:58 gearman-manager[32271]: New code found. Sending SIGHUP
Aug 30 10:02:58 gearman-manager[15625]: New code found. Sending SIGHUP
ERROR:
  Could not open log file syslog

Gearman worker manager script

USAGE:
  # GearmanManager.php -h | -c CONFIG [-v] [-l LOG_FILE] [-d] [-v] [-a] [-P PID_FILE]

OPTIONS:
  -a             Automatically check for new worker code
  -c CONFIG      Worker configuration file
  -d             Daemon, detach and run in the background
  -D NUMBER      Start NUMBER workers that do all jobs
  -h HOST[:PORT] Connect to HOST and optional PORT
  -H             Shows this help
  -l LOG_FILE    Log output to LOG_FILE or use keyword 'syslog' for syslog support
  -p PREFIX      Optional prefix for functions/classes of PECL workers. PEAR requires a constant be defined in code.
  -P PID_FILE    File to write process ID out to
  -u USERNAME    Run wokers as USERNAME
  -v             Increase verbosity level by one
  -w DIR         Directory where workers are located, defaults to ./workers. If you are using PECL, you can provide multiple directories separated by a comma.
  -r NUMBER      Maximum job iterations per worker
  -t SECONDS     Maximum number of seconds gearmand server should wait for a worker to complete work before timing out and reissuing work to another worker.
  -x SECONDS     Maximum seconds for a worker to live
  -Z             Parse the command line and config file then dump it to the screen and exit.

Aug 30 10:02:58 gearman-manager[15624]: Restarting children
Aug 30 10:02:58 gearman-manager[26655]: New code found. Sending SIGHUP
Aug 30 10:03:00 gearman-manager[25766]: New code found. Sending SIGHUP
Aug 30 10:03:01 gearman-manager[28663]: New code found. Sending SIGHUP
Aug 30 10:03:02 gearman-manager[29863]: New code found. Sending SIGHUP
Aug 30 10:03:02 gearman-manager[18455]: New code found. Sending SIGHUP
Aug 30 10:03:03 gearman-manager[15631]: (H:server:6779) Starting Job: send
Aug 30 10:03:13 gearman-manager[15629]: (H:server:6780) Starting Job: send
...
...
Aug 30 10:04:10 gearman-manager[15629]: (H:server:6790) Starting Job: long_curl
Aug 30 10:04:20 gearman-manager[15628]: Been running too long, exiting
Aug 30 10:04:20 gearman-manager[15628]: Child exiting
Aug 30 10:04:26 gearman-manager[15629]: (H:server:6791) Starting Job: send
Aug 30 10:04:37 gearman-manager[15633]: (H:server:6792) Starting Job: long_curl

Then I perform restart:

user@server:~$ /etc/init.d/gearman-manager restart
Stopping Gearman Manager:No process in pidfile '/var/run/gearman/manager.pid' found running; none killed.
.
Starting Gearman Manager:.

I'm having a problem with worker permissions.

I have a worker trying to rename a file under /foo/moo

/foo [mode: 770, owner: fileuser, group: fileuser]
/foo/moo [mode 777]

gearmand and gearman-manager are running as user "gearman"

gearman user belongs to fileuser group

Workers say that /foo/moo is not writable, it only works if I change owner of /foo to gearman or chmod it to 777

What am I missing here? It's as if workers don't follow group permissions of the owner process.

Thanks

I'm trying to rotate the logs for GearmanManager, but as expected it continues to write to the original log. I am rotating with newsyslog on freebsd. Does GearmanManager expect a signal?

Thanks

The gearman task object returned on our client complete callback does not get the data when our worker is an object oriented worker but when its a procedural worker it gets the "$task->data()" right. Here is our source code.

<?
//==CLIENT===
$client= new GearmanClient();
$client->addServer();
$client->setCompleteCallback("complete"); 

echo "CLIENT: Sending job\n";

$workload = "helloworld1";
$workload2 = "helloworld2";

$client->addTask("StrRev", $workload);
$client->addTask("stringrev", $workload2);

$client->runTasks();

echo "CLIENT: Job done!\n\n";

function complete($task) 
{ 
  echo "[CALLBACK] COMPLETE: " . $task->unique() . ", " . $task->data() . "\n"; 
}

//======FUNCTION WORKER=====
function stringrev($job, &$log)
{
  echo "Received job: " . $job->handle() . "\n";

  $workload = $job->workload();
  $workload_size = $job->workloadSize();

  echo "Workload: $workload ($workload_size)\n";

  $result = strrev($workload);
  echo "Result: $result\n";

  # Return what we want to send back to the client.
  return $result;
}

//========CLASS WORKER=========
class StrRev 
{
    public function run($job, &$log)
    {
       echo "Received job: " . $job->handle() . "\n";

      $workload = $job->workload();
      $workload_size = $job->workloadSize();

      echo "Workload: $workload ($workload_size)\n";

      $result = strrev($workload);
      echo "Result: $result\n";

      # Return what we want to send back to the client.
      return $result;
    }    
}

?>

Here are the outputs:

//==CLIENT OUTPUT:==//
CLIENT: Sending job
[CALLBACK] COMPLETE: 2906bce6-48bc-4bdb-912e-54d63349c8be, 2dlrowolleh
[CALLBACK] COMPLETE: deb758e8-6080-459e-ad4c-3f15e08f9a18,
CLIENT: Job done!


//==GEARMAN MANAGER LOG==//
 2627 WORKER (H:ip-10-2-113-15:8) Starting Job: stringrev
Received job: H:ip-10-2-113-15:8
Workload: helloworld2 (11)
Result: 2dlrowolleh
 2625 WORKER (H:ip-10-2-113-15:9) Starting Job: StrRev

Echo inside worker does not also show on gearman-manager as you can see on the output.

Change GearmanManager class as abstract class can show code users that this class must not be used directly. Only Pear and Pecl child implementantions can be used.

Hi,

Running Gearman-manager (installing with install.sh, Debian squeeze 32-bit), with 1 job file with dedicated_count=4, the CPU utilization of the Gearman-manager processes is 100%.

No jobs are being sent through gearmand.

How can I debug this?

Thanks,
Bar.

Hi, had some strangeness with GearmanManager always starting workers which were not defined in the config, as a result of this code :

GearmanManager.php, L198
foreach($worker_files as $file){
$function = substr(basename($file), 0, -4);
if(empty($this->functions[$function])){
$this->functions[$function] = array("count"=>1);
}
}

... changed the count to '0' and the problem went away. Is the intention here to have all possible workers defined in the config and set to count=0 if they're not used or marshalled to other gearman servers?

GearmanManager is enabled in two different boxes (M1 and M2).

We are currently using Gearman v0.27. On M1, a job runs for 30-35 minutes and then terminates, even though the job is not complete.

On the other hand, on M2 when the processing time of the job exceeds 2 hours, the job runs for 2 hours and then spawns a child without terminating the parent. Both of them continue processing the same job. We have checked the worker code for issues but have not found any. Issue seems to be in the GearmanManager itself.

Any ideas on how to fix this issue...???

Hi,
I'm not sure if this is an issue or my bad understanding of GearmanManager, but I need this to be solved ASAP and gitHub and google group were the only two places I was able to find to ask the following:

So, in my worker function I want to use a variable defined outside of it by using keyword "global":

Variable $temp is empty... I tried this too:

Variable is still NULL.

Thanks,
Luka

Hi,
I might be missing something, but if a job fails the manager continuously resubmitts to the worker. How to handle this properly -- I looked for some sort of setting to tell the worker not to retry and I couldn't find anything. I'm fairly new to gearman so please point me the right way if this isn't in scope for the gearman-manager you have written.
Peace,
Tony

Hi,

How can I create resources or objects (for example a DB connection) that stay alive from job to job? If the PHP workers are always running, it seems silly to 'include db.php' in the worker function every time (which creates a DB handle).

Can it be done outside of the worker function?

Thanks,
Bar.

I defined in config.ini effective user (user that should run workers) e.g. user=someuser, but it appears that this definition is ignored. posix_geteuid() is giving me that user is gearman and not one that I defined.

I am starting GearmanManger using sudo service gearman-manger start.

I guess that I am missing something. :)

Right now I have workers that handle 3-6 functions each. By default, they do so with each function getting its priority by the order in which the functions are registered. For example, one of my PHP worker classes looks like the paste below. The order of the registered functions is sets the priority in which they receive jobs, and this is critical for our application. How can I replicate this functionality with GearmanManager?

class GmWorker {
protected $gearmanWorker;

public function __construct() {
    $this->gearmanWorker = new GearmanWorker();
    $this->gearmanWorker->addServer('work1');
}

public function setupWorker() {
    $this->gearmanWorker->addFunction( 'td', array(&$this, 'td') );
    $this->gearmanWorker->addFunction( 'tda', array(&$this, 'tda') );
    $this->gearmanWorker->addFunction( 'scrub', array(&$this, 'scrub') );
    $this->gearmanWorker->addFunction( 'v', array(&$this, 'v') );
    $this->gearmanWorker->addFunction( 'list', array(&$this, 'list'));
    $this->gearmanWorker->addFunction( 'fbl', array(&$this, 'fbl'));
    $this->gearmanWorker->addFunction( 'int', array(&$this, 'int'));
    $this->gearmanWorker->addFunction( nv', array(&$this, 'nv') );
    $this->gearmanWorker->addFunction( 'imp', array(&$this, 'imp') );
    while( $this->gearmanWorker->work() );
}

    //functions for each of those registered above are here

}

$gmW = new GmWorker();
$gmW->setupWorker();

If there is no 'td' job, it will do 'tda' jobs... but if a 'td' job pops up, that will take priority when the worker is ready for it's next job.

Hello,

I have a simple worker that utilizes some Laravel code to do it's work. However, I have the following:

class Scrape {

     public function run($job, &$log)
     {
          try
          {
               Command::run(array('scrape'));
          }
          catch (Exception $e)
          {
              $log[] = $e->getMessage();
              return false;
          }

          return true;
     }

}

If anything in the command throws an exception, you'd think it would get caught by that global catch statement. Even adding throw new Exception('uh oh'); right before Command::run() still causes this behavior.

When an exception is triggered I get something like this in the log hundreds of times. I eventually have to open another SSH shell and run service gearman-manager stop && service gearmand stop to kill the process; which empties the queue and calms the server down.

[2013-02-07 00:24:44.438701]  5975 PROC   Child 6080 exited (Metadata_Scrape)
[2013-02-07 00:24:44.439258]  5975 PROC   Started child 6087 (Metadata_Scrape)
[2013-02-07 00:24:44.439666]  5975 DEBUG  Registering signals for child
[2013-02-07 00:24:44.439928]  6087 WORKER Adding server 127.0.0.1
[2013-02-07 00:24:44.440879]  6087 WORKER Adding job Metadata_Scrape
[2013-02-07 00:24:44.504482]  6082 WORKER Creating a Metadata_Scrape object
[2013-02-07 00:24:44.504580]  6082 WORKER (H:localhost.localdomain:14) Starting Job: Metadata_Scrape
[2013-02-07 00:24:44.504626]  6082 DEBUG  (H:localhost.localdomain:14) Workload: {"artist":"Linkin Park","title":"In The End","album":"Hybrid Theory"}
[2013-02-07 00:24:44.504661]  6082 DEBUG  (H:localhost.localdomain:14) Calling object for Metadata_Scrape.
[2013-02-07 00:24:44.539559]  5975 PROC   Child 6081 exited (Metadata_Scrape)
[2013-02-07 00:24:44.540214]  5975 PROC   Started child 6088 (Metadata_Scrape)
[2013-02-07 00:24:44.540936]  5975 DEBUG  Registering signals for child
[2013-02-07 00:24:44.541264]  6088 WORKER Adding server 127.0.0.1
[2013-02-07 00:24:44.541956]  6088 WORKER Adding job Metadata_Scrape
[2013-02-07 00:24:44.612261]  6079 WORKER Creating a Metadata_Scrape object
[2013-02-07 00:24:44.612395]  6079 WORKER (H:localhost.localdomain:14) Starting Job: Metadata_Scrape
[2013-02-07 00:24:44.612447]  6079 DEBUG  (H:localhost.localdomain:14) Workload: {"artist":"Linkin Park","title":"In The End","album":"Hybrid Theory"}
[2013-02-07 00:24:44.612497]  6079 DEBUG  (H:localhost.localdomain:14) Calling object for Metadata_Scrape.
[2013-02-07 00:24:44.640594]  5975 PROC   Child 6082 exited (Metadata_Scrape)
[2013-02-07 00:24:44.641916]  5975 PROC   Started child 6089 (Metadata_Scrape)
[2013-02-07 00:24:44.643182]  5975 DEBUG  Registering signals for child
[2013-02-07 00:24:44.643474]  6089 WORKER Adding server 127.0.0.1
[2013-02-07 00:24:44.644146]  6089 WORKER Adding job Metadata_Scrape
[2013-02-07 00:24:44.719704]  6087 WORKER Creating a Metadata_Scrape object
[2013-02-07 00:24:44.719916]  6087 WORKER (H:localhost.localdomain:14) Starting Job: Metadata_Scrape
[2013-02-07 00:24:44.720018]  6087 DEBUG  (H:localhost.localdomain:14) Workload: {"artist":"Linkin Park","title":"In The End","album":"Hybrid Theory"}
[2013-02-07 00:24:44.720118]  6087 DEBUG  (H:localhost.localdomain:14) Calling object for Metadata_Scrape.
[2013-02-07 00:24:44.742286]  5975 PROC   Child 6079 exited (Metadata_Scrape)
[2013-02-07 00:24:44.742735]  5975 PROC   Started child 6090 (Metadata_Scrape)
[2013-02-07 00:24:44.743018]  5975 DEBUG  Registering signals for child
[2013-02-07 00:24:44.743280]  6090 WORKER Adding server 127.0.0.1
[2013-02-07 00:24:44.744044]  6090 WORKER Adding job Metadata_Scrape
[2013-02-07 00:24:44.827649]  6083 WORKER Creating a Metadata_Scrape object
[2013-02-07 00:24:44.827784]  6083 WORKER (H:localhost.localdomain:14) Starting Job: Metadata_Scrape
[2013-02-07 00:24:44.827836]  6083 DEBUG  (H:localhost.localdomain:14) Workload: {"artist":"Linkin Park","title":"In The End","album":"Hybrid Theory"}
[2013-02-07 00:24:44.827886]  6083 DEBUG  (H:localhost.localdomain:14) Calling object for Metadata_Scrape.
[2013-02-07 00:24:44.843047]  5975 PROC   Child 6087 exited (Metadata_Scrape)

In order for the default example to work, the name of the called function should be 'reverse_string' and not 'reverse'.

I just spent 30min trying to figure this out.

If you follow the recommended debugging method (xdebug + xdebug.scream = 1) you will get flooded with the message below.
It's spammed once per every worker per tick, so any other errors/warnings are easily lost.

PHP Warning:  GearmanWorker::work(): (null) in /usr/local/share/gearman-manager/pecl-manager.php on line 51
PHP Stack trace:
PHP   1. {main}() /usr/local/share/gearman-manager/pecl-manager.php:0
PHP   2. GearmanManager->__construct() /usr/local/share/gearman-manager/pecl-manager.php:219
PHP   3. GearmanManager->bootstrap() /usr/local/share/gearman-manager/GearmanManager.php:250
PHP   4. GearmanManager->start_worker() /usr/local/share/gearman-manager/GearmanManager.php:820
PHP   5. GearmanPeclManager->start_lib_worker() /usr/local/share/gearman-manager/GearmanManager.php:877
PHP   6. GearmanWorker->work() /usr/local/share/gearman-manager/pecl-manager.php:51

Is it possible to know why a worker has exitied?

[2011-10-28 18:00:42.715517] 26505 PROC   Started child 9784 (keywordCollection)
[2011-10-28 18:00:42.720847]  9784 WORKER Creating a keywordCollection object
[2011-10-28 18:00:42.720918]  9784 WORKER (H:domU-12-31-39-05-35-72:43396) Starting Job: keywordCollection
[2011-10-28 18:00:42.766095] 26505 PROC   Child 9784 exited (keywordCollection)

I want to know what causes the exits. This worker used to be working before I have upgraded to the latest version.

Thanks

One thing which would be incredibly useful is for GearmanManager to detect new / deleted worker files.

I noticed you mentioned it being bad practice, but any downsides could be avoided by simply being mindful of new and deleted jobs ones. Letting us shoot ourselves in the foot, that is :-)

I have been working on this for a few hours today and have cobbled together something which nearly works.

Having the helper process detect new / deleted files was simple, but getting the parent process to handle new children has been a challenge.

What I have yet to fix is the parent restarting the children processes [in process_loop()] as well as it not being able to kill orphaned processes when I stop the daemon... they just keep running.

Diff: http://www.pureformsolutions.com/tmp/GearmanManager.diff
Full script: http://www.pureformsolutions.com/tmp/GearmanManager.phps

Any help / direction would be greatly appreciated.

Also, thanks for such a great tool!

Chris-

Ive had to add

            $this->config['log_file'] = $this->log_file;

at line 362 so that the code will set this variable for later use.

I have a current setup that utilizes some includes and helper functions in my workers, making it impossible to use GearmanManager. On startup: "INFO Child exited with non-zero exit code 65280."

It would be helpful if you could utilize require_once() and other functions instead of only being able to have one function in the worker file. Maybe being able to define a worker in the normal way, allowing drop in support or minimal modification for current Gearman worker setups.

I installed the gearman 1.1.1 with libgearman version 1.1.5 and configured gearman manger. I executed my worker without gearman manger it works perfectly with out any error.

When start use gearman manger the worker is not adding anyjob. While configuring I am getting timeout error.

Can anyone tell me what error it means. Does my configuration went wrong or anything else. I am not able to log any error in gearman.log file. So it's very hard to debug.

spurtree@spurtree-desktop:/etc/gearman-manager/workers$ ps aux|grep gearmand
gearman  10725  0.0  0.0  60296  1272 ?        Ssl  12:13   0:00 /usr/sbin/gearmand --pid-file=/var/run/gearman/gearmand.pid --user=gearman --daemon --log-file=/var/log/gearman-job-server/gearman.log --listen=127.0.0.1
spurtree 10876  0.0  0.0   4388   832 pts/5    S+   12:15   0:00 grep --color=auto gearmand
spurtree@spurtree-desktop:/etc/gearman-manager/workers$ sudo /etc/init.d/gearman-job-server stop
 * Stopping Gearman Server gearmand                                                                            [ OK ] 
spurtree@spurtree-desktop:/etc/gearman-manager/workers$ sudo /etc/init.d/gearman-job-server start
 * Starting Gearman Server gearmand                                                                            [ OK ] 
spurtree@spurtree-desktop:/etc/gearman-manager/workers$ sudo /home/spurtree/GearmanManager/pecl-manager.php -w /etc/gearman-manager/workers -c /etc/gearman-manager/config.ini -l /usr/gearman.log -vvv -d -P /var/run/workers.pid -a  -u root
PID   Type   Message
10913 PROC   User set to root
10913 INFO   Loading workers in /etc/gearman-manager/workers
10913 PROC   Helper forked with pid 10914
10914 INFO   Loading workers in /etc/gearman-manager/workers
10913 PROC   Started with pid 10913
10913 PROC   Started child 10915 (get_blog_country_fn)
10913 PROC   Started child 10916 (get_blog_country_fn)
10915 WORKER Adding server 127.0.0.1
10915 WORKER Adding job get_blog_country_fn ; timeout:
10916 WORKER Adding server 127.0.0.1
10916 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10917 (get_blog_country_fn)
10913 PROC   Started child 10918 (get_blog_country_fn)
spurtree@spurtree-desktop:/etc/gearman-manager/workers$ 10917 WORKER Adding server 127.0.0.1
10917 WORKER Adding job get_blog_country_fn ; timeout:
10918 WORKER Adding server 127.0.0.1
10918 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10919 (get_blog_country_fn)
10913 PROC   Started child 10920 (get_blog_country_fn)
10919 WORKER Adding server 127.0.0.1
10919 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10921 (get_blog_country_fn)
10920 WORKER Adding server 127.0.0.1
10920 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10922 (get_blog_country_fn)
10921 WORKER Adding server 127.0.0.1
10921 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10923 (get_blog_country_fn)
10922 WORKER Adding server 127.0.0.1
10922 WORKER Adding job get_blog_country_fn ; timeout:
10923 WORKER Adding server 127.0.0.1
10923 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10924 (get_blog_country_fn)
10924 WORKER Adding server 127.0.0.1
10924 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10925 (get_blog_country_fn)
10925 WORKER Adding server 127.0.0.1
10913 PROC   Started child 10926 (get_blog_country_fn)
10925 WORKER Adding job get_blog_country_fn ; timeout:
10926 WORKER Adding server 127.0.0.1
10913 PROC   Started child 10927 (get_blog_country_fn)
10926 WORKER Adding job get_blog_country_fn ; timeout:
10927 WORKER Adding server 127.0.0.1
10913 PROC   Started child 10928 (get_blog_country_fn)
10927 WORKER Adding job get_blog_country_fn ; timeout:
10928 WORKER Adding server 127.0.0.1
10913 PROC   Started child 10929 (get_blog_country_fn)
10928 WORKER Adding job get_blog_country_fn ; timeout:
10929 WORKER Adding server 127.0.0.1
10913 PROC   Started child 10930 (get_blog_country_fn)
10929 WORKER Adding job get_blog_country_fn ; timeout:
10930 WORKER Adding server 127.0.0.1
10913 PROC   Started child 10931 (get_blog_country_fn)
10930 WORKER Adding job get_blog_country_fn ; timeout:
10931 WORKER Adding server 127.0.0.1
10913 PROC   Started child 10932 (get_blog_country_fn)
10931 WORKER Adding job get_blog_country_fn ; timeout:
10932 WORKER Adding server 127.0.0.1
10932 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10933 (get_blog_country_fn)
10933 WORKER Adding server 127.0.0.1
10913 PROC   Started child 10934 (get_blog_country_fn)
10933 WORKER Adding job get_blog_country_fn ; timeout:
10934 WORKER Adding server 127.0.0.1
10934 WORKER Adding job get_blog_country_fn ; timeout:
10913 PROC   Started child 10935 (get_blog_country_fn)
10935 WORKER Adding server 127.0.0.1
10935 WORKER Adding job get_blog_country_fn ; timeout:

when auto code update is enabled, which will fork it into another process.

and when we use killproc -p $PIDFILE $DAEMON from the shell script, it doesn't stop the code update process.

however "kill pid" will stop it.

$function = 'reverse';

is supposed to be

$function = 'reverse_string';

It would be helpful to add option getting config.ini directives from worker user function.

For example:

Config::get('host');

For example in case when worker sends job to gearman server with his work results.

I'm trying to use GearmanManager with CodeIgniter framework. As I need to access the CodeIgniter instance from the jobs being run by GearmanManger for loading libraries and stuff.

Without GM, I create a CI controller as worker with Net_Gearman library to load the jobs and it works well. But when using GM, those workers are not recognized as jobs. If I just use the jobs with GM, I do not have access to the CI instance and to the libraries provided.

How does GM check if a php is a job or not. Would it be possible to modify this check and use CI controllers as jobs?

Currently, when I make a change on the concurrency (i.e. dedicated_count) of a certain worker type, I need to restart the gearman manager service before the config change takes effect. It would be nice if gearman manager automatically adjusts the number of child processes for a certain worker type if the corresponding config section was changed.

Another feature that would be great to have is the ability to terminate all children of a specific worker type. When I'm developing and testing a new worker, it's very usual that I'd have to prematurely stop a specific worker upon realizing an error in the code. However, for this to be done, I'd need to restart the gearman manager service. This is not so good even on a test server because all other worker processes would be killed even if they belong to a different worker type.

I'm not familiar with the inner workings of gearman manager so just let me know if they're not possible

Is there plans to add composer ( https://getcomposer.org/ ) support to this project?

I'm using spl_autoload capabilities in job files.
Providing one job is fine. If I add another (also with autoload inclusion), the second one will fail.
Cause:
Calling class_exists on the second job triggers the autoloader which has not the job directory in its include path.

This works for me:

pear-manager.php
Row:215 change to ...
if(!class_exists($class, false)) {

Hi,

Is it possible to use something like xdebug to profile the workers? If yes, how? So far when I enabled profiling for all scripts, the output only included information about the client execution.

Any profiling method, even non-xdebug, is welcome.

Thanks in advance

pecl-manager.php
do_job method
line 93: $h = $job->handle();

lines 140, 143, 159, 162: The variable name $handle is used for log messages. Should be $h.

Just wanna request for a feature that would enable me to get a list of jobs (job id + job type) being processed. I know that I can somehow see this in the logfile, but I log a lot of things so it's quite tricky to catch up reading all the lines.

Something like gearman's 'status' and 'workers' commands would be great but I don't know about the internals of gearman manager so I'm not sure if this is possible

I'm having a weird problem where the worker exists after every processing jobs. I'm new to gearman manager but this doesn't seem normal.

I'm running this on CentOS 5 inside virtual machine, gearman 0.27 and php 5.3.0

convert_job worker file can't be causing fatal errors because it's very simple:

manager log:

Date PID Type Message
[2012-01-18 09:56:27.531608] 16924 PROC User set to gearman
[2012-01-18 09:56:27.531759] 16924 DEBUG Registering signals for parent
[2012-01-18 09:56:27.531855] 16924 INFO Loading workers in /etc/gearman-manager/workers
[2012-01-18 09:56:27.531996] 16924 INFO Loading workers in /home/convert/gearman
[2012-01-18 09:56:27.532632] 16925 PROC Helper forked
[2012-01-18 09:56:27.532880] 16925 INFO Loading workers in /etc/gearman-manager/workers
[2012-01-18 09:56:27.532967] 16925 INFO Loading workers in /home/convert/gearman
[2012-01-18 09:56:27.541318] 16924 PROC Started with pid 16924
[2012-01-18 09:56:27.541968] 16924 DEBUG Registering signals for child
[2012-01-18 09:56:27.542353] 16926 WORKER Adding server 127.0.0.1
[2012-01-18 09:56:27.542527] 16926 WORKER Adding job convert_job
[2012-01-18 09:56:27.543619] 16924 PROC Started child 16926 (convert_job)
[2012-01-18 09:58:47.730125] 16924 PROC Child 16926 exited (convert_job)
[2012-01-18 09:58:47.730753] 16924 DEBUG Registering signals for child
[2012-01-18 09:58:47.731132] 17137 WORKER Adding server 127.0.0.1
[2012-01-18 09:58:47.731273] 17137 WORKER Adding job convert_job
[2012-01-18 09:58:47.731621] 16924 PROC Started child 17137 (convert_job)
[2012-01-18 09:58:47.732286] 17137 WORKER (H:localhost.local:36) Starting Job: convert_job
[2012-01-18 09:58:47.732342] 17137 DEBUG (H:localhost.local:36) Workload: d32b8b4774d5fc8ddd77c2ee250e22e11ff630f6
[2012-01-18 09:58:47.732393] 17137 DEBUG (H:localhost.local:36) Calling function for convert_job.
[2012-01-18 09:58:47.732463] 17137 WORKER (H:localhost.local:36) convert requested
[2012-01-18 09:58:47.732561] 17137 DEBUG (H:localhost.local:36)
[2012-01-18 09:59:13.321011] 16924 PROC Child 17137 exited (convert_job)
[2012-01-18 09:59:13.321735] 16924 DEBUG Registering signals for child
[2012-01-18 09:59:13.322242] 17177 WORKER Adding server 127.0.0.1
[2012-01-18 09:59:13.322394] 17177 WORKER Adding job convert_job
[2012-01-18 09:59:13.322665] 16924 PROC Started child 17177 (convert_job)
[2012-01-18 09:59:13.323583] 17177 WORKER (H:localhost.local:37) Starting Job: convert_job
[2012-01-18 09:59:13.323633] 17177 DEBUG (H:localhost.local:37) Workload: 1d29380cb77304a882282d1b20f7b8269e4eb248
[2012-01-18 09:59:13.323671] 17177 DEBUG (H:localhost.local:37) Calling function for convert_job.
[2012-01-18 09:59:13.323735] 17177 WORKER (H:localhost.local:37) convert requested
[2012-01-18 09:59:13.323792] 17177 DEBUG (H:localhost.local:37)
[2012-01-18 09:59:27.829840] 16924 PROC Child 17177 exited (convert_job)
[2012-01-18 09:59:27.830391] 16924 DEBUG Registering signals for child
[2012-01-18 09:59:27.830688] 17206 WORKER Adding server 127.0.0.1
[2012-01-18 09:59:27.830824] 17206 WORKER Adding job convert_job
[2012-01-18 09:59:27.831086] 16924 PROC Started child 17206 (convert_job)
[2012-01-18 09:59:27.831934] 17206 WORKER (H:localhost.local:38) Starting Job: convert_job
[2012-01-18 09:59:27.831974] 17206 DEBUG (H:localhost.local:38) Workload: 1505aa7cc978870221300cf3f518f5cb0ca5574b
[2012-01-18 09:59:27.832001] 17206 DEBUG (H:localhost.local:38) Calling function for convert_job.
[2012-01-18 09:59:27.832050] 17206 WORKER (H:localhost.local:38) convert requested
[2012-01-18 09:59:27.832167] 17206 DEBUG (H:localhost.local:38)
[2012-01-18 09:59:51.582747] 16924 PROC Child 17206 exited (convert_job)
[2012-01-18 09:59:51.583274] 16924 DEBUG Registering signals for child
[2012-01-18 09:59:51.583572] 17245 WORKER Adding server 127.0.0.1
[2012-01-18 09:59:51.583707] 17245 WORKER Adding job convert_job
[2012-01-18 09:59:51.583962] 16924 PROC Started child 17245 (convert_job)
[2012-01-18 09:59:51.584556] 17245 WORKER (H:localhost.local:39) Starting Job: convert_job
[2012-01-18 09:59:51.584593] 17245 DEBUG (H:localhost.local:39) Workload: cd8ca87a85ad53b5d34b1c0dd835a718ac9fcaa5
[2012-01-18 09:59:51.584619] 17245 DEBUG (H:localhost.local:39) Calling function for convert_job.
[2012-01-18 09:59:51.584685] 17245 WORKER (H:localhost.local:39) convert requested
[2012-01-18 09:59:51.584732] 17245 DEBUG (H:localhost.local:39)
[2012-01-18 10:00:30.311528] 16924 PROC Child 17245 exited (convert_job)
[2012-01-18 10:00:30.312212] 16924 DEBUG Registering signals for child
[2012-01-18 10:00:30.312675] 17300 WORKER Adding server 127.0.0.1
[2012-01-18 10:00:30.312872] 17300 WORKER Adding job convert_job
[2012-01-18 10:00:30.313160] 16924 PROC Started child 17300 (convert_job)
[2012-01-18 10:00:30.313908] 17300 WORKER (H:localhost.local:40) Starting Job: convert_job
[2012-01-18 10:00:30.314267] 17300 DEBUG (H:localhost.local:40) Workload: 10e7b7ae31577fad6ba4e7eb0be5726b27a98434
[2012-01-18 10:00:30.314312] 17300 DEBUG (H:localhost.local:40) Calling function for convert_job.
[2012-01-18 10:00:30.314378] 17300 WORKER (H:localhost.local:40) convert requested
[2012-01-18 10:00:30.314593] 17300 DEBUG (H:localhost.local:40)

Hi,

when the gearman manager is started with the -a parameter, all files that are present at start time will be checked for changes.
But when you add an additional worker file, this file will be ignored.

We tried a workaround with $this->load_workers(); in every iteration of the check_code loop, but there is something still missing.

we are looking into this, but maybe an "official" fix, would be much better ;)

thanks in advance

@brianlmoon
I have a worker, and in the run function I'm trying to get an environment variable using getenv('VARNAME'). This seems to be returning an empty string, although I know the environment variable exists and is set. In my shell terminal I echo $VARNAME and get the result I expect, I also use getenv('VARNAME') outside of my workers in other parts of my code and it works there as well. Is there some reason why I could not be able to use this in my worker?

Hi,

When using GearmanManager with a gearman PECL extension 1.0.0 or 1.0.1 (which are considered stable by PECL), GearmanManager won't start, and omit this error repeatedly until stopped:

Assertion "packet->universal" failed for function "gearman_packet_free" likely for "Packet that is being freed has not been allocated, most likely this is do to freeing a gearman_task_st or other object twice", at libgearman/packet.cc:256

gearmand is 0.2.6.

Any help would be much appreciated.

Thanks,
Bar.