Indatus / dispatcher

Dispatcher is a Laravel artisan command scheduling tool used to schedule artisan commands within your project so you don't need to touch your crontab when deploying.
MIT License
1.06k stars 70 forks source link

Sleeping processes not being killed? #142

Closed inctor closed 8 years ago

inctor commented 8 years ago

Hey,

We've been using this package for a while now, and we love it.

We're sadly stuck in Laravel 4.2 for a while, but we've begun running into some issues.

We have some clients, each client has their own Codebase‚ and therefore their own Schedule-command to run.

I've noticed that the process is not always being killed properly after the check has finished.

We've added it to /etc/crontab like this: */5 * * * * forge php /data01/Source-share/clients/team/artisan scheduled:run 1>> /dev/null 2>&1

We've set it to every 5 minutes, otherwise the server is killing itself after a short while.

But when i look at "sleeping processes", every time it has run, the numbers just climbs and climbs without being killed again, which makes the load-average ever-increasing.

And looking at "ps axjf" to get a tree view of the processes,

32831 33379 32831 32831 ?           -1 S        0   0:00  \_ CRON
33379 33418 33418 33418 ?           -1 Ss    1001   0:00  |   \_ /bin/sh -c php /data01/Source-share/clients/team/artisan scheduled:run 1>> /dev/null 2>&1
33418 33449 33418 33418 ?           -1 D     1001   0:00  |       \_ php /data01/Source-share/clients/team/artisan scheduled:run

And then it stays as a sleeping process without being removed, and just adds new ones, each time the cron is being executed.

We have about 30'ish codebases now, which are all close to identical apart from a few config settings unrelated to the commands being run, and our schedule server is being pounded down by this.

Is this an issue with how this package works, or some server-configuration issue?

inctor commented 8 years ago

I've isolated the issue somewhat now.

For some reason, the process it spawns "/bin/sh -c php .....", if there is no quotation marks around the actual php-command, it just never dies and goes to sleep.

If i add quotation marks, it finished the job as expected and kills itself..

However this doesn't function as expected through the cronjob.. It just ends up writing; /bin/sh: 1: php /data01/Source-share/clients/team/artisan scheduled:run --debug: not found

However, if i copy and run it manually it works as expected.

inctor commented 8 years ago

I realize this is most likely a server-related issue, and not because of this package. Here's what i've tried so far, without luck:

I put it in /etc/crontab, i used tabs instead of spaces, i added php to the PATH of /etc/crontab, added quotation marks around the actual command in /etc/crontab, both single and double quotes.

All above, even combined in various different ways haven't resolved it.

I'll be closing this ticket, but hope that someone drops by, who might have some knowledge on it, to nudge me in the right direction to fix this.

inctor commented 8 years ago

Alright.

So i managed to resolve the issue. Not entirely sure.

But i removed the Null-pipe and used --debug instead to get some output, and disabled mail-sending in CRON.

Now they are executed and "killed" as they usually have.

Might be related to PHP7.0 handling it differently than PHP5 or HHVM?

inctor commented 8 years ago

I was mistaken. It actually still doesn't work with a large quantity of requests.

It seems to work as expected with a few crons being fired off, but when it have to dispatch many of them at once, it breaks for some reason.

bkuhl commented 8 years ago

I want to comment so you're aware I saw this, but I don't plan to continue to maintain this package since scheduling is now a part of the core of Laravel. If you find a solution for the issue you have, I'd be happy to release a patch if it's non-breaking.