Lucee-std-out.[datetime].log taking too much space

Hi there :slight_smile:
One of our servers is generating huge amount of logs in the lucee-std-out.[datetime].log
First I thought it was because we restart server every night (for various maintenance tasks) but appears that the log comes back every time (if we can, sometimes we can’t) we delete it, restart or not.

I’m not quite sure of the utility of this log file and what could make it grow like hell (that is above 20 gigs).
Can someone explain to a non dev ops (me)

  • what’s its purpose
  • can it be disabled and/or moved to a dedicated disk and/or limited in growth ?

As it might be (is probably) critical, I don’t want to act blind and some advice from you would be very appreciated as googleing didn’t give me a clear answer about this.

Thanks in advance,

@Antoine_BAPST What sort of output are you seeing which is filling most of the file? For al we know, the output could be coming from your own CFML code, not Lucee.

1 Like

The file is so big, it’s barely viewable as is …
So I’ll dig into it and check that; I believe you may be right but there’s something strange here : other servers have the exact same cfml (and configuration) and don’t behave likely …
Sorry, I should have started here. Will try and come back.

VSCode does a surprisingly good job of opening large files without crashing. Or just use head or tail from bash which will show you X lines of the file. I think you’ll probably find some sort of logging coming from your application or an error happening over and over that you didn’t anbout.

1 Like

Will do thx. Currently copying it over the network to a resource where I can DL it locally.
in the meantime, I found a near-to-zero one on another server, just with a header that could give us a clue:

2023-02-23 03:26:32 Apache Commons Daemon procrun stdout initialized.
[mod_cfml] INFO: Starting mod_cfml version: 1.1.11

Edit : sorry, that’s not anything we can take advantage of. It’s standard tomcat log output.
Thing I didn’t mention, pardon me, is that we’re running under windows/IIS …

So, you’re right.
It’s filled with debug/info from a java custom component.
I believe there’s a version problem here.
Sorry, this was trivial.
Thanks for reminding me the obvious :slight_smile: !