Process ID should not be stored in configuration

A little bit confused about used branches (2.x vs. 2.0.x). Finally I've based on 2.0.x.

I confirm this is an issue.
In my environments, I use multiple docker containers with a shared database.
The process IDs are different on each container but the config stored in the database is shared.
Sometimes, PIDs are overlapping - so when I stop the runner, it would kill an unrelated process in another container.

Therefore, the PIDs should definitely not be stored in the Database - using the State API would not solve this issue.
Also, we should probably check that the process we kill is indeed a runner and not another task.

We should dynamically retrieve the process status and ID from the ps command.
Similarly to statusByPid but generic.

Maybe do a check on the running command itself ;
[17] => 268 www-data 0:00 php /var/www/html/web/modules/contrib/advancedqueue_runner/src/Scripts/jobs.php

We should dynamically retrieve the process status and ID from the ps command

If it's not stored, the functionality to restart after a crash will not work. I've created https://www.drupal.org/project/recurring_task → to make have a generic way to run tasks (not only queue) and there I've moved to state vars. I didn't think about database shared between many sites but we can work there to make that working (maybe such as prefixing with some site hash, or other way?)

Yes, we need to make sure the processes we generate are the only ones we stop - storing in the database can be a way to check but should not be the way to identify.

I'll look into your contrib. module soon. But for now, my only solution is to NEVER use the stop button as it may kill unwanted processes.
Thanks for your work on this. :)

If that module is doing what you need to do I’m willing to help to get the site-aware support. Please open a ticket there

I'll look into this. we use the PID to determine if the runner is active or not. We don't have the use case of multiple containers shared the database, so that's not an issue from my end. I'll looking into alternative way.