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.

Sign up for GitHub

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

Jump to bottom

Scheduler does not work with PDF type #229

Closed
gianlucapiccolo opened this issue Mar 6, 2024 · 1 comment · Fixed by #231
Closed

Scheduler does not work with PDF type #229

gianlucapiccolo opened this issue Mar 6, 2024 · 1 comment · Fixed by #231
Labels
bug Something isn't working
Milestone
1.0.2

Comments

@gianlucapiccolo
Copy link

gianlucapiccolo commented Mar 6, 2024 •
edited

Describe the bug

When a report is scheduled to be sent via mail as a PDF, after the first iteration the scheduler stops to work.
The scheduled job to send the report PDF via mail breaks the scheduler, no jobs are executed anymore after that.

To Reproduce

Steps to reproduce the behavior:

  1. Import the attached reporting database (reporting-broken-scheduler.zip)
  2. Configure the pdfexport module to use the local Chrome binary (/usr/bin/google-chrome)
  3. Run icingacli reporting schedule run --debug
  4. Wait at least 3 minutes.
  5. Pay attention: the scheduler stops to execute next scheduled jobs after the first time.

Expected behavior

The scheduler should not stop after the first execution but it should continue to send the report as scheduled.

Your Environment

  • Icinga Web 2 version and modules (System - About):
    image
  • Server operating system and version: Debian 11.9
  • /usr/bin/google-chrome --version: Google Chrome 122.0.6261.111

Additional context

From a little bit of investigation, it could be related to a conflict between the React\EventLoop\LoopInterface object instanciated into the reporting scheduler and the one instanciated in the icingaweb2-module-pdfreport:library/Pdfexport/HeadlessChrome.php.
@yhabteab yhabteab mentioned this issue Mar 13, 2024
Merged
@yhabteab yhabteab added the bug Something isn't working label Mar 13, 2024
@yhabteab yhabteab added this to the 1.0.2 milestone Mar 13, 2024
@yhabteab yhabteab mentioned this issue Mar 13, 2024
Merged
@yhabteab
Copy link
Member

yhabteab commented May 6, 2024

ref/IP/52505

raviks789 added a commit to Icinga/icingaweb2-module-pdfexport that referenced this issue May 7, 2024
@raviks789
Allow to asynchronously generate PDFs (#65)
43c4232 
The current implementation of `HeadlessChrome::toPdf()` always assumes
that it controls the event loop instance, i.e. `HeadlessChrome` creates
and starts the event loop manually. This may work for most use cases as
they are mostly triggered via Icinga Web, but not if you want to
generate PDFs using a daemon. Since our scheduler uses the same global
event instance, it is unfavourable to call `Factory::create()` over
again occasionally.

refs Icinga/icingaweb2-module-reporting#229
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
1.0.2
Development

Successfully merging a pull request may close this issue.

SendMail: Send PDFs asynchronously Icinga/icingaweb2-module-reporting
2 participants
@gianlucapiccolo @yhabteab