Thanks for all the discussion both on list and on irc. After more investigation, it sounds like there are no feature gaps, but we will need to incorporate this workaround <https://github.com/rq/rq/issues/684#issuecomment-352152369> to cancel a task that is already running.
The feedback I've heard on the idea is that it's valuable and looks feasible, but we won't really know until we prototype it a bit. Based on the technical outline in the previous email, I believe it can be prototyped in a day or two. I plan to do this soon, once I contribute to a few other required-for-beta planning items first. I'll post my PR to see what other think of the change, probably next week. On Wed, Mar 21, 2018 at 6:41 PM, Daniel Alley <dal...@redhat.com> wrote: > I meant in the sense that, what is the aftermath when it comes back > online, and is it screwed up in ways that cause side effects. > > On Wed, Mar 21, 2018 at 5:02 PM, Jeremy Audet <jau...@redhat.com> wrote: > >> > RQ does not support revoking tasks. If you send the worker a SIGINT, >> it will finish the task and then stop processing new ones. If you send the >> worker SIGKILL, it will stop immediately, but I don't think it gracefully >> handles this circumstance. >> >> Nothing handles SIGKILL gracefully. Processes can't catch that signal. >> `kill -9 $pid` sends SIGKILL. >> >> If one is looking for a way to gracefully, immediately kill an RQ >> worker, then SIGTERM may do the trick. Anecdotally, many processes >> handle this signal in a hurried fashion. Semantically, this is >> appropriate: SIGINT is the "terminal interrupt" signal (Ctrl+c sends >> SIGINT), whereas SIGTERM is the "termination signal." >> > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
