No offense taken. Indeed, I had ended with a smile emoji specifically hoping to avoid such a misinterpretation. We're all here to help or be helped. Sadly, sometimes words get in the way. 🙂  ... View more

There are two "code analyzers" that Adobe provides: that code compatibility analyzer (in the cf admin, which has existed for a long time) and the security code analyzer (in cf builder, both the old eclipse and new vscode implementations, which is more recent).   It wasn't clear from your note which you meant., so it's simply that I assumed you meant the latter. And I was writing at the same time you were writing your reply to yourself.   But note that I'd provided also a link to the docs for my screenshot, so you could have answered this for yourself. I try to help beyond simple answers. 🙂  ... View more

I think I may have your solution.   First, FWIW, that looks like a typical log of 3 startups and shutdowns. Nothing worrisome at all (not even the "memory leak" warnings, which are in fact commonly logged during most cf shutdowns and are generally nothing to be concerned about).    As for the first launch "not letting you in" to the cf admin, are you accessing it on port 8500 (which the log shows being listened on)? If instead you're trying to access the cf admin via an apache site, you can't. That capability was removed even in cf2023 and 2021 per updates a couple of years ago. Old hacks to force it to be permitted no longer work.   Another issue is that during install of cf you were asked what ip addresses should be allowed to access the cf admin. Did you leave it empty? That would limit it to 127.0.0.1 or ::1. If your linux is headless, you have a couple of rather simple choices: Use ssh port forwarding/tunneling, if you're familiar. That could be configured to present "as if" you're coming in from 127.0.0.1 Or modify the xml entry in the neo*.xml file which holds that list of ips, and restart cf. (I'm writing from a phone so can't confirm the name or element.) If that list is empty, there's no ip limit (except your firewall, blocking such a non-standard port)   You COULD even just reinstall cf (since you just did it) but this time change the answer to that question (about the admin ip address list), putting in * and changing it later to be YOUR ip on the admin security>ip addresses page.   (If you do that's, here's a tip: use the cf admin's debugging > debugging ip address page to let it detect your current ip, rather than guess that you know it--which would again lock you out.  Sadly that feature to detect your ip is not offered on that admin security ip address page. I've just added a feature request for that, here. Votes appreciated.)    Let us know if this gets you going. If not, check out other cf logs when it hangs up and share key lines. (If more than a dozen, consider attaching a file instead.)  ... View more

Yes, it's possible to install the updates entirely offline. See the steps in each update's technote. Follow them carefully, without shortcuts.   Let us know how it goes. We can proceed from there for any needed further troubleshooting.  ... View more

The illegal character is just the message you get when the update mechanism doesn't get what it expects--which is almost always down to the url's being unreachable or returningunexpected content. (And to be clear, the default ones you list DO work, so again it's got to be something in your environment. )   When you say in point 2 that they "work fine in a browser", I sure hope you caught the key point was to be trying that from a browser on the machine running CF. But assuming that's true, note that there may be reasons (on your end) why the URL may still fail from within CF and NOT the browser.   It could be about browser proxy configuration (that allows it, where CF does not), or it could be about security protection software that is ALLOWING that call from your browser but NOT from CF, even though both are on the same machine. So that point, let's focus on the cfhttp call from within CF.   When you say in reply to my point 3 that " Just trying to get me to google using cfhttp gives some auth required error from the company", by "the company" do you mean your company?   If you're saying you need help how to DO the cfhttp, see below: <cfhttp url="https://www.adobe.com/go/coldfusion-updates"> <cfdump var="#cfhttp#">  Put that in some cf page and run it. Then try the same with the packages url. ... View more

Frustrating, I know. But something about your restricted environment is the issue. There WILL be a way to your updates done. Just depends on the problem. Questions:   What is the current value for the update url and packages url?  FWIW, the default value for the "update site" url for CF2023 are https://www.adobe.com/go/coldfusion-updates--which redirects to https://www.adobe.com/go/coldfusion-updates, which does have CF2023 (and cf2025) updates listed within its json result. The default "packages site" url is https://www.adobe.com/go/cf2023_packages--which redirects to https://cfmodules.adobe.com/cf2023/bundlesdependency.json, and which has only cf2023 package updates in it. Whatever your values are is, can you browse to either of THOSE values successfully from a browser on that dev machine where you're trying to update? If not, what's the error. Even if you can, the real question is whether cf can. Create a simple test page to do a cfhttp to each of your urls, dumping the output. Do they succeed or fail? What if you try the default URLs I offered above? Finally, regarding the "proxy settings" your trying (at the bottom of that package mgt page), you would be naming something on your end (not Adobe's). If that can't be reached, reconsider what value you're specifying.   Let us know how the above goes. ... View more

Yes, using the "export" button offered in the top right of the output. See the screenshot at the bottom of the docs page about the feature.   ... View more

Please see my reply to your original question, which now appears below.. Just adding this as a reply to this later "reply" you added, in case someone else might reply to this...which could then lead you or others not to notice my more substantial reply below. ... View more

Ok ... View more

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. ... View more

Yep, Matt. And on your idea of simply testing if a simple cfmail fails, that's a great idea that some folks may want to hear a bit more about. There are at least two ways one could go about that.   One is to just create a simple cfm page, with a simple cfmail (to/from/subject) and confirm it works. Then wrap that cfmail in a cftry/cfcatch (or script equivalents), and if the attempt to mail fails (because of this bug), in the catch somehow alert yourself (sadly, you can't send an email when this bug is in play). Then you could set that up a call to that simple cfm page as a scheduled task, to run as little as every minute (or more flexibly with the cron feature of CF scheduled tasks.)   Or a more robust approach is to use a service, like checkcentral.cc (which offers a free plan), where you setup CF to send it mail on a regular basis (like every 15 mins) and IT will alert you if it does not get the email as expected.  I use this myself for detecting if ever my mail processing out of CF is failing (for any reason, such as a problem in the cf mail spool or the smtp server not delivering).   It's quite simple really: again just create a simple cfm page doing a simple cfmail (no need of try/catch)...but in this case the "to" address would be one you setup via checkcentral. Then on checkcentral you create a "check", telling it to WATCH for this email to arrive every 15 mins: and if it doesn't arrive within a time you set (1 min, 5 mins, 10 mins, etc.), then IT will alert you: and the free plan can send an email (which comes from their servers, not yours) or a push notification (to their mobile app).   While the free plan should suffice for this basic need we have here, paid plans (starting at $25/mo) can also send sms texts, browser notifications, slack, and dozens more options. More on the plan differences here. Note that the free plan supports 5 such "checks" (the above is one "check": it's NOT referring to the frequency of checks).   Finally, note that the main focus of the tool/service is to instead create more powerful checks, such as from a backup tool, looking at text in the email, and more.  They have a 6-min YT video going over the basics of setting up such a check. Again, while it focuses on such a "backup" check, the same steps would apply to our CF mail send check. 🙂 Hope that helps, you or others here. ... View more

Well, those questions aside, I'm just focused on the technical matter of a given cf instance talking to a given remote pdf service--and the issues that can arise (and some that Ian has confirmed).   For example, someone may specifically WANT to offload all pdf generation to a machine separate from cf. (Or since cfhtmltopdf let's you name a pdf server as an attribute, maybe one would have SOME PDFs generated locally and others remote.)   And for some people that remote pdf server may be the one implemented optionally within "another cf instance" on that other server, while for others they'd be using the available cf add-on service installer there to setup ONLY the pdf service (no cf at all on that server).   So while you can reasonably want to check why he's doing whatever he's doing, it could be one of these reasonable scenarios. Even if not, what's being discussed could benefit ANYONE dealing with CF talking to a remote pdf service. 🙂    And as I'd noted previously, that's a rather rare situation (use of remote pdf services, even if done for a reasonable use case), for which there's pretty scant discussion and docs (virtually none mention this 5500 port that gets enabled in cf once a remote pdf service is registered).   So I hope this thread ultimately benefits folks beyond Ian...and if nothing else, by feeding knowledge to the AIs to find. Sadly, for humans, it is lamentable that this whole remote service discussion isn't its own thread. By far most discussion is well AFTER what's marked as the "answer" for his original question. 😞   Anyway, let's hear what Ian has to say to the outstanding line of questioning from last night, as we were indeed getting close to resolution, I think (and hope).  ... View more

Dave and bkbk, to be clear the 404 he gets is on his curl of the cf server's port 5500 from the remote pdf server. That was to confirm the latter could reach the former, once it showed being enabled during his cf startup. So the 404 is a good sign. See my reply before each of yours (from last night) for more.   What we await now is confirmation of what the status code is on the pdf server's request log, for the call from cf. We don't yet KNOW if it's now a 500. That was a key question I'd asked him in my reply last night, among others.    As for WHAT is in the cfhtmltopdf, that MAY be interesting, but to be clear it could be just the word 'test" and still be failing, FWIW. More than that, note he'd said the verify of the pdf service was still failing.   That's why I'd  focused on now first the communication from the cf server to the remote pdf server (the success of which may have changed since he had tweaked the firewall), and then what status code (if any) was now being logged. I know I'd written a lot. Just summarizing and putting it in context with your respective comments, while we await his reply/replies.  ... View more

Wow, after all that (and dealing with the other issues I'd mentioned), I finally found that there ARE in fact already other folks reporting the same issue (needing to clear the felix-cache AGAIN after having done it following an update).   And one of them created a tracker ticket about the issue, that interested folks will want to vote on and/or follow.   Still, I hope all I wrote earlier today might still benefit someone. If nothing else, things we share here feed the AIs, so perhaps it could benefit even those who never see this thread. 🙂  ... View more

First, thanks for the very kind regards.  And solving problems with CF is what I love to do, and I do it about all day each day...albeit normally on a consulting basis. But I bring that experience to bear here in the community, especially on such knotty problems (we have a couple going on here in the forums this week).   1) So for anyone who may look at Matt's log attachment that he shared, note that it's not ONE log. Instead he shareds a bit of a couple of CF runs, then adds some commentary (separated by -------------- lines to help), and then more CF runs, then more comments. That wouldn't be obvious to some, who may just start "searching" the log for info and perhaps would not see the context he offers there.   2) I confirmed that the uninstalling only shows up for the one startup after he had applied updated. Good thing I was careful to couch my proposal above (that he might find package updates happening on each start) as merely a possibility. 🙂   3) So what can we take away from all the info he's shared? Well, I don't see any ready explanation in CF's log lines. But he says here and a bit more in the log text that the last problem happened after a box restart...which they'd done because of a memory problem in CF (with I suspect high cpu). That may be were the problem lies. More on that in a moment.   4) I'll note first that you could have avoided the box reboot by just killing the CF task. I do realize you likely tried to stop the service (which would "shut it down gracefully") but you probably found it "wouldn't stop". That happens when memory runs out, GCs get excessive, and CF CPU takes over most of the machine.   And since I can see from the logs you're on Windows, I suspect further that you either gave up waiting for the progress bar of the service to finish, or it popped up saying it couldn't be started. Here's good news in that situation: if you'd waited just another minute then CF would have killed the process. But perhaps you didn't want to wait: in that case, you could have killed the coldfusion.exe process yourself in task manager (not something to do regularly, for reasons I'm about to explain).   But FWIW, when you opted to reboot the box, the same effect could have happened: Windows again tells all services, "hey y'all. shut down." But if they don't, then IT just kills the whole running OS.   5) Now, what's this got to do with your scenario? Well, maybe somehow when CF doesn't go down gracefully  (is killed by you, or by Services not being able to shut it down gracefully, or by a box reboot), perhaps THAT is when something goes amiss with the felix-cache. This is just a guess.   I just don't know enough about how the felix-cache internal processing works. Perhaps someone else or Adobe could chime in. (It's not clear they are reading this thread or will. You may want to open a ticket at tracker.adobe.com reporting the issue. Let us know the ticket number if you do.)    6) If this is indeed the issue, then that's a hard thing to "monitor" (going back to your original idea). There's no mechanism I know of that tracks if CF did or did not shut down gracefully in its previous run.   You could "watch out for the problem" manually: if you look at that coldfusion-out.log, you'll notice you don't see lines about it "stopping", like you showed when it "went down normally", for example (from your log): Jul 10, 2025 20:15:59 PM Information [Thread-12] - Monitoring Service stopped. Jul 10, 2025 20:15:59 PM Information [FelixStartLevel] - Monitoring Service stopped. Jul 10, 2025 20:15:59 PM Information [Thread-12] - ColdFusion stopped So if I ever DO wonder if someone/something "killed" CF, this is what I look for. Or if I'm reviewing logs with folks and I see it does NOT log that (in coldfusion-outl.log, or similar but different lines in coldfusion-error.log, such as "A valid shutdown command was received via the shutdown port. Stopping the Server instance"), that tells me CF crashed or was killed (and usually I'd want to find out why).   I'm just saying that's ONE thing you could watch out for. Sadly I'm not aware of even any means to programatically tell how long CF has been up (so that you could watch for when it may have recently "started", then look to see if those log lines are missing--in which case you could proactively stop CF and clear the felix-cache and start it again.)   But I will note at least that if you have FusionReactor, that DOES show on its metrics<web metrics page (in the text below the graphs) when CF "started" (it refers to it as "server started" but it IS referring to CF, or Lucee, or BoxLang, or Tomcat, or Wildfly, or whatever Java app.app server FR is monitoring--which is why they just say "server", though many misread that as "the server".)   Sorry I don't have better news. Again, maybe someone else will, or Adobe may get back to you if you file a ticket. Please do keep us posted. I've not heard of this happening to many others, but it certainly COULD be happening to others. I hoep we may find some "better" explanation for your situation, as it would be lamentable if a mere "hard crash" of CF could lead to this need to clear the felix-cache. I actually hope it's proven that it's NOT the case, actually. ... View more

Ian, you may not be so far away as you presume. As I keep saying, there are a number of moving parts to this communication--and each environment may present a different challenge.   1) So first, as I've said a couple of times now, once the port 5500 stuff checks out, if the enabling or PDF generation still fails, you need to look again at the jetty request log (on that remote PDF server). Please confirm if the failures have changed there from being 500 status codes to 403's. That would be a new, different problem based on changes introduced by the May CF updates (and the new jetty-ipaccess.xml protection mechanism, which I've held off elaborating until we need to).    2) If you may find there are NO lines in the request log when you enable/verify the PDF service from CF, that's a different problem. Are you positive that the port on the remote PDF service is 8995?    And have you confirmed that you could do a curl to that ip and port (for that remote PDF service) from the CF machine ? Don't presume that this direction of communication is necessarily open.  Just as you had to have them open port 5500 on the CF server to be reachable from the PDF service, so too must this 8995 be opened to be reachable from the CF server. That may be obvious and you've already checked it, but I have to ask.  (And I realize that earlier in the thread you did report seeing 500 status code in that log. I just want to ensure nothing has changed given your recent firewall tweaking. If those jetty request log lines ARE happening when you do the verify or try to create a pdf, then that confirms CF CAN reach that server. In that case, that's why my point 1 focused on any change in that status code.)   3) I'll note also that it's certainly good news that the CF log showed port 5500 being enabled and started. At least we know that's tthe call-back port that would be used.   And it's actually ok that the curl of that port 5500 on this server (from the remote server) returned a 404. That confirms it's "running" and listening. Again it ONLY starts listening if you DO enable remote PDF services, like you saw was being logged.   4) Finally, if you look close at that 404 html you shared, you'll see it shows being a jetty response. That may seem confusing to folks trying to follow along. Let me clarify, as I've not mentioned it yet: this port 5500 we're discussing is actually YET ANOTHER JETTY implementation within CF. Yes, there are two! This one (for port 5500, which only starts when you enable a remote PDF service) is configured via a jetty.xml that is found in cfusion/lib. That's NOT the same one as in cfusion/jetty/etc.    (I'm assuming Adobe didn't leverage that jetty implemented within cfusion/jetty because technically someone could opted during install of CF to NOT install the add-on service, which provides that "local" PDFg and Solr functionality on the CF server.  And some long-time troubleshooters may recognize this "other jetty" as being a holdover from the CF9.0.1 days, when Adobe first implemented it to be the optional "monitoring server" feature for the old CF Server Monitor. It provided an alternative web server to serve up the monitor, for "reasons".)   Anyway, enough of the history lesson. I just wanted to connect all these dots.   Please let us know what you find with regard to my poiints 1 and 2 above. If those check out ok, we can move on to additional steps.  ... View more

Matt, I think there's a different solution to this new problem you raise (this seeming need to "clear the felix cache" more often than just after a cf update). And I don't think the solution is for you to "monitor anything", thankfully: we just need to fix the root cause problem. 🙂 And I have an educated guess of what it is. This will take a couple of minutes to read, Please bear with me, as I offer some diagnostics which will help you (and other readers) even if my proposed solution might prove not to work for you.   A key to me is that you said the problem started after a CF restart. My bet is that we'll find that for you EACH CF RESTART is causing package updates (which then leads to that need of clearing the felix-cache). SHOULD CF be updating packages on each CF restart? No. Is there a reason it's happening? Yes, there will be. How can you find and resolve it? Let me give it a shot.   1) First, we'll want to look at the coldfusion-out.log (in the logs folder for the cf instance in question, which is cfusion by default, but if you have more than one instance look for a sibling folder with that name). As you may know, that file tracks many lines of info about each CF restart.    It ALSO tracks still MORE detail whenever CF updates happen. Specifically, in the first startup AFTER such an update the next restart should show lines indicating "uninstalling the package", naming the ones to be updated, and then for each package also it names then the specific jars for the package being uninstalledat that time. (To be clear, we don't then see any line in the log saying "updating" or "installing".) That should ONLY happen when there have been package updates--whether per a CF update or by manually updating some particular package in the admin or via cfpm.   But before looking at the log, it's important to note also that on EVERY restart, we DO see lines for each package you have installed, indicating that it was started, as in "package xxxxx was started".   I suspect that in your case, you may find that this "uninstalling" of packages is happening on each restart, when it should not. And I have found that when this happens, there's a reason and a solution. More on that in a moment. Let's confirm if things are as I suspect.    2) So let's now look at that coldfusion-out.log of yours. Go to the bottom and search up for the phrase "coldfusion started". That's shown on each restart, and it's preceded by dozens of lines about CF starting up. Within those, for EACH of your restarts, you will again see many  saying each of your packages was "started".   But do you also see with that last restart lines saying also '"uninstalling the package"? Then if you look at each preceding restart (look for that "coldfusion started"), do you see again "uninstalling the package" lines? You SHOULD see them there for the date you did the cf update (which is tracked in the name and date of the log in the hf-updates folder for that update). And you WOULD see them there if anyone were to update some particular package via the admin or cfpm.   But if you find these "uninstalling the package" lines on EVERY cf restart, that's indeed the problem to resolve.   3) Assuming you confirm that issue, let's next check a couple more things: a) look at your CF admin (or the CF Admin for the instance in quesiton, if you have more than one). Go to the "package manager" page, and see its available "settings"  tab offered at the top of that page. In there, what is the value for the "packages url"? And for the "default packages url"?   b) Next, if YOU are the one who does the CF updates, do you do them from within the CF Admin or via the command line?   c) And if you do it from the command line, do you also perform the "manual offline steps" (in the update technote) of downloading and extracting the zip offered there? Where do you extract it to?   Often, what is happening is that someone (in a past update) changed that packagesurl (whether in the CF admin or by editing the neo_updates.xml file, as suggested in the technote).  But if you do a later update and should point to a NEW extracted zip, instead CF thinks it should go back to the OLD one...and you end up with it thinking it needs to update packages, when it shouldn't.  And that happens on each restart.    Could I have just started with point 3? Sure. But then we'd need to await your answer, and THEN I'd have discussed points 1 and 2. I offer all this to help folks in this situation to know better WHERE to look, in order to diagnose the problem rather than just "pop a pill". Often people are told to do that, or are not given complete info.   (Indeed, I would argue that the technote offers incomplete info--because if one does that manual offline update for one update but later gets CF to be able to talk to the internet, they will do a later update that way...but the CF update mechanism will download the new files and put them into the cf bundles folder...but this pointer to the extracted zip from the earlier update will keep the update mechanism from USING those newly updated bundles files...leading to your error.)   Well, it's one common cause. Again, I didn't want to start with that. I wanted to have you assess the coldfusion-out.log to confirm first if WHAT I suspect is happening shows to be happening (packages being updated on each restart). That's the what and how of your problem. The rest is the why, and at least one suggested reason and its resolution.   If it's not the right what or why, we'll have to dig in a different direction to get you out of this hole you're in. 🙂 We've got shovels at the ready.    Let us know how the above goes for you. ... View more

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).   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.  Whatever that port is, attempt a curl of that ip an port from the remote server. Does that work? 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.  ... View more

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. 🙂 ... View more

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). ... View more

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.  ... View more

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. ... View more

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.)  ... View more

Thanks for the kind regards. We're blessed as well to have other frequent longtime contributors here like bkbk, Dave Watts, and even you. 🙂 We're all in this together!  ... View more

I'll jump in and say "no".  Really, just follow those steps. They're literally recommended by Adobe in the technote for the most recent updates, just as they've been for most of the recent updates. It's just a one-minute effort, without risk (though, granted, it requires a cf restart).   But trying to cherry pick and guess what cf needs based on these sort of error seems risky business. Another "mole" will likely pop up, needing to be "whacked". Just flush the field, in the hopes it will eradicate all the moles. 🙂   Then let's hope eventually Adobe gets to the bottom of whatever is the true root cause of this package mismanagement being caused (in some situations) by their updates.   Finally, if this DOES NOT solve the problem, then at least we've ruled that out. I'd propose the next thing to consider would be whether there were any errors in the update or its subsequent package update process. But let's wait to cross that bridge if we get there.   Or bkbk may have a different perspective to share, if course.  ... View more

So Jonas, today is your first mention of using docker. That might steer us toward different considerations. So it leads to a few questions, which I'll number to make it easy for you to reply to: First, I assume these are the Adobe-provided cf images you're using, right? (There are others.)  And when you say you use "a fresh Coldfusion 25 Docker installation", is it actually running update 3? If you visit the cf admin, or dump the server. coldfusion.productversion, that will confirm this, reporting 2025.0.03... (While you may well be "spinning up a new container", and that may be based on the "adobecoldfusion/coldfusion2025" image, note that unless you've "pulled" that recently, docker could be using its cached image running an OLDER cf update that was pulled down previously on your end.) Most important, even if it IS update 3 (reporting 2025.0.03...), can you confirm that's NOT due to your having run the cf update from the container, such as via the CF Admin or via the command line. That's POSSIBLE to do within a container, though it's NOT the recommended approach (which is instead to use the already-updated image, such as with new 2025.0.3 image tag). Finally, do you use the CF image's installModules or importModules env vars, to name packages to implement at container startup? If so, do you name any version number for them? Sometimes in pinning a package to a version, that causes cf to unexpectedly DOWNGRADE the cf core to an earlier version.    Those last 2 points are  key because if you did either, then (just like with any cf instance) your problem could be caused by an error during the update of cf or of the packages. There are logs for that, within the container, like in any cf instance's cfusion/logs folder.   Then, too, if you DID run the update within the container (my point 3 above), then it may be that you need to "clear the felix-cache folder"-- again, like with any cf instance, and as is discussed in many of the cf update technotes.   This should NOT be necessary if you're using the latest image (and are NOT UPDATING it or its packages). But I bring it up since you now refer to using containers.   Sorry for so much to consider, beyond what also BKBK is proposing. Hopefully the correct answer for you will become clear soon.  ... View more

Good to hear. As for the port, again that's jetty rather than solr. If you're wanting to ensure solr is gone, if it's no longer in that cfusion/jetty/webapps  (as either a war file or folder), then it can't be served via jetty (that port), and so it's gone with respect to this implementation within cf.   I'll just remind readers that if someone gets the separate cf add-ons installer, that defaults to implementing itself in a folder separate from cf. So you'd want to remove THAT to ensure "no solr related to cf remains".   BTW, when Adobe updates CF, some of those updates do update solr. I see that the Oct 2024 cf update for cf2023 updated its solr 8, and the same one for cf2021 updated its solr 7. Finally, newer cf versions implement still newer solr versions, with Cf2025 coming with solr 9. ... View more

Oh, great. So you're confirming that adding the jvm arg has worked (for now)? If so, could you mark as "the answer" my original reply proposing this arg?   Then, for your sake, are you and your developer digging deeper to find and resolve the root cause problem in that cfc remote method being called, due to the change introduced by that May update? See the links I've offered, for more. As always, just trying to help.  ... View more