You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nov 04 19:50:06 ip-10-172-65-227 qdone[12283]: AWS.SimpleQueueService.NonExistentQueue:
...
Nov 04 19:50:06 ip-10-172-65-227 systemd[1]: qdone-chunker.service: Main process exited, code=exited, status=1/FAILURE
Nov 04 19:50:06 ip-10-172-65-227 systemd[1]: qdone-chunker.service: Unit entered failed state.
Nov 04 19:50:06 ip-10-172-65-227 systemd[1]: qdone-chunker.service: Failed with result 'exit-code'.
One gotcha with systemd integration is when qdone has no queues to listen on, it can fail faster than normal, causing systemd to move the unit to the failed state and not restart it.
This came up in a use case where we were deleting idle queues, and several weeks into deployment, a brief lull in job activity caused all queues to be deleted.
One gotcha with systemd integration is when qdone has no queues to listen on, it can fail faster than normal, causing systemd to move the unit to the failed state and not restart it.
This came up in a use case where we were deleting idle queues, and several weeks into deployment, a brief lull in job activity caused all queues to be deleted.
You can fix this with systemd config, but I'd prefer qdone behave consistently and not trip people up.
The default behavior should be to listen for
--wait-time
seconds, even if there are no queues to listen on.The text was updated successfully, but these errors were encountered: