We have basically forked this module for our own needs in hosting_queue_runner, which is kind of unfortunate, but was necessary because we do not (yet?) use the standard Drupal queues for Aegir's queuing system.

So we had to roll our own.

In doing so, we have done several improvements, most of which are sitting in a development branch now, but may be of interest to you. Randomly thrown out there:

* making supervisord optional (by having the daemon restart itself automatically to reclaim memory)
* startup scripts (in init.d...)
* signal handling (SIGHUP reloads the server, but waits for running tasks to complete, server waits for task completion before obeying SIGINT)
* make the lifetime of the daemon customizable in the frontend

The code is in our module's git repository, more specifically the autorestart branch.

Comments

Anonymous’s picture

Anonymous (not verified) commented

cool, i'll take a look.

Anonymous’s picture

Anonymous (not verified) commented

looking at these features, i'm not sure i want any of them except the lifetime front end, and maybe some better signal handling.

i really, really don't like the idea of doing parent/child stuff in php, or init.d stuff directly for the script etc.

i'd rather leave that for supervisord (or something - supervisord is not required, just something that can do a similar job).

msonnabaum’s picture

msonnabaum commented

oops, wrong thread.

sdboyer’s picture

sdboyer commented
Status: Active » Needs work

agreed with @beejeebus - i'd prefer to have waiting_queue avoid parent/child process futzing. or at least, i would prefer its default implementation to avoid that, and instead rely on an external system for it (be that monit, supervisord, or whatever your poison).

however, i'd be open to allowing two separate runner implementations, one which does its own restarting per the mechanism you've put in hosting_queue_runner and tied to a separate drush command from the simpler one we have in waiting_queue right now. i do kinda agree that it should be possible for these two projects to become one, and that'd be a Good Thing.

that would entail updating the signal handling logic in hosting_queue_runner to utilize the class we've created.