Skip to main content

Screenshot 2020-11-23 at 10.47.43In order to control the file system size I have setup a automatic System Cleanup that works on one of our custom shared resources. This was setup a couple of days ago, but it seems that this process was not run.

 

  • Is there a place where I can see the System Cleanup runs? Neither in the logs or jobs could I find any reference to this.
  • Is there a setting at what time of the day this is run?
  • What privileges are needed for the service to delete the files?
  • What defines the filesystem user for, for example, the "fmeupload" files?

I have used the following System Cleanup task definition, which should be run every day. However, in the folder structure I can see folders and files older than 1 month already.

 

Update

After restarting the FME Core, it now correctly logs the event of checking if it can delete the logs once every day. It however does not delete the logs. It looks like that all the files are owned by "root:root". Not something I would expect from a service ran by "fmeserver".

 

 

Have you looked in the clean up log, located here:

Resources / logs / service / current / fmecleanup.log

 


Have you looked in the clean up log, located here:

Resources / logs / service / current / fmecleanup.log

 

Interesting, was not aware of this one. It seems that nothing is happening in there for 2 months.

 

I have ran the following command to list all of the older logs: 

grep -v RequestHandler-Thread /data/fmeserverdata/resources/logs/service/old/**/*fmecleanup*.log

The last 2 months, I only see the message of "Continued from <older log file>". The last useful information before that is a disk trigger for cleaning up the system ("Starting cleanup due to one or more Low Disk Condition alarms being triggered"). Could it be that the internal service is 'corrupted'?


The problem was related to the engine not writing the engine files (logs) to the core folder with the same user ("fmeserver") as the core was running on. Making sure both are using the same (default) user fixed this.


Reply