Ubuntu coldfusion2025 PDFManager not working

[iclark3509]

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?

[AbhishekJha]

@iclark3509 Please reach out to cfsup@adobe.com

Thanks,

Abhishek

[BKBK]

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

[iclark3509 · Accepted solution]

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.

[BKBK]

Thanks for sharing your solution, @iclark3509 .

[iclark3509]

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.

[BKBK]

What is the Coldfusion version and update level?

Please check all the logs and share every relevant error message in full

[iclark3509]

Name 

Core Server

Update Level: 

15

Update Type: 

Security

Build Number: 

330825

Jetty request log(

192.168.86.48 - - [25/Jul/2025:17:25:49 +0000] "POST /PDFgServlet/ HTTP/1.1" 500 607 "-" "Apache-HttpClient/4.5.13 (Java/17.0.6)"

I already included the stderrlog as an attackment. 

From the calling coldfusion server:

server.log

"Error","ajp-nio-127.0.0.1-8022-exec-9","07/25/25","13:26:19","","Error occurred while generating PDF."

and that is it. Not much use at all.

[BKBK]

Could it be that you are requesting the wrong host to generate the PDF? I can identify at least 3 IP addresses from the stderrout.log and from your last post: 

192.168.86.50,

192.168.86.48, and

127.0.0.1.

Apparently, 192.168.86.48 is a client making an HTTP request to Jetty, and 192.168.86.50 is the Jetty host server running on port 8995, and receiving the request. Is that how you configured the remote generation of a PDF?

What IP is ColdFusion running on?

It seems 192.168.86.50 is the correct Jetty host server. To verify, launch

192.168.86.50:8995/PDFgServlet/verify

 in a browser. Press F12 to open Developer Tools, and then F5 to reopen the web page. 

Examine the request header. Is the status 200 OK?

[iclark3509]

yes 50 is the host (jettry is running on) 48 is the client (cold fusion is running:

so 192.168.86.48 has cold fsuion and IIS as the web server. Cold Fusion is set up to have the PDF Manager running on 192.168.89.50,

My test page:

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF-8" />

    <title>Simple Test Page</title>

  </head>

  <body>

  <p>Simple test page...</p>

  </body>

</html>

</cfhtmltopdf>

is on that server. So using htto://localhost/ian/tdftest.cfm should create a simple PDF and display it to the browser.

Nothing is displayed and no error reported except in the log. NOTE: if I disable the remote MDFManager and enable the local one it works fine.

[BKBK]

Thanks for the update.

To confirm, ColdFusion runs on 192.168.86.48 and the PDF service runs on port 8995 on 192.168.86.50 (You wrote 192.168.89.50; is that just a typing error?)

There is another source of confusion. Which ColdFusion version is this all about? That is not clear.

Your initial question is about the ColdFusion 2025 PDF Manager. However, the stderrout.log and the Jetty error message ("Update Level: 15",  "Java/17.0.6") suggest Jetty is running on ColdFusion 2023. For ColdFusion 2025 those values are  ("Update Level: 3",  "Java/21.0.6").

So which ColdFusion version is running on 192.168.86.48? What do you get when you run the following code?

<cfoutput>#server.coldfusion.productversion#</cfoutput>

Did you do the test I suggested earlier? If so, what was the result?

Here is the test once again:

1. "Verify" the PDF service by launching

192.168.86.50:8995/PDFgServlet/verify

 in a browser.

2.  Press F12 to open Developer Tools, and then F5 to reopen the web page. 
Examine the request header. Is the status 200 OK?

There is an alternative way to verify the PDF service: via the ColdFusion Administrator.

1.  Open the ColdFusion Administrator, and go to the page Data & Services > PDF Service.
2.  Is your PDF service listed in the section "PDF Service Managers"? It should be. If it is not, then that is crucial information to share with us.
3.  Let's assume your service is in the list. What are its settings (Name, Host Name, Port, Weight, Https Enabled, Engine)? 
4.  (Still assuming the service is in the list)  Click on the button  "Verify All Service Managers". What is the resulting "Connection Status"?

[iclark3509]

This has been a series of frustrations for a while now.

At work we run RedHat Enerprise Linux and I have been working with our adminis to try and get it to work. All on ColdFusion 2023. It does not. The calling (client) server connects and verifies to the remote host using the Cold Fusion Administrator but when trying to produce a PDF. The client gives the error connoct create PDf and the PDFManager (Jetty) appears to show a 500 error message.

After having no lock with that and without waisting my Admins time I turned to my at home machiens.

1. Ununtu PC ruinng Cold Fusion 2025 The a client PC rinning windows and cold fsuion 2023. In my opinion if this Java produce works the version of cold fusin should not matter. Here I ran into issues with it not working and in additon my Ubuntu PC has IPV6 active at the same time that through up a whole other set of issues.

So I decided to switch to a purely Windows based test with a desktop and laptop both running Cold Fusion 2023 with the latest Patch (15). Rhese were where my errors logs came from. 

At the moment all my attempts to call a remote server have failed. If I run it locally it works fine. But ideally I need to have a sparate server to produce the PDFs.

It should not be this difficlt to run a tool in the time I have wasted on this. I could have written Java code to isung the underlying iText.jar to create nice looking PDFs. 

Initally at work we could not use the PDFManager becuase we ran on Solaris and the PDFManager did not work there. So now we are on Red Hat I was hoing we could use it. But I am not sure it is work the effoert any more. When I report back to management my findings it is yet anoter reason why we should migrate from Cold Fusion and I do not have a good answer to contradict this sentiment.

[BKBK]

Hi @iclark3509 , I can understand your frustration. Like you, I am a fellow developer.  I'm not an Adobe employee. I am here to help -- and to learn.

In my few decades experience as a developer, the best, quickest and most efficient solutions always emerge when developers join heads together on a problem and share their ideas. Always.

I have tried to share ideas with you. Unfortunately, you have consistently ignored the debugging questions I have been asking.

[BKBK]

Of recent, some ColdFusion developers have reported that, after they install an update, there usually are issues with packages and bundles. Adobe is working on the problem. In the meantime there is a simple action you can undertake to fix such problems:

1.  Stop ColdFusion;
2.  Delete the directory /bin/felix-cache (Don't worry: ColdFusion will recreate the directory and repopulate it upon restart.)
3.  Restart ColdFusion.
4.  Test to see whether whatever issue you were facing has been resolved.

[BKBK]

...
At the moment all my attempts to call a remote server have failed. If I run it locally it works fine. But ideally I need to have a sparate server to produce the PDFs.
...

By @iclark3509

From what I understand, you have two ColdFusion servers, CF1 and CF2. You can generate PDFs locally on CF1 and locally on CF2. But what you want is for CF1 to generate PDFs on CF2.

I still miss the reason why you would want to do that. It is cumbersome. In any case, I am curious to learn about your reason for generating PDFs remotely instead of locally.

The way ColdFusion is designed, PDF is ideally generated locally by the host server on which ColdFusion runs. In fact, the way practically every application server is designed, heavy-duty tasks such as PDF generation are executed locally by the host server on which the application server runs.

There are sound technical reasons for that. Among them the design principles Separation-of-Concerns and G.R.A.S.P. (Information Expert, Low Coupling, High Cohesion), for example.

[BKBK]

So you're not left empty-handed, here is some debugging code that might come in handy:

<!--- 
Code to determine the port on which ColdFusion's PDF Service is running.
Execution time of code: between several seconds and up to 8 minutes on ColdFusion 2023 --->
Looking for port. Please be patient. This can take up to 8 minutes...
<cfflush>

<cfset pdfServicePort="No port found.">
<cfloop index="port" from="8985" to="9005">
	<!--- Domain of PDF Servive Manager is 127.0.0.1 --->
	<cfhttp url="http://127.0.0.1:#port#" method="get" result="cfhttpResult">
	<cfif not findNoCase("Connection Failure",cfhttpResult.fileContent)>
		<cfif structKeyExists(cfhttpResult.responseHeader, "server") and findNoCase("Jetty",cfhttpResult.responseHeader.server)>
			<cfset pdfServicePort=port>
			<cfbreak>
		</cfif>
	</cfif>	
</cfloop>
<p><strong>PDF Service port:</strong> <cfoutput>#pdfServicePort#</cfoutput></p>

[Charlie Arehart]

Ian, I have a very different take on your problem, given what you've reported--especially the tracking of the 500 error in the jetty logs. And it fits the scenario you're describing. (And I'll share briefly that if someone might see a 403 for the pdfgservlet calls in that log, that would ba a very different problem related to recent CF updates. I'll try to create a blog post on that, but let's move on to your issue.)

And as for your frustration with things, I'll just say that when it comes to using remote PDF services it adds a new level of complication that could explain the issues you're facing. (Both your isssue and that other one I refer to.) And as for yours, most people are unaware that there's actually a TWO-WAY conversation that takes place between CF and a remote PDF service. And you need to open a port in your firewall on the CF server to be reachable from the machine serving the remote PDF service.

So to begin, look in your coldfusion-out.log, around the time when CF starts (if you have a remote PDF service defined already, or look there the first time you register a remote PDF service). You will see it indicating a line along the lines of:

Enabling port 5500 to serve and receive content from remote PDFg service

You should then see one a few lines later saying that it "started" that port.  (There are reasons it could show as yet another report, if two CF instances are running and both have remote PDF services registered, in which case you may see it using port 13618.)

So THAT is the port you need to open in your firewall (again in the CF server where your CF Admin has registered the remote service.) And once you do that, test your request again. And if that doesn't work, you may need to go back into the CF Admin to the PDF Services page, and use the button to "enable" the service in question. You should also try the "verify" button.

And if it that fails or the CF page STILL returns a blank page, click the button to EDIT the PDF Service, and without changing it click the "update" button. Then try the "enable" button and the "verify" button, then test your cf page.

If it all works now, let's celebrate. If instead it still fails, look in the request log on the remote server's jetty logs, and let us know if the status code has changed from a 500 to a 403. If it has, you have a new problem. But this is already a long reply (and all this has gotten pretty far afield of the original post above), so unless it's your issue I'll create a blog post with those details.

Let us know if this is helpful. (And even if it's not the solution for you, I hope it may help others in the future. This stuff is rarely well-documented, so we are all contributing here to the public knowledge on these things.) 

[iclark3509]

Charlie,

Thanks for you response.

I know this email chain contains three separate threads of trying to get the report PDF Manager working.

1. My Day Job ( govenment agency) ruuning coldfusin 2023 on RED HAT enterprise Linux. Previously on Oracle Solaris. Prior to Adobe adding PDF Reactoer to the tool while wewere on Solaris the PDF Manager was never an option for us. Now I have been asked to see if we could use it. Hence all this effort.

2 Using Ubuntu as the report server. This was my attempt to get closier to the agency setup. Issues with IPV6 and the other connection issues

3. Windows to windows to try and similfy the environment. This is the one I will keep with for now.

So I decided to make sure what I had done. So this morning on both machines:

Turned off Widws Defendor and McAfee ( so no fire wall or viru scanner running)

On the client restarted coldf suion.

Log information:

Jul 28, 2025 07:59:27 AM Information [Thread-24] - Enabling port 5500 to serve and receive content from remote PDFg service.
Jul 28, 2025 07:59:27 AM Information [main] - Package odbc started...
Jul 28, 2025 07:59:27 AM Information [main] - Starting sql...
Jul 28, 2025 07:59:28 AM Information [Thread-24] - PDFg service manager http://192.168.86.50:8995/PDFgServlet/ registered.
Jul 28, 2025 07:59:28 AM Information [main] - Package scheduler started...
Jul 28, 2025 07:59:29 AM Information [main] - Package ftp started...
Jul 28, 2025 07:59:29 AM Information [main] - Package awssqs started...
Jul 28, 2025 07:59:29 AM Information [main] - Package awssns started...
Jul 28, 2025 07:59:29 AM Information [main] - Package azureservicebus started...
Jul 28, 2025 07:59:29 AM Information [main] - Package awsdynamodb started...
Jul 28, 2025 07:59:29 AM Information [main] - Package gcpfirestore started...
Jul 28, 2025 07:59:29 AM Information [main] - Package gcppubsub started...
Jul 28, 2025 07:59:29 AM Information [main] - Package gcpstorage started...
Jul 28, 2025 07:59:29 AM Information [main] - Package report started...
Jul 28, 2025 07:59:29 AM Information [main] - Package exchange started...
Jul 28, 2025 07:59:29 AM Information [main] - Package sharepoint started...
Jul 28, 2025 07:59:29 AM Information [main] - Package graphqlclient started...
Jul 28, 2025 07:59:29 AM Information [main] - ColdFusion started
Jul 28, 2025 07:59:29 AM Information [main] - ColdFusion: application services are now available
Jul 28, 2025 07:59:30 WARN [main] - Unable to determine dialect of the StAX implementation at jar:file:/D:/ColdFusion2023/cfusion/lib/bundleaxis/wstx-asl-3.2.9.jar!/
Jul 28, 2025 07:59:30 AM Warning [main] - Unable to determine dialect of the StAX implementation at jar:file:/D:/ColdFusion2023/cfusion/lib/bundleaxis/wstx-asl-3.2.9.jar!/
Jul 28, 2025 08:01:15 AM Error [ajp-nio-127.0.0.1-8022-exec-1] - Error occurred while generating PDF.

No reference to ther port 5500 starting??

On the server nothing in the 2025_07_28.stderrout.log log.

The 2025_07_28.request.log had:

192.168.86.48 - - [28/Jul/2025:11:59:26 +0000] "POST /PDFgServlet/ HTTP/1.1" 200 256 "-" "Apache-HttpClient/4.5.13 (Java/17.0.6)"

192.168.86.48 - - [28/Jul/2025:12:00:53 +0000] "POST /PDFgServlet/ HTTP/1.1" 500 607 "-" "Apache-HttpClient/4.5.13 (Java/17.0.6)"

I added an image of the developer tools request when I call the page with the call to the PDF Manager. But don't think that provies any information.

I aslo delete the remote PDFManager rnytuy and recresated it..

Ian Clark <ianclark@clarksconsultingllc.com>	8:39 AM (1 minute ago)
to me

Jul 28, 2025 08:34:41 AM Information [http-nio-8500-exec-1] - PDFg service manager http://192.168.86.50:8995/PDFgServlet/ unregistered.
Jul 28, 2025 08:34:41 AM Information [http-nio-8500-exec-1] - Stopping PDFG Server.
Jul 28, 2025 08:35:44 AM Information [http-nio-8500-exec-2] - PDFg service manager http://192.168.86.50:8995/PDFgServlet/ registered.
Jul 28, 2025 08:35:44 AM Information [http-nio-8500-exec-2] - Enabling port 5500 to serve and receive content from remote PDFg service.

No entries after the Enabling port 5500 message. Should it have written something?

Thanks,

Ian

[Charlie Arehart]

Ian, you're almost there.

First, you say in reply to me, "No reference to ther port 5500 starting??", but note it was indeed the first line of the logging you quoted:

Jul 28, 2025 07:59:27 AM Information [Thread-24] - Enabling port 5500 to serve and receive content from remote PDFg service.

And then also the last line of all that logging:

Jul 28, 2025 08:35:44 AM Information [http-nio-8500-exec-2] - Enabling port 5500 to serve and receive content from remote PDFg service

So we're halfway home, I think. I would assert now that the problem is that the remote server can't reach that port on the cf server. I know you said you turned off defender. Let's not stop there.

1) First, did you then do the steps I proposed (for after addressing FW issues) to again try to enable and verify the remote pdf service, in the cf admin of the server doing the cfhtmltopdf? 

2) If you may say you did (or now do) that and things still don't work, see then also my final suggestion to make sure the jetty request log is still reporting a 500. It may have changed to now a 403 status code, which would be a different problem (one that's new to recent cf updates, which I can elaborate on if needed).

3) Also, let's not have you hang your hat on merely having disabled defender. Let's confirm simply if the remote pdf server CAN reach that port 5500 on the cf server. 

Go to the remote pdf server, and in the jetty request log find the request getting a 500 status code (on the pdfgservlet call from the cf server requesting a pdf). Note the ip address shown for that line (in the first couple of columns): this will be the ip address of the cf server sending the pdf request. 

Now, test if that remote pdf server (in your case, itself another cf instance on the remote machine) can reach port 5500 on the originating cf server. There are several ways to do that, from old school telnet (now disabled by default in windows) to curl (now built into windows) to powershell:

Curl thatip:5500

Or

powershell Test-NetConnection thatip -port 5500

Do any of those show a failed connection?

If so, that's why the attempt to use that as a remote pdf service fails (sadly, without ANY tracking in the logs on the cf side, and just a blank page shown the user).

4) Finally, if adding a rule in the defender firewall for port 5500 (to open it initially to all) doesn't work (along with later limiting it to access from the ip of that remote server), then it would seem you may have yet another firewall in the way, on either end. 

If the two machines aren't in the same network, that's definitely possible. For instance, if the cf machine is in your home and the remote pdf server (your other cf instance) is at work, your home router could be blocking port 5500. Or the work machine might even use a firewall that blocks OUTBOUND calls to non standard ports. (Indeed, see if you can simply access the cf admin of each machine from a browser in the other.) 

If you fix that (get the port to be accessible), don't forget to repeat the steps in my point 1, or check if you're now suffering the problem in my point 2.

Then let us know what you find. I appreciate it's frustrating and feels fiddly. As I said, the two-way communication with remote pdf services is unexpected to most, and little-documented. And many who persevere to solve it don't bother explaining how they did: they just get on with other priorities, as I'm sure you'd like to! 🙂 

I think you could be really very close to resolving this.

[iclark3509]

Charlie,

I think you have found the issue:

curl 192.168.86.48:5500
curl : Unable to connect to the remote server
At line:1 char:1
+ curl 192.168.86.48:5500
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

I have a google mesk WiFi Network. So while I hae turn off McAfee and windows defender I think it might be blocking the port. I'll see if I can figure out how to open it and report back

Thanks again.

I also have something to tell the admins at work what to look for as they were concentrating on the 8995 port and not looking at the 5500. I am supposed Adobe Support did not methion this to them.

Ian

[Charlie Arehart]

Great to hear. Like I said, it's a little known facet of remote pdf services. And it would hit only those whose cf and remote service are in different networks. That's not everyone who uses remote pdf services.

Let's consider that many cf  folks don't bother to create PDFs from cf, and of those who do many still use cfdocument (which is entirely unrelated to this pdf service feature). And most of those who do use cfhtmltopdf don't use anything but their local pdf service.

By the time you get to those using a remote pdf service--and THEN those whose remote service and cf service aren't on the same network or VPN, then you're d indeed own to a tiny fraction of the cf world.

Just saying this is why I'm not surprised either Adobe or bkbk mentioned this 5500 port matter. (And see my first note about how it can even end up being a different port than 5500.)

This is why I press for using diagnostics to understand and resolve such problems as tedious as that may seem to some readers. And good on you for being so diligent as to have provided the info, from the 500 in the jetty request log (which started my suspicion of your problem), to the cf out log showing that port being enabled and started (which confirmed my suspicion).

Testing the port access was the final piece of evidence to be able to "get an indictment".  Queue the closing music for Law and Order...or let's see if instead this turns into a two-part episode. 🙂 

Looking forward to hear your how further testing goes. 

[iclark3509]

Charlie,

Thank you very much. 

I will not get into the details of my Laptops issues. But it has multiple VPNs (crtix,Fortinet etc. ) used on various contracts as well as windows defender and McAfee as well as my home Google Mesh setup all contributing to blocking the port and IP addess from other PCs on the netwrk. Once I checked all of those and was able to do the test of the connection:

Test-NetConnection 192.168.86.48 -port 5500

ComputerName : 192.168.86.48
RemoteAddress : 192.168.86.48
RemotePort : 5500
InterfaceAlias : Ethernet
SourceAddress : 192.168.86.50
TcpTestSucceeded : True

Then restarting coldfusion on the laptop I confirmd that the PDF Maanger was verified with no errors.

Then I was able to sucessfuly generate and display a PDF.

So my at home set up is now working.

With the help you gave me I now have a good idea of what is going on at work. So now I need to work with the Admin to open ports etc. between my Virtual Red Hat PC and our PDF Manager. 

I was able to modidy my firewall on the machine to open port 5500 but the MDFManager still cannot connect to it. So the Admin might need to make some changes. But thanks to you I am a lot closer.

Ian

[Charlie Arehart]

Really great to hear. Do keep us posted on how things go with the work servers. 

I'll add a reply to the thread currently showing at the bottom here (poniting folks to this part of the discussion), because otherwise with this threaded interface someone jumping to the bottom to find "the answer" won't see this discussion and its seeming conclusion...and especially now that the entire thread is split over two pages here. 

That said, perhaps at some point you'll choose to mark one of the replies as "the answer", which will help people who come into the top.

I know BKBK doesn't care for doing that when the thread has more than one topic, and the "current" answer addreses the ORIGINAL question (he raised that concern in another thread here last week). But since YOU raised the new question (and really, it's an extension of the original issue), I think it would be reasonable for you to do that. 

And if you pick one of my replies, I would edit it to add a point of clarification to the top of the reply to explain to those (now seeing it at the top under "answers") that it addresses this follow-up discussion of yours. Just a sad circumstance with this threaded interface (which otherwise is usually quite helpful).

[iclark3509]

Charlie,

At work I was able to open port 5500 at work and from the PDFManager Server I am able to do a curl command.

However on my client server when I bring up cold fusion i get this error:

Jul 29, 2025 06:41:47 AM Error [http-nio-8500-exec-9] - Registration error for service manager : .http://xxx.x.x.x:8995/PDFgServlet/.Reason: SERVER ERROR

And on the PDFManager server in the jetty logs I get:
yyy.y.y.y - - [29/Jul/2025:11:41:43 +0000] "POST /PDFgServlet/ HTTP/1.1" 500 4511 "-" "Apache-HttpClient/4.5.13 (Java/17.0.6)"

I removed the IP Addesses .

I disabled the remote sever and the re-enabled it with the same errpr occurring. Hove you seen this before or do you have any pointers as to what to look for?  Both of these servers are running RedHat Enterprise Linux

[Charlie Arehart]

Yes, there are 3 things yet for you to try (based on the info I've shared before here), before we presume you have some new problem (let alone one that may be unique to Linux).

1. Please confirm in the cf instance that its logs show it enabling and starting port 5500. Remember, I'd shared there could be reasons it could show using another port instead. 
2. Whatever that port is, attempt a curl of that ip an port from the remote server. Does that work?
3. If after all that it still doesn't work, remember I'd said not just to try clicking the button to "Enable" the remote pdf service, but also click the edit button and "update" the service (without change), which causes cf ("coldfusion", not "cold fusion") to re-register the remote service

Then, assuming there's no error in doing that, test your pdf creation page. If it still fails, confirm it's still a 500 in the jetty request log. As I'd said, the problem could switch to now logging a 403 error, which would be yet a different problem. Again, let's cross that bridge when we get there.