PDF to JPG and ImageMagik can crash your system

OpenEMR Development
1

tmccormi wrote on Thursday, February 04, 2016:

ImageMagick is used to convert PDF files to JPG for viewing in Patient->Reports. If the PDF is huge it will take the system down both CPU use pegged and by filling the root temp drive.

It does not cleanup after itself if killed.

I have disabled the inline conversion and printing of PDF on some of my customers that have this issue frequently, but I suspect we could come up with a better way to handle PDFs and the Patient->Report feature.

Thoughts?

–Tony

2

tmccormi wrote on Thursday, February 04, 2016:

Example …

total 17G
-rw------- 1 www-data www-data    0 Feb  3 16:06 magick-j0WPMr2w
-rw------- 1 www-data www-data    0 Feb  3 16:14 magick-8SkgElxw
-rw------- 1 www-data www-data 4.9G Feb  3 16:16 magick-lSLCeVbW
-rw------- 1 www-data www-data    0 Feb  3 16:16 magick-LVZS3cD0
-rw------- 1 www-data www-data 4.9G Feb  3 16:19 magick-5KZwCxqR
-rw------- 1 www-data www-data 4.9G Feb  3 16:22 magick-v1M1nnRN
-rw------- 1 www-data www-data    0 Feb  4 08:05 magick-GbQA8tKL
-rw------- 1 www-data www-data 4.9G Feb  4 08:13 magick-keDxUnQQ
-rw------- 1 www-data www-data 860K Feb  4 09:35 phpc5Mzks
mi2@mii11:/tmp$
3

aethelwulffe wrote on Monday, February 08, 2016:

What thread limit are you using, and which imagemagick libraries…meaning when were they compiled, and were they compiled specifically for ubuntu? Are you on version 6.9.3-3?

4

mdsupport wrote on Monday, February 08, 2016:

We had similar issues with inbound faxes that was fixed with limiting the resolution of split pages. Managing temporary files for an multi-user environment is always messy. It is even more challenging in a pure web interface as server will never know when user is done viewing the pages. For faxes where the pages can get deleted selectively from a site folder, we ended up with a nightly cron cleanup.

We definitely need better ‘documents’ manager with centralized methods - create, view and delete. In addition, since pdf has so many robust inline viewers, IM approach limits functionality. Perhaps a global flag can be tested and let pdf files handed off to the browser.

5

tmccormi wrote on Tuesday, February 09, 2016:

Art - defaults fpor the platform install, nothing special.

6

tmccormi wrote on Tuesday, February 09, 2016:

What do people think about adding a global to just turn of PDF to JPG conversion entirely? PDF documents would need to be opened and printed individually when a copy is needed by the user, but I think that beats crashing the system for everyone…

7

aethelwulffe wrote on Wednesday, February 10, 2016:

Honestly, I think that on import you should have a default option to run a scaling utility on a file to ensure the resolution is of a normal size.
Next, I would encode them into html or just a text file.
Finally, you can run your reports with this:

$pdf_base64 = "base64pdf.txt";
//Get File content from txt file
$pdf_base64_handler = fopen($pdf_base64,'r');
$pdf_content = fread ($pdf_base64_handler,filesize($pdf_base64));
fclose ($pdf_base64_handler);
//Decode pdf content
$pdf_decoded = base64_decode ($pdf_content);
//Write data back to pdf file
$pdf = fopen ('test.pdf','w');
fwrite ($pdf,$pdf_decoded);
//close output file
fclose ($pdf);
echo 'Done';
8

tmccormi wrote on Thursday, February 11, 2016:

As to the scaling utility. I tried that and it worked sometimes… other times it produced a trashed file. So I abandoned that option. To be clear I was trying to fix the fact that the customer had scanned files at 1200 DPI to PDFs…

Not clear what the above code would do or where you would implement that…