Skip to main content
I
iclark3509
Inspiring
May 2, 2025
Answered

Ubuntu coldfusion2025 PDFManager not working

  • May 2, 2025
  • 3 replies
  • 4213 views

I am trying to get the PDF manager to work on coldfusion 2025 (developer addition) running on Ubuntu with Apache web server. I did the full GUI install (ColdFusion_2025_GUI_WWEJ_linux64.bin ) select developer addition, all add ons etc. Did no install the separate addons download. So jetty is instslled under cfusion.

After installation I can verify the PDF  Manager ( in my case the install changed the port to 8999). Like some other post I have seen I was seeing the unregistered in the log. Selecting edit and saving without any changes allowed me to verify and provided the reghistered log item:

May 2, 2025 07:15:06 AM Information [http-nio-8500-exec-4] - PDFg service manager http://127.0.0.1:8997/PDFgServlet/ unregistered.
May 2, 2025 07:15:06 AM Information [http-nio-8500-exec-4] - PDFg service manager http://127.0.0.1:8997/PDFgServlet/ registered.

I do have it connected to appache anbd the web root is set so in a file called test.cfm I have:

<cfhtmltopdf>
<h1>Hello World</h1>
</cfhtmltopdf>

When I naviage here (http://localhost/library/pfdf/test.cfm) the server tings about it and finally display this:

http://localhost/library/pfdf/test.cfm?&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__&__

 

There is nothig written to the coldfusion or Jetty logs!! I an at a loss as to why. Previously I have used windows with no issues. But I need it to run on linux for a customer. Does any body have any ideas as to what is going on?

Correct answer iclark3509

Charlie, thank you for your help and here are my final notes:

 

To summarize, we had wanted to setup on Red Hat Enterprise Servers a single instance of the PDF Manager to handle calls from multiple ColdFusion servers ( currently running coldfusion 2023).

 

If you follow the Adobe instructions you will get the fonts that go in usr/share/fonts, but what you will not see is that first the PDFReactor underlying the remote pdf service requires a JVM flag -Djava.awt.headless=true, that goes in to jetty start.ini file. You also need to edit the jetty/etc/jetty-ipaccess.xml file on that server to add the IP of any cf server that needs to access the PDF service.

 

The next big items are the required ports. From the client to the PDF Manager server, you need 8995 (default for 2023 but it could be different). The one that there is no apparent documentation on is that port 5500 on the calling cf server must be reachable from the pdf service machine. This is the one that had been giving me issues.  This is used to receive the rendered PDF from the PDF Manager.

 

And I made sure the firewall had this port open, but it still did not connect. I initially thought it might be still some other firewall or gateway machine blocking it.

 

But while trying to set a web server connection between ColdFusion and Apache and getting 503 error messages, I saw references to "SELinux". This is a security layer on Red Hat Linux servers that was enabled without my knowledge, which was blocking the port.

 

As soon as port 5500 was opened up in SELINUX, my connector worked and so did the remote PDF generation.

 

While I did waste a lot of time on these port issues, as a developer I did get our Linux Admins to think about giving the developers more insight into what was configured on the virtual servers so hopefully going forward we will have more insight and visibility.

 

Ian

3 replies

Charlie Arehart
Charlie Arehart
Community Expert
July 28, 2025

Readers who come here to the bottom of this multi-page list of replies should take note that Ian had raised in late July a new issue about remote PDF services issues. Some good news is that it seems he's come to a resolution on that, but given the threaded nature of this UI it's not here at the end (or even on this currently second page) but instead in another discussion.

See the couple of messages between us above and below this one of his where he reported seeming to have made real progress, especially dealing with firewall matter which I suspected was at issue--regarding the port 5500 that the remote add-on service calls back to (in the CF instance trying to create the PDF). Much more on this there.

I just want to add this here for those who may "jump to the bottom" to find the conclusion. I realize that it's possible that in time still other new messages may appear here, but I'm writing this on the preumption this may just as likely remain as the "last message" in the thread here. 🙂

/Charlie (troubleshooter, carehart. org)
I
iclark3509AuthorCorrect answer
Inspiring
August 13, 2025

Charlie, thank you for your help and here are my final notes:

 

To summarize, we had wanted to setup on Red Hat Enterprise Servers a single instance of the PDF Manager to handle calls from multiple ColdFusion servers ( currently running coldfusion 2023).

 

If you follow the Adobe instructions you will get the fonts that go in usr/share/fonts, but what you will not see is that first the PDFReactor underlying the remote pdf service requires a JVM flag -Djava.awt.headless=true, that goes in to jetty start.ini file. You also need to edit the jetty/etc/jetty-ipaccess.xml file on that server to add the IP of any cf server that needs to access the PDF service.

 

The next big items are the required ports. From the client to the PDF Manager server, you need 8995 (default for 2023 but it could be different). The one that there is no apparent documentation on is that port 5500 on the calling cf server must be reachable from the pdf service machine. This is the one that had been giving me issues.  This is used to receive the rendered PDF from the PDF Manager.

 

And I made sure the firewall had this port open, but it still did not connect. I initially thought it might be still some other firewall or gateway machine blocking it.

 

But while trying to set a web server connection between ColdFusion and Apache and getting 503 error messages, I saw references to "SELinux". This is a security layer on Red Hat Linux servers that was enabled without my knowledge, which was blocking the port.

 

As soon as port 5500 was opened up in SELINUX, my connector worked and so did the remote PDF generation.

 

While I did waste a lot of time on these port issues, as a developer I did get our Linux Admins to think about giving the developers more insight into what was configured on the virtual servers so hopefully going forward we will have more insight and visibility.

 

Ian

Charlie Arehart
Charlie Arehart
Community Expert
August 13, 2025

Great to see the concluding summary and to hear that the key was first that port 5500 (which readers can find I introduced and discussed more above) and then that selinux was blocking it even once you'd opened it in your firewall (this is the first mention of that here, so thanks). 

 

These are indeed all valuable things for folks (and Adobe) to consider about enabling remote pdf services, especially when they are on different machines or using selinux. I hope the additional discussion of diagnosing the problem may help others, especially when the port numbers maybe different (for any of several reasons, also discussed above).

 

Best of all, glad it's resolved for you. When you first raised this new part of the discussion in May, you seemed on the verge of feeling you'd need to move off of CF, or perhaps only for pdf services. Surely many get to that point, and some may feel justified or even encouraged by that prospect (or alternatives they may find).

 

Given that Adobe licenses PDF Reactor as the underlying engine for cfhtmltopdf (since cf2023), which would be VERY expensive for us to do on our own, I'm all the more happy that we all on this thread have contributed key knowledge to the community. Indeed, I hope to do a blog post with my own summary of the conclusion, as some won't have the stomach to wade through all this, or may not even see your summary--which I will mark now as another "answer" for this thread. 🙂 

/Charlie (troubleshooter, carehart. org)
I
iclark3509Author
Inspiring
June 9, 2025

I did not get an answer from Adobe but I found that PDFReactor required a JVM setting if it was not running with a graphicl inferface. So in the jetty start.ini I added -Djava.awt.headless=true restarted Jetty and it worked. Ubuntu has a GUI so it kind of threw me as to why this would work. But in did. This was on a developer addition of ColdFusion2025. I then had a docker container with coldfusion2023 that had the same issue. I checked it heare and it worked as well.

So for now this appears to be resolved.

I
iclark3509Author
Inspiring
July 25, 2025

So the saga continues.

I cannot get a remote PDF Manager to produce a PDF for me. All effirts so far have resulted in a generic coldfusion error "error occurred while generating  PDF". In jerry with no debugging on I can see the post with a 500 error code.

Debugging with org.eclipse.jetty.server.LEVEL=DEBUG  (gibrd tyhe atatched output for today). Looks like the post worked but beyond that I cannot tell what the debug is telling me. 

The was two winodws machines one runnning wndows 10 the other 11. To get this far I had to turn McAfee and windows defender off. I also tried windos to Ubuntu but here ran into IPV6 Issues.

For work I need this t work on Red Hat enterprise Linux. I have to have administraotrs make chances for me. At the moment I have not tried the debugging but get the same 500 error. 

At this point I am redy to give up and recommend we do not try to use this. Which is a shame as we are close to ginging up on cold fusion altogether and this is another nail in the coffin.

I
iclark3509Author
Inspiring
July 31, 2025

Ian, that's helpful info. Let's press on. I have new diagnostics for you to consider. The solution should be in reach.

 

1) First, though, I didn't ask if port 5500 was open. You'd already confirmed that. But the 500 status code is the key question I was asking, AND it confirms also that cf can reach the pdf server (my other question).

 

2) So let's focus now on the 500 (in the server log of the remote pdf service). More important, the additional stack trace within that log info you just shared now points to a problem that clearly remains.

 

Readers should note that Ian had buried in one of his attachments this statement: "I think my next step is to ask the admin to turn on jetty debugging. Bit I am not sure which module to set it for." (Ian, I'd plead you not to put text in those files. Most people won't read them.)

 

3) Anyway, I would say yes, additional logging would now be warranted, but no need to enable any jetty "module". Instead, we want the CF PDF service feature to give us logging about what it's doing (or failing to do).

 

To do that, go to the remote pdf server. If it's a CF instance as you've said, go to [cf]\cfusion\jetty\webapps\PDFgServlet\WEB-INF. (Those who may use an "add-on service" installer on the remote server would look instead at [cfaddon]\webapps\PDFgServlet\WEB-INF (note there's no jetty folder, as the folder you install the cf add-on service to IS the jetty folder.)

 

Then in that specific WEB-INF folder is a web.xml file where we want to tweak just one line. About 40 lines down that file are these lines:

	<context-param>
	    <description>EnableLogging logs complete details about pdfg service and conversion request lifecycle. This option needs to be enabled for debugging purpose only. </description> 
	    <param-name>enableLogging</param-name>
	    <param-value>false</param-value>
	</context-param>

Change that "false" to "true" and restart that pdf service. (No need to change or do anything on the CF/client side other than to re-run your page that is failing.)

 

4) Enabling this will now create new files in the logs folder of that remote jetty instance. Let's focus on the one called::

htmltopdf_1_conversion.log.0

Weird name, I know.  You'll see also a file called htmltopdf_1_conversion.log--without the 0, but I find it never has anything in it. Same with the files ending in .lck--some "lock" file, I assume. I've also found it to sometimes create a htmltopdf_2_conversion.log.0, usually with the same info as the one above.

 

Anwyay, for reference (for you to compare, or others to consider), I've attached here the log for my remote service. (Note that this upload feature wouldn't let me upload it with its name ending in log.0, to I renamed it to log.0.txt).

 

And to be clear I had enabled the logging, restarted that service, and am showing the lines for just one request to it. FWIW, that request was tracked in the jetty request log as this:

192.168.68.50 - - [30/Jul/2025:18:10:46 +0000] "POST /PDFgServlet/ HTTP/1.1" 200 51129 "-" "Apache-HttpClient/4.5.13 (Java/21.0.8)"

Note its time of 18:10:46 (which is GMT time, the default for that jetty request log). Be careful to note that the corresponding lines in the attached htmltopdf_1_conversion.log.0 for that request are instead shown as for the local timezone of that server (US Central, so 5 hrs earlier)...though sadly there's a bug in that it lacks the am/pm indicators, so it shows as 01:10--rather than 01:10pm or 13:10).

 

5) More important, this new log tracks about 60 lines for that one request of mine--which only did a cfoutput of now() in the cfhtmltopdf. That's what you'll want to pay attention to in yours.

 

For example, you'll see (per my log) the calls back to that calling CF instance (doing the cfhtmltopdf), which is at 192.168.68.50 (as is shown also in that request  log line above: CF tells the PDF service what is the IP address of itself in the headers of the call it makes).

 

Note you'll also see references to "PDFreactor", which is the name of the product Adobe has licensed for producing PDFs when using cfhtmltopdf, since CF2023 (and is indicated in the setup of the CF Admin PDF services page as what's called "engine" version "2.0"). 

And in fact this remote pdf service was one for cf23 that I was calling from a cf2025 instance--but that works in either direction, and the same basic info should be logged if the PDF service is a cf25 version.

 

6) So enable and check out yours. Maybe you'll see some specific error among your lines that we can next dig into. If so, let us know.

 

I know it's a lot to take in--and frustrating that it "just doesn't work". As I said, there are lots of moving parts We can only treat it as a "black box" when it works. But as we've seen in all this discussion there are a) facets of the communication in both directions that need to be considered (which can be diagnosed)...and b) the work being done on the remote service (which has its own logs that can be considered).

 

Sadly, there's nothing currently that Adobe surfaces to us when a cfhtmltopdf fails because of something in all this back and forth and remote processing. We just get a blank result for the requested pdf. And that's why I have belabored all these details, to help folks in this situation (folks pay for this sort of help from me every day--and this has been more than several hours effort). 

 

I hope you'll stick it out to resolution. Again, I think we're really getting close to solving what's amiss...and helping others along the way.


My first attempt did not uncoer muc. After the logging was enabled. I thought I had replied to this comment but I might of put in else where. In any case I think this is better. I released that my Cold Fusion was 2023 with no patches applied and the PDFManager server was 2023 patch 15 applied ( not sre why it would matter) in any case up updated mine to patch 15. and tried again. I now get thesse log items ( I enlarged the lines that say severe) which is a connection refused. But not indication of which connection!

There was no additional information in any other logs.

 

Log items:

31/07/2025 03:52:05.235 - [coldfusion.pdf.service.j.a] - [INFO] - [PDFReactorThread] Selecting PDFREACTORservice from available idle services

31/07/2025 03:52:05.235 - [coldfusion.pdf.service.j.a] - [INFO] - [PDFReactorThread] Service selected: class a.e

31/07/2025 03:52:05.235 - [coldfusion.pdf.service.j.a] - [INFO] - [PDFReactorThread] Executing the task using service: class a.e

31/07/2025 03:52:05.239 - [coldfusion.pdf.service.j.a] - [INFO] - [pool-3-thread-1] Conversion Request Data received and parsed.

31/07/2025 03:52:05.242 - [coldfusion.pdf.service.j.a] - [INFO] - [pool-3-thread-1] Conversion Settings configured.

31/07/2025 03:52:05.492 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-1] java.net.ConnectException: Connection refused

31/07/2025 03:52:05.492 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-1] Error occurred during PDF conversion for request :java.net.ConnectException: Connection refused

31/07/2025 03:52:05.492 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-1] com.realobjects.pdfreactor.PDFreactor$ConversionWrapper.convert(l:253)  at com.realobjects.pdfreactor.PDFreactor.convert(l:78) at a.e.a(Unknown Source) at a.e.a(Unknown Source) at coldfusion.pdf.service.remote.a.a(Unknown Source) at coldfusion.pdf.service.p$a.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:842)

31/07/2025 03:52:05.492 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-1] java.net.ConnectException: Connection refused

31/07/2025 03:52:05.492 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-1] com.realobjects.pdfreactor.PDFreactor$ConversionWrapper.convert(l:253)  at com.realobjects.pdfreactor.PDFreactor.convert(l:78) at a.e.a(Unknown Source) at a.e.a(Unknown Source) at coldfusion.pdf.service.remote.a.a(Unknown Source) at coldfusion.pdf.service.p$a.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:842)

31/07/2025 03:57:52.299 - [coldfusion.pdf.service.j.a] - [INFO] - [qtp1344645519-22] Added the conversion task to waitingQ successfully

31/07/2025 03:57:52.299 - [coldfusion.pdf.service.j.a] - [INFO] - [PDFReactorThread] Task picked up by: PDFREACTOR

31/07/2025 03:57:52.299 - [coldfusion.pdf.service.j.a] - [INFO] - [PDFReactorThread] Selecting PDFREACTORservice from available idle services

31/07/2025 03:57:52.299 - [coldfusion.pdf.service.j.a] - [INFO] - [PDFReactorThread] Service selected: class a.e

31/07/2025 03:57:52.299 - [coldfusion.pdf.service.j.a] - [INFO] - [PDFReactorThread] Executing the task using service: class a.e

31/07/2025 03:57:52.301 - [coldfusion.pdf.service.j.a] - [INFO] - [pool-3-thread-2] Conversion Request Data received and parsed.

31/07/2025 03:57:52.302 - [coldfusion.pdf.service.j.a] - [INFO] - [pool-3-thread-2] Conversion Settings configured.

31/07/2025 03:57:52.316 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-2] java.net.ConnectException: Connection refused

31/07/2025 03:57:52.316 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-2] Error occurred during PDF conversion for request :java.net.ConnectException: Connection refused

31/07/2025 03:57:52.316 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-2] com.realobjects.pdfreactor.PDFreactor$ConversionWrapper.convert(l:253)  at com.realobjects.pdfreactor.PDFreactor.convert(l:78) at a.e.a(Unknown Source) at a.e.a(Unknown Source) at coldfusion.pdf.service.remote.a.a(Unknown Source) at coldfusion.pdf.service.p$a.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:842)

31/07/2025 03:57:52.316 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-2] java.net.ConnectException: Connection refused

31/07/2025 03:57:52.316 - [coldfusion.pdf.service.j.a] - [SEVERE] - [pool-3-thread-2] com.realobjects.pdfreactor.PDFreactor$ConversionWrapper.convert(l:253)  at com.realobjects.pdfreactor.PDFreactor.convert(l:78) at a.e.a(Unknown Source) at a.e.a(Unknown Source) at coldfusion.pdf.service.remote.a.a(Unknown Source) at coldfusion.pdf.service.p$a.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:842)

 

A
Community Manager
AbhishekJhaCommunity Manager
Community Manager
May 2, 2025

@iclark3509 Please reach out to cfsup@adobe.com

 

Thanks,

Abhishek

BKBK
BKBK
Community Expert
May 7, 2025

@iclark3509  and @AbhishekJha , I hope you did eventually identify and resolve the issue. If so, could you please share?

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices