Log errors on gcr - Uncaught signal 14 (Alarm clock)

[illambo]

Laravel Version: 11.34.2
PHP Version: 8.2
stackkit/laravel-google-cloud-tasks-queue Version: 4.2.1

Hi, on gcr I'm seeing this type of errors related to the POST call on /handle-task:

Uncaught signal: 14, pid=43, tid=43, fault_addr=0.
[core:notice] [pid 1:tid 1] AH00052: child pid 3563 exit signal Alarm clock (14)

They seem to be related to the timeout management (signal SIGALRM 14) regulated by the $timeout parameter of the jobs (default laravel 60s).
The jobs are processed correctly and also the related responses to the scheduler but it seems that the process remains active for the duration of the timeout and then exits with an error.

Do you also see this behavior or could it be something related to the docker image? The pcntl extension appears to be activated correctly.

Thanks.

[jfradj]

Hello,

I'm seeing the same errors on my Google App Engine application:

I can't say what's the precise issue but I can 100% affirm is related to the library.
Indeed, I've create cloud tasks by hand on an API (instead of using job dispatch and the library) and everything is working as intended. Tasks are being processed successfully and no AppEngine instances are being killed.
So probably not related to docker, image or pcntl.

@marickvantuil any idea 🙏 ?

Thanks

[marickvantuil]

Thanks for the report. I've been debugging this issue the past few days and I've come to the conclusion that the pcntl functions don't play nice with the Cloud Run/AppEngine environment. I've tested this with Cloud Run with both this package and a dummy application that uses phpunit/php-invoker (package with similar timout management using pcntl extension too) and both have the same uncaught signal issue in Cloud Run.

Apparently the pcntl extension is more meant for cli processes and not so much for web requests. So knowing that, I'm currently working on an alternative solution based on set_time_limit. It needs some more testing but my initial testing looked promising. In case you're willing to help me verify, version v4.2.3-beta.5 can be used to test (the previous beta versions were attempts to make pcntl work 🙃).

[illambo]

Thanks @marickvantuil i can test around january 7th.
Thanks again for the help!

[jfradj]

@marickvantuil I finally came to the conclusion that trying to make Google Cloud Task a Laravel job provider is like trying to fit a square peg into a round hole. They're way too different.
I spent almost a full week on this subject, trying every open-source library without getting it to work or feeling confident about the quality and coherence.
That's why I finally coded my own library, which is heavily inspired by the Laravel's jobs but without relying on it at all.

I can create and pushed a task just like that:

ProcessStripeWebhook::dispatch($request->all())
            ->withTaskId($signature)
            ->onQueue('stripe')
            ->delay(10)
        ;

I'm in a big rush right now but I planned to create an open-source library and a medium post to explain my point of view and how I created it.

[illambo]

Hi @marickvantuil, about set_time_limit:

Apparently the pcntl extension is more meant for cli processes and not so much for web requests. So knowing that, I'm currently working on an alternative solution based on set_time_limit.

I fear that it is not the most suitable solution as I read in spec:

The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, sleep, etc. is not included when determining the maximum time that the script has been running.

I try to verify the issue better, but if so I find it quite problematic in some scenarios.
What do you think?