Properly get workers pids when running on SunOS.

[vadimcomanescu]

When getting worker pids on SunOS (OpenIndiana or any other Solaris derivative) the ps command does not support the arguments as on linux. So to be able to get the worker pids the command line arguments for ps need to be changed.

[danhunsaker]

On my Debian system, the output of ps -A -o pid,command is identical to the output of ps -A -o pid,args - and, indeed, the manpage for ps states that command is simply an alias for args. It also states that comm gives the unmodified (as in, without proctitle changes) version of the command name only (no arguments), which should always be php in this case...

Maybe we should simply switch completely over to the more widely-supported ps -A -o pid,args command line? I don't really like running exec() in the first place, but I dislike checking the OS even more; I prefer to check for functionality and go from there.

Of course, that's just me.

[danhunsaker]

This may not be the best place to discuss it, since it's not directly related to the changes being made here, but it involves the code being changed, so I'll bring it up while I'm at it. This function relies on either proctitle being installed and functioning, or the word resque appearing somewhere in the command line. While this isn't a problem, necessarily, my own projects abstract out the fact that Resque is behind the scenes and so that word is never included (and for some reason, my host doesn't properly honor the proctitle extension, though it is installed and enabled...) - which means my workers are never actually found. If I've done it, chances are others will do it, too.

It might be nice to mention this limitation (because there isn't an obvious clean fix) somewhere in the documentation so that implementers can be aware that either proctitle needs to work, or they need to have resque in their normal command line for this to work properly.

[Rockstar04]

Proctitle would not be needed for a PHP 5.5 implementation (cli_set_process_title), but I assume it will be YEARS before many area actually able to use 5.5 in their shared hosts.

[danhunsaker]

True on both counts. Though it would still have to work. No idea why the extension isn't working on this particular host; the bug might also affect 5.5's native implementation.

[danhunsaker]

Anyone else have any feedback on this? @chrisboulton?

[chrisboulton]

Maybe we should simply switch completely over to the more widely-supported ps -A -o pid,args command line? I don't really like running exec() in the first place, but I dislike checking the OS even more; I prefer to check for functionality and go from there.

I think I agree with this decision too, but then again Resque (2.0) itself has gone all out with separations for each OS variation which may be even safer in the long run: https://github.com/resque/resque/blob/master/lib/resque/process_coordinator.rb

[danhunsaker]

It may ultimately come down to how much we wish to emulate Ruby Resque:

• If the in-Redis data should be identical (allowing jobs to be enqueued from either system and run on whichever has the appropriate class, for example; note that extra data which Ruby Resque doesn't include is perfectly acceptable and beyond the scope of this stipulation either way), but the rest can be PHP-centric, then the correct approach would be whichever makes most sense with PHP, which tends toward detecting functionality rather than platform, since PHP doesn't always have reliable information from the host system.
• If, however, the goal is to be as close to the Ruby implementation as possible (a true port), then their approach is automatically the right one to take. In this case, at least.

Which approach we wish to take (either one of these [relative] extremes, or something elsewhere on the spectrum) isn't entirely clear at the moment. Obviously some aspects will need to be modified to account for PHP idiosyncrasies, but aside from those, how close to the Ruby implementation are we aiming?

[johannesnagl]

i think, to be as close to the ruby implementation as possible is the best way to go. in our situation we're using php-resque as queueing mechanism, and using the ruby resque as dashboard component. it works fine at the moment and hope, that this is not going to break in near future.

[danhunsaker]

@johannesnagl The only part that needs to be identical for that is the in-Redis stuff. Indeed, your exact setup is cited as one of the main reasons the in-Redis stuff is the way it is - so we don't have to reinvent the web interface as well. That aspect isn't likely to change in the foreseeable future.

[arturo-c]

maybe this should be an extensibility option like so:

protected $unix_flavor;

function set_unix_flavor(UnixInterface $unix) {
  $this->unix_flavor = $unix;
}

function get_worker_pids() {
  $this->unix_flavor->get_worker_pids();
}