Logfiles must not be deleted automatically

[hlinseisen]

Looking at cs81210 i found:

• Starting with Windchill 10.0 there is a background process that will maintain the number of logs in the Windchill logs folder.
• By default this task will run every 2 days and will remove logs older than 15 days

This meant that i was fighting several days to find out why my logfiles and also other files that i wrote into the logfolder suddenly disappeared.

I even accused our system administration team that they run a cronjob that deletes the files.

Using a filewatcher and process monitor i finally found out that windchill servermanager itself deleted the logfiles.

It's definetly a nice feature if windchill can do this -- but this setting must not be enabled by default !!!

I lost tons of logfiles and transfer data because of this

[jessh]

I guess it's debatable as to what the default behavior should be.  The issue we had without deleting old log files automatically was that smaller customers would let the logs fill up their disk without realizing it.

The important this is that one can change the duration of logs retained, disable the automatic deletion, or even specify a custom action to be performed on stale log files instead of deletion.

[MatthewKnight]

I wonder if there are any customers who have contractual requirements to keep server log files?

Maybe PTC can flag Default Configurations that should be examined and have not yet been confirmed by system administrators.  Or maybe PTC could default a preference to email Administrators X days before the files are deleted, with explanation or links to the options page?

[jessh]

As I see it, all of your questions get at a simple idea: the default behavior should be made quite clear to the administrator so that they are not suprised.

That makes a good deal of sense in any case.

[hlinseisen]

@Mathew we are keeping the logfiles because we also log the transfers to SAP and the transfers from Vpm Catia into the methodserver log files.It's essential for us to keep logfiles in order to be able to reproduce interface issues.

Also it was quite confusing not to know who is deleting files on your system --- I never heard of any other software deleting logfiles in that manner. This should be kept in the responsibility of the administrator.

@Jess

If filling up the disk is the problem PTC could create a job

- that checks remaining disk space and sends an email to the admin and writes a message into the Backgroundmethodserver log file that the disk is running out of space - maybe together with a hint how one can limit the logfiles

The job itself should log the filenames that were deleted --- i couldn't find anything in the logfiles  

[MatthewKnight]

I agree with you, Herbert.

Jess, I don't want to sound like I'm completely knocking the File Deletion feature and step on anybody's toes. It's a neat idea and I see the benefit. And there's no doubt in my mind that the current implementation is going to prohibit frustration for a larger percentage of customers than it will cause frustration. It's just my opinion that a first line of defense (if done without explicit confirmation/acceptance), should be the disk usage monitor idea, or maybe compression, and would definitely send some type of alert or notification.  When i want to manually delete a file - any file - on one of my servers, I'm asked at least twice if I'm sure. And if I don't go out of my way to hit an extra key and shift delete, it goes to the recycle bin where it can still be recovered.  I know that if our logs were needed or requested (which happens occaisionally) and I couldn't fimd them, I'd have some very serious explaining to do. On top of the log files being needed for who knows what in any particular instance, having to explain that I didn't know the system was deleting the files would just be a kick in the teeth.

I hope my opinions didn't come across inappropriately here.  I just want to convey how serious I think it is. If customers were having problems with the size of the StringValue table, I know the solution wouldnt be to delete the customer's data without their explicit consent.

BTW I have no personal experience with whatever version of the software the deletion feauture is implemented in.  I just found out about it in this idea thread.

[jessh]

Having an alert when disk space is running low is a good idea.

Unfortunately, Java didn't have an API allowing this information to be obtained in a cross platform fashion in the release in which the periodic log file cleanup feature was added.

Since that point attributes have been exposed on the MBean to allow one to add a gauge monitor MBean to do such monitoring, but it hasn't been provided out-of-the-box (as it is for file vaults).

[JørnAHansen]

I like the current default.

And I think it was announced somewhere in the documentation when it was first introduced.

If you need the files for a longer period you can always automate to move them away to some kind of archive location. 

[jessh]

I should note that one can enable logging of all such file deletions -- it's just INFO level logging (on the wt.jmx.core.mbeans.ManagedDirView$FileDeleter logger), so you need to increase verbosity on this logger if you want it.

Based on this discussion I did make a small change to 10.2 M020's default behavior.  It will compress files older than 15 days and only delete them after 31 -- with both cutoffs being configurable.

Finally, as Jørn points out, one can easily disable log file maintenance entirely or install your own custom handling of old log files.

[hlinseisen]

Still i doubt a little bit that first time users of PDM Link won't wonder why their logfiles are disappearing or compressed after some time. Logging of the deleted Files should be enabled by default together with a line referring to cs81210.

But the solution is ok for me -- as i know the mechanism now. The compressing  option is great.