magento2: MessageQueue cron runner repeatedly launches duplicate consumers when ps command is provided by Busybox
Preconditions (*)
- Magento 2.3.2
- Alpine Linux (or any distro using busybox to provide ps command)
- ps command provided by busybox (no procps installed)
- no php-posix module installed.
- Cron jobs setup
Steps to reproduce (*)
- ps -a
- Wait 5 minutes
- ps -a
Expected result (*)
- Only one set of consumers should be running.
Actual result (*)
- Every minute a new set of consumers is launched.
\Magento\MessageQueue\Model\Cron\ConsumersRunner
uses one of two ways to determine whether the consumers are already running or not.
php posix_getpgid($pid)
or
exec ps -p $pid
The check to make sure no consumers are running fails, and new consumers are launched, even though there are already consumers running.
The machine will expire shortly later when all memory is exhausted.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 17 (11 by maintainers)
@gwharton or @maderlock: out of curiosity: did you already test this with Magento 2.3.3? There were some changes done to how Magento checks if a consumer process is already running. I’m not sure if it would solve your problem, but it might …
The
ps -p
code has been removed in that same commitInstalling php7-posix module resolves the issue on alpine to get the posix functions working.
The documentation should be updated that it is now a requirement that either “ps -p $pid” or php’s posix extension is required.
The module should be a little more intelligent at determining what it should do if both methods fail, instead of just relaunching and killing the machine.
Ubuntu 19
Alpine with busybox only
Alpine with procps
The mechanism cannot detect the difference between ps being called with an unknown argument, or ps -p being called on a process id that doesnt exist. Both return 1. And installations using only busybox it fails altogether.
I’m getting the same problem of constantly spinning up consumers under Magento 2.3.2 on Amazon Linux.
Oddly, this has procps installed, so there must be some other reason it is not able to find the processes. It is writing to the .pid file, so I do not think this is a permissions problem.
@gwharton I was able to resolve a similar issue by adding
procps
to my alpine dependencies.