Fix orphan workers on restart

[dan-jensen]

If 1 daemonized DJ worker is running and you execute restart with a
different n value, the existing worker will effectively be orphaned, in
that it continues to run through future stop/start/restart commands
with the new n value. The opposite is also true. If you change from an
n value of 2+ to 1 when you restart then the running workers will be
orphaned. This fixes that problem by looking in the pid_dir to identify
all worker process names and stopping them ALL prior to starting n new
workers.

This is a proposal for resolving #1091. Comments and alternative proposals very welcome.

[dan-jensen]

Would love to hear your thoughts on this, @albus522.

[albus522]

People do start/stop/restart independent groups of workers. So having restart stop anything it can find running would stop more than intended for certain use cases. A warning that additional workers may still be running might be all we can do here.

[dan-jensen]

Hey thanks for the quick response, @albus522!

I could be wrong, but I think the existing code would stop more than intended in the case of independent groups of workers. Specifically, Delayed Job will stop everything with a process name of "delayed_job.#{worker_index}" (line 103/104 in this changeset). In fact, I think this change would actually improve that behavior. Because it relies on worker-specific PIDs instead of a shared naming convention, it won't stop workers running in the context of another project.

[albus522]

Look above to the identifier section. That uses the same "delayed_job.*" structure.

[dan-jensen]

@albus522, I'm sorry, I don't understand what you're getting at. I see you're talking about the section starting on line 93. But are you saying this changeset would introduce a problem with the use of the identifier argument?