PHP daemon for managing gearman workers

Overview

Gearman Manager for PHP

PHP Requirements

  • PHP 5.5.9 (Tested with this version)
  • POSIX extension
  • Process Control extension
  • pecl/gearman or Net_Gearman

Why use GearmanManager

Running Gearman workers can be a tedious task. Many many files with the same lines of code over and over for creating a worker, connecting to a server, adding functions to the worker, etc. etc. The aim of GearmanManager is to make running workers more of an operational task and less of a development task.

The basic idea is that once deployed, all you need to do is write the code that actually does the work and not all the repetative worker setup. We do this by creating files that contain functions in a specified directory. The file names determine what functions are registered with the gearmand server. This greatly simplifies the function registration.

How it works

We start by deciding where our worker code will live. For this example, lets say we create a directory called worker_dir to hold all our worker code. We would then create files like these: (These examples use pecl/gearman syntax. For PEAR/Gearman see the example pear workers for minor differences)

Procedural:

# cat worker_dir/example_function.php

function example_function($job, &$log) {

    $workload = $job->workload();

    // do work on $job here as documented in pecl/gearman docs

    // Log is an array that is passed in by reference that can be
    // added to for logging data that is not part of the return data
    $log[] = "Success";

    // return your result for the client
    return $result;

}

The existence of this code would register a function named example_function with the gearmand server.

Object Oriented:

# cat worker_dir/ExampleFunction.php

class ExampleFunction {

    public function run($job, &$log) {

        $workload = $job->workload();

        // do work on $job here as documented in pecl/gearman docs

        // Log is an array that is passed in by reference that can be
        // added to for logging data that is not part of the return data
        $log[] = "Success";

        // return your result for the client
        return $result;

    }

}

The existence of this code would register a function named ExampleFunction with the gearmand server.

But wait! There's more

In addition to making worker creation easier, GearmanManager also provides process management. If a process dies, it restarts a new one in its place. You can also configure workers to die after a certain amount of time to prevent PHP from using too much memory.

Then there is the problem of pushing new code out to the servers. GearmanManager has an option to have it monitor the worker dir and restart the workers if it sees new code has been deployed to the server.

When shutting down GearmanManager, it will allow the worker processes to finish their work before exiting.

Advanced Stuff

While it easy to get going, you can do some advanced things with GearmanManager.

Configuring Workers

By default, GearmanManager ensures that there is at least one worker that knows how to do every job that has a file in the worker directory. To be clear, that means that by default a single process will be created for every function. This is obviously not ideal for most production systems. There are a few ways you can customize how many processes run for the functions.

The ini file for GearmanManager is divided into one or more sections. There is the global section [GearmanManager] and there can be one section per function. In the example above that would be [example_function] or [ExampleFunction]. For the global section there are several options. There are a couple of sample ini files in the code.

worker_dir - Defines the directory(s) where worker functions live. You can specify multiple directories by separating them with commas.

include - This is a list of worker functions that should be registered by this server. It can be * to include all functions defined in the worker directory. * is the default behavior if the option is not set.

count - This setting defines the minimum number of workers that should be running that will perform all functions. For example, if count is set to 10, 10 processes will be started that are registered for all the functions. This defaults to 0.

dedicated_count - This setting defines the number of processes that should be started that will be dedicated to do only one function for each function that will be registered. For example, if you have 5 functions in your worker directory and set dedicated_count = 2 there will be 2 processes started for each function, so 10 total processes for this work. This defaults to 1.

max_worker_lifetime - Set this value to the maximum number of seconds you want a worker to live before it dies. After finishing a job, the worker will check if it has been running past the max life time and if so, it will exit. The manager process will then replace it with a new worker that is registered to do the same jobs that the exiting process was doing. This defaults to 1 hour.

auto_update - If set to 1, the manager will fork a helper process that watches the worker directory for changes. If new code is found, a signal is sent to the parent process to kill the worker processes so that the new code can be loaded.

For each registered function, you can also specify some options for only those workers.

count - Setting this to some integer value will ensure there are that many workers that know how to do this function. It does not guarantee there will be a dedicated process, only that some process will register this function. The process may also register other functions as well.

dedicated_count - Setting this to some integer value will ensure there are that many processes started that are dedicated to only doing this function. The process will not do any other work than this function.

Logging Data

There are lots of options on the command line. See -h for all of them. Logging is one of those options. Because the loading of the config is logged, you have to specify logging information on the command line. There are two options you should be aware off.

-v This enables verbosity from the manager and workers. You can add more and more and more v's (-vvvv) to get more and more logged data. It scales up like this:

-v      Logs only information about the start up and shutdown
-vv     Logs information about process creation and exiting
-vvv    Logs information about workers and the work they are doing
-vvvv   Logs debug information
-vvvvv  Logs crazy amounts of data about all manner of things

-l You can specify a log file that log data will be sent to. If not set, log data will be sent to stdout. You can also set this to syslog to have the log data sent to syslog.

Specifying Gearmand Servers

You can specify servers in two ways. They can be specified on the command line or in the configuration file.

On the command line, you can specify -h [HOST[:PORT][,[HOST[:PORT]]]]. For example: -h 10.1.1.1:4730,10.1.1.2:4730

In the config file in the global [GearmanManager] section you can use these options:

host - The hosts and ports separated by commas. e.g. 10.1.1.1:4730,10.1.1.2:4730

Running the daemon

Minimal command line is:

# ./pecl-manager.php -c /path/to/config.ini

There are some more command line options that are handy for running the daemon.

-P - The location where the pid file should be stored for the manager process. Also setable with pid_file in the ini file.

-d - If set on the command line, the manager will daemonize

-u - The user to run the daemon as. You can also use user in the ini file.

Debugging

So you built an awesome worker but for some reason it dies and the error_log is empty?

GearmanManager makes use of the supression operator (@) every now and then which makes it a little harder to debug because error messages are silenced.

The solution is Xdebug's scream and the steps to set it up are:

  1. Install Xdebug
  2. Configure it
  3. Profit!

Installation

pecl install xdebug

Configuration

Put the following into your xdebug.ini:

zend_extension="/path/to/where/your/xdebug.so"
xdebug.scream = 1
xdebug.show_exception_trace = 1
Comments
  • Support for includes and more in worker files

    Support for includes and more in worker files

    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.

    opened by chaud 11
  • Gearman-manager processes take 100% CPU even with no jobs running

    Gearman-manager processes take 100% CPU even with no jobs running

    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.

    opened by bartzy 11
  • PHP warning makes debugging a chore

    PHP warning makes debugging a chore

    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
    
    opened by c2h5oh 10
  • Worker exits after every job

    Worker exits after every job

    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)

    opened by littleape 10
  • getopt empty

    getopt empty

    Hello, I've recently installed GearmanManager on a CloudLinux Server release 6.6 X-Powered-By PHP/5.4.39 and it wasn't able to find the ./workers dir. I soon realized that none of the parameters was passed to the script.

    /etc/rc.d/init.d/gearman-manager correctly try to daemonize the script with deamon --pidfile=/var/run/gearman/manager.pid /usr/local/bin/gearman-manager -P /var/run/gearman/manager.pid -l /var/log/gearman-manager.log -u gearmand -d -c /etc/gearman-manager/config.ini

    In /usr/local/share/gearman-manager/pecl-manager.php I've then placed exit(var_dump(getopt("ac:dD:h:Hl:o:p:P:u:v::w:r:x:Z"))); and its output is:

    bool(false)
    

    However exit(var_dump($argv)); outputs:

    array(10) {
      [0] => string(30) "/usr/local/bin/gearman-manager"
      [1] => string(2) "-P"
      [2] => string(28) "/var/run/gearman/manager.pid"
      [3] => string(2) "-l"
      [4] => string(28) "/var/log/gearman-manager.log"
      [5] => string(2) "-u"
      [6] => string(8) "gearmand"
      [7] => string(2) "-d"
      [8] => string(2) "-c"
      [9] => string(31) "/etc/gearman-manager/config.ini"
    }
    
    opened by NanoCaiordo 9
  • Gearman server stucks in case of death of  worker

    Gearman server stucks in case of death of worker

    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());
    }
    
    ?>
    
    opened by AlexeyOrlenko 8
  • Worker permissions

    Worker permissions

    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

    opened by littleape 8
  • Support for multiple config files, and for directories of config files

    Support for multiple config files, and for directories of config files

    I have multiple projects in multiple directories with worker code, so I've been symlinking their workers into the GearmanManager worker directory, but found the need to configure how many of said workers I need for each project. So I modified GearmanManager::getopt and GearmanManager::parse_config to support multiple -c flags so that it accepts multiple config files specified:

    $ ./pecl-manager.php -c /var/www/project1/gmanc.ini -c /var/www/project2/gmanc.ini
    

    I also had it support config directories, so if you specify a directory, it globs for .ini or .php files while safely ignoring any other files in said directory:

    $ ls /var/www/project3/gmanc/
    config.ini  config.php  notaconfig.txt
    $ ./pecl-manager.php -c /var/www/project3/gmanc/
    

    Note that these changes also change the signature of parse_config's args from void parse_config(string $file) to void parse_config(Array $files), so it could affect anything that inherits GearmanManager and tries to overload parse_config

    opened by EvanK 8
  • The count param in config.ini is not works

    The count param in config.ini is not works

    [GearmanManager] ; workers can be found in this dir worker_dir= XXXXXXXXX

    ; Reload workers as new code is available auto_update=1 count=10

    I have set 10 worker to do the job,but why is only 1 worker start? qq 20150512185235

    opened by gzldx 7
  • socket_select(): unable to select [4]: Interrupted system call

    socket_select(): unable to select [4]: Interrupted system call

    [31-Oct-2012 00:46:06 UTC] PHP Warning:  socket_select(): unable to select [4]: Interrupted system call in /usr/share/php/Net/Gearman/Worker.php on line 243
    [31-Oct-2012 00:46:06 UTC] PHP Stack trace:
    [31-Oct-2012 00:46:06 UTC] PHP   1. {main}() /usr/local/share/gearman-manager/pear-manager.php:0
    [31-Oct-2012 00:46:06 UTC] PHP   2. GearmanManager->__construct() /usr/local/share/gearman-manager/pear-manager.php:219
    [31-Oct-2012 00:46:06 UTC] PHP   3. GearmanManager->bootstrap() /usr/local/share/gearman-manager/GearmanManager.php:250
    [31-Oct-2012 00:46:06 UTC] PHP   4. GearmanManager->start_worker() /usr/local/share/gearman-manager/GearmanManager.php:820
    [31-Oct-2012 00:46:06 UTC] PHP   5. GearmanPearManager->start_lib_worker() /usr/local/share/gearman-manager/GearmanManager.php:877
    [31-Oct-2012 00:46:06 UTC] PHP   6. Net_Gearman_Worker->beginWork() /usr/local/share/gearman-manager/pear-manager.php:69
    [31-Oct-2012 00:46:06 UTC] PHP   7. socket_select() /usr/share/php/Net/Gearman/Worker.php:243
    
    opened by akagomez 7
  • Startup Script Not Working

    Startup Script Not Working

    Hi,

    I'm trying to use Gearman Manager to start up my workers as the system boots. I'm on (bitnami) Ubuntu 12.04 and have copied the deb.sh script from /install into etc/init.d and called it "gearman-manager".

    I have run update-rc.d and see the various symlinks ok in the various etc/rcX.d directories. I have set the gearman-manager to run at 80, to make sure it runs after the gearmand daemon is started (which starts at 20 by default).

    Log file and Config file seem to be set up ok, in that when I run:

    service gearman-manager start

    then my workers are registered, my log file says:

    Type Message PROC User set to root DEBUG Registering signals for parent INFO Loading workers in /var/gearman/GearmanManager/pecl-workers PROC Helper forked with pid 1818 INFO Loading workers in /var/gearman/GearmanManager/pecl-workers

    and I see two php.bin processes running (I guess they are called "php.bin" this because they are running in the php interpreter as pecl-manager.php is not a binary executable).

    However, on startup, if I use this snippet in my start() function in my service definition:

    if start-stop-daemon
    --start
    --startas $DAEMON \ (this points to pecl-manager.php) --verbose
    --pidfile $PIDFILE
    -- -l $LOGFILE
    -u $GEARMANUSER \ (am using root) -d
    -v
    $PARAMS; log_daemon_msg "Daemon called...\r"; then log_end_msg 0 else log_end_msg 1 log_warning_msg "Please take a look at the syslog" exit 1 fi

    then whilst there are no error messages in boot.log or anywhere else I can find, there is also no gearman_manager.pid file in the process directory, and my workers are not active and jobs don't work either.

    If I instead use this snippet in my start() function in my service definition (ie don't bother with the fancy start-stop-daemon script):

    ${DAEMON} -P ${PIDFILE} -c ${CONFIGFILE} -l ${LOGFILE} -vvvvv -u ${GEARMANUSER}

    I get errors in the boot.log as follows (render_server.php is my worker code and it tries to instantiate class GearmanWorker at line 1:

     PHP Fatal error: Class 'GearmanWorker' not found in /var/gearman/GearmanManager/pecl-workers/render_server.php on line 12 PHP Stack trace: PHP 1. {main}() /var/gearman/GearmanManager/pecl-manager.php:0

    etc

    So I'm stumped. I have checked that gearman is properly registered in my php runtime. Can anyone suggest how to get the manager to start at boot?

    Cheers, Andy

    opened by squiggel1 6
  • timeout is milliseconds in gearmand 1.1.19

    timeout is milliseconds in gearmand 1.1.19

    https://github.com/brianlmoon/GearmanManager/blob/69df37005e0dd774ecb55080e2348da5c3a18c19/etc/config-advanced.ini#L33

    Hello, this timeout is supposed to be used in milliseconds as of german 1.1.19 https://github.com/gearman/gearmand/issues/196

    We had the problem that for all workers that take longer than ~1 second the gearman service did return "work_fail = 14" to the client. After changing this value to 300000 instead of 300 we had the behaviour like in 1.1.18

    Regards

    Upstream 
    opened by Nibbels 1
  • Adds ability to configure the shutdown timeout

    Adds ability to configure the shutdown timeout

    Adds a configuration setting for setting the shutdown timer through a config (from 60s hardcoded to config setting), such that it can be adjusted in production environments where container deployments or tasks are not hard-interrupted during a deploy.

    opened by ChristopherGC 0
  • Odd solution to workers not wanting to stop with SIGTERM

    Odd solution to workers not wanting to stop with SIGTERM

    I've been a longtime user of gearman-manager, thank you for your work on this!

    Background: Just updated a worker server from centos 6.5 to 7.5. I noticed ^C (killing the manager while running in the foreground, and even background use) would cause the manager to hang until 60 seconds, when it will just forcefully kill the workers. Normally the workers will shutdown gracefully in a few seconds.

    I was having a difficult time finding a solution, however, finally I just randomly added a line of code in the start_lib_worker method in GearmanPeclManager.php, and now GM will shutdown nicely.

            while(!$this->stop_work){
    
                if(@$thisWorker->work() ||
                   $thisWorker->returnCode() == GEARMAN_IO_WAIT ||
                   $thisWorker->returnCode() == GEARMAN_NO_JOBS) {
    
                    if ($thisWorker->returnCode() == GEARMAN_SUCCESS) continue;
    
                    if (!@$thisWorker->wait()){
                        if ($thisWorker->returnCode() == GEARMAN_NO_ACTIVE_FDS){
                            sleep(5);
                        }
                    }
    
                }
    
                /**
                 * Check the running time of the current child. If it has
                 * been too long, stop working.
                 */
                if($this->max_run_time > 0 && time() - $start > $this->max_run_time) {
                    $this->log("Been running too long, exiting", GearmanManager::LOG_LEVEL_WORKER_INFO);
                    $this->stop_work = true;
                }
    
                if(!empty($this->config["max_runs_per_worker"]) && $this->job_execution_count >= $this->config["max_runs_per_worker"]) {
                    $this->log("Ran $this->job_execution_count jobs which is over the maximum({$this->config['max_runs_per_worker']}), exiting", GearmanManager::LOG_LEVEL_WORKER_INFO);
                    $this->stop_work = true;
                }
    
            }
    

    Adding any sort of line to evaluate does the trick:

            while(!$this->stop_work){
    
                if(@$thisWorker->work() ||
                   $thisWorker->returnCode() == GEARMAN_IO_WAIT ||
                   $thisWorker->returnCode() == GEARMAN_NO_JOBS) {
    
                    if ($thisWorker->returnCode() == GEARMAN_SUCCESS) continue;
    
                    if (!@$thisWorker->wait()){
                        if ($thisWorker->returnCode() == GEARMAN_NO_ACTIVE_FDS){
                            sleep(5);
                        }
                    }
    
                }
    
                /**
                 * Check the running time of the current child. If it has
                 * been too long, stop working.
                 */
                if($this->max_run_time > 0 && time() - $start > $this->max_run_time) {
                    $this->log("Been running too long, exiting", GearmanManager::LOG_LEVEL_WORKER_INFO);
                    $this->stop_work = true;
                }
    
                if(!empty($this->config["max_runs_per_worker"]) && $this->job_execution_count >= $this->config["max_runs_per_worker"]) {
                    $this->log("Ran $this->job_execution_count jobs which is over the maximum({$this->config['max_runs_per_worker']}), exiting", GearmanManager::LOG_LEVEL_WORKER_INFO);
                    $this->stop_work = true;
                }
    
            $true = false; # some extra code
            }
    

    This is the most bizarre behavior I've witnessed, particularly since it doesn't output/echo any new characters or do anything at the IO level.

    Do you have any possible explanation as to why doing this allows gearman manager to exit gracefully rather than having to SIGKILL the entire process? I tried running this on the v2 tag and v1 tag and the behavior is the same. I'm also running PHP 7.

    Thanks!

    opened by ghost 9
  • Listen on a TCP/UDP port for restart commands

    Listen on a TCP/UDP port for restart commands

    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.

    Feature Request 
    opened by brianlmoon 2
  • Auto apply config changes & ability to terminate all processes of a specific worker type

    Auto apply config changes & ability to terminate all processes of a specific worker type

    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

    Feature Request 
    opened by pjc23 2
Releases(2.1.1)
  • 2.1.1(Mar 6, 2017)

  • 2.1.0(Feb 3, 2017)

    The minor version has been bumped due to files moving around. If you upgrade to this version and you were including files manually, you will need to change those paths.

    • Refactored the directory structure so that autoloading via composer would work correctly.
    • Added required PHP extensions to the composer file
    Source code(tar.gz)
    Source code(zip)
  • 2.0.1(Feb 3, 2017)

  • 2.0.0-alpha(Sep 28, 2015)

    This is an alpha release of GearmanManager version 2. The code has been reorganized. In addition, many changes have been merged in based on a high volume of use at DealNews.com.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Oct 10, 2014)

Version is a library that helps with managing the version number of Git-hosted PHP projects

Version Version is a library that helps with managing the version number of Git-hosted PHP projects. Installation You can add this library as a local,

Sebastian Bergmann 6.3k Dec 26, 2022
A tool for managing SSH key access to any number of servers.

Revons - SSH Key Authority Features Easily manage SSH key access for all accounts on your servers. Manage user access and server-to-server access rule

Revons Community 1 Mar 14, 2022
A simple mini pos that handles managing product data's and product categories

What is CodeIgniter CodeIgniter is an Application Development Framework - a toolkit - for people who build web sites using PHP. Its goal is to enable

Mahendra Dwi Purwanto 0 Dec 26, 2021
Smd imagery - A Textpattern CMS plugin for managing images in the Write panel.

smd_imagery Insert images into your Write panel. Very handy for people who run photoblog or image-heavy sites, or those who categorise images for incl

Stef Dawson 5 Nov 15, 2022
Sspak - Tool for managing bundles of db/assets from SilverStripe environments

SSPak SSPak is a SilverStripe tool for managing database and assets content, for back-up, restoration, or transfer between environments. The file form

Silverstripe CMS 45 Dec 14, 2022
An application for building and managing Phars.

An application for building and managing Phars.

Box Project 1.2k Nov 9, 2022
A high-performance license server system service for creating and managing products, major versions, and software licenses for the purpose of selling installable software products.

A high-performance license server system service for creating and managing products, major versions, and software licenses for the purpose of selling installable software products. Comes with a SDK and command-line tool. Works anywhere that PHP runs.

CubicleSoft 32 Dec 5, 2022
TEC UTilities (or tut) are a collection of tools for managing plugins.

TEC Utilities TEC UTilities (or tut) are a collection of tools for managing plugins. /^\ L L /

The Events Calendar 5 Dec 2, 2022
The Current US Version of PHP-Nuke Evolution Xtreme v3.0.1b-beta often known as Nuke-Evolution Xtreme. This is a hardened version of PHP-Nuke and is secure and safe. We are currently porting Xtreme over to PHP 8.0.3

2021 Nightly Builds Repository PHP-Nuke Evolution Xtreme Developers TheGhost - Ernest Allen Buffington (Lead Developer) SeaBeast08 - Sebastian Scott B

Ernest Buffington 7 Aug 28, 2022
A sampling profiler for PHP written in PHP, which reads information about running PHP VM from outside of the process.

Reli Reli is a sampling profiler (or a VM state inspector) written in PHP. It can read information about running PHP script from outside of the proces

null 272 Dec 22, 2022
PHP Meminfo is a PHP extension that gives you insights on the PHP memory content

MEMINFO PHP Meminfo is a PHP extension that gives you insights on the PHP memory content. Its main goal is to help you understand memory leaks: by loo

Benoit Jacquemont 994 Dec 29, 2022
A sampling profiler for PHP written in PHP, which reads information about running PHP VM from outside of the process.

Reli Reli is a sampling profiler (or a VM state inspector) written in PHP. It can read information about running PHP script from outside of the proces

null 258 Sep 15, 2022
A multithreaded application server for PHP, written in PHP.

appserver.io, a PHP application server This is the main repository for the appserver.io project. What is appserver.io appserver.io is a multithreaded

appserver.io 951 Dec 25, 2022
Easy to use utility functions for everyday PHP projects. This is a port of the Lodash JS library to PHP

Lodash-PHP Lodash-PHP is a port of the Lodash JS library to PHP. It is a set of easy to use utility functions for everyday PHP projects. Lodash-PHP tr

Lodash PHP 474 Dec 31, 2022
A PHP 5.3+ and PHP 7.3 framework for OpenGraph Protocol

Opengraph Test with Atoum cd Opengraph/ curl -s https://getcomposer.org/installer | php php composer.phar install --dev ./vendor/atoum/atoum/bin/atoum

Axel Etcheverry 89 Dec 27, 2022
A status monitor for Elite Dangerous, written in PHP. Designed for 1080p screens in the four-panel-view in panel.php, and for 7 inch screens with a resolution of 1024x600 connected to a Raspberry Pi.

EDStatusPanel A status monitor for Elite Dangerous, written in PHP. Designed for 1080p screens in the four-panel-view in panel.php, and for 7 inch scr

marcus-s 24 Oct 4, 2022
🐘 A probe program for PHP environment (一款精美的 PHP 探針, 又名X探針、劉海探針)

Simplified Chinese | 简体中文 Traditional Chinese(Taiwan) | 正體中文(臺灣) Traditional Chinese(Hong Kong) | 正體中文(香港) Japanese | 日本語 ?? X Prober This is a probe

Km.Van 1.2k Dec 28, 2022
PHP Text Analysis is a library for performing Information Retrieval (IR) and Natural Language Processing (NLP) tasks using the PHP language

php-text-analysis PHP Text Analysis is a library for performing Information Retrieval (IR) and Natural Language Processing (NLP) tasks using the PHP l

null 464 Dec 28, 2022
PHP generics written in PHP

PHP generics written in PHP Require PHP >= 7.4 Composer (PSR-4 Autoload) Table of contents How it works Quick start Example Features Tests How it work

Anton Sukhachev 173 Dec 30, 2022