Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zombie processes inside scheduler container for runInBackground() tasks #50

Closed
varemel opened this issue Jan 13, 2024 · 1 comment
Closed

Comments

@varemel
Copy link

varemel commented Jan 13, 2024

Initially I run scheduler inside app container and there was no problem with zombie processes. After I move scheduler to separate container, problem appered.

As I understand this process in simple words:
Laravel schedule:run spawn child process for each runInBackground() task and quits. Tasks become zombie (orphan processes = with no parent process) after completion, because supercronic (main init process in container) seems to doesn't know how to 'reap' orphan child processes or doesn't have to.

Screenshot 2024-01-13 at 04 36 01

More on PID 1 zombie reaping problem - https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

My suggestion is to run scheduler container inside supervisord

start-container

...
elif [ ${container_mode} = "scheduler" ]; then
    initialStuff
    php artisan schedule:clear-cache
    # exec supercronic -overlapping /etc/supercronic/laravel
    exec /usr/bin/supervisord -c /etc/supervisor/conf.d/supervisord.scheduler.conf
...

supervisord.scheduler.conf

[supervisord]
nodaemon=true
user=%(ENV_NON_ROOT_USER)s
logfile=/var/log/supervisor/supervisord.log
# use /var/log, because user has no write permissions to write to /var/run (symlink to /run)
pidfile=/var/log/supervisord.pid

[program:scheduler]
process_name=%(program_name)s_%(process_num)02d
command=supercronic -overlapping /etc/supercronic/laravel
user=%(ENV_NON_ROOT_USER)s
autostart=%(ENV_APP_WITH_SCHEDULER)s
autorestart=true
stdout_logfile=/var/www/html/scheduler.log

I checked this config, and it seems that problem is gone.

@smortexa
Copy link
Member

Thanks for your feedbacks! I think that's a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants