Scalix Shutdown due to Log & Temporary Files

[crankshaft]

Hi;

Well Scalix had mysteriously shut itself down twice over the last 4 days, the last time I managed to just restart it, but when I tried today I got the error:

File System / Full (or something very similar similar)

So I executed du -h > folders.txt and opened the file and searched for any folders which were larger than 1 GB (probably a easeir way to do this from the commandline) anyway, my drives were full and the culprit sure enough was scalix.

Firstly, the catalina.out log file was 27GB, then in the var/opt/scalix/de/s/temp folder there were thousands of .mim .ofd .ofa and ofd.gz temporary files going back to when scalix was first installed.

So anyway, I needed to get the server up so I deleted the catalina.out files and all of the other temporary files older than yesterday and scalix restarted.

But Now I want to prevent this from recurring again, I have done a quick search of the forums and can't seem to find the answer, I will also google it and see if I can come up with something.

I guess what I need to do is to minimize tomcat's logging and understand how to prevent or manage all of these temporary files !

Any ideas.....


P

Thanx

[aherbert]

I had this same problem and was counseled to schedule a periodic run of omscan.

Something like this :

Code: Select all

omscan -Aavfx

I put it in cron to run nightly.

[crankshaft]

Hi;

Well after googling, and searching these forums for snippets, I managed to discover that the logging can be configured for rollover by editing the log4j.properties file:

# switch on or off level and log destinations here
log4j.rootLogger=INFO
# log4j.logger.com.scalix.caa.util.CAALogger=INFO, file
log4j.logger.com.scalix.caa.util.CAALogger=ERROR, R

I have configured it to only show ERRORs and to create a R ollover file, rather than one huge ever growing file.

I guess that many of you already know this, but if not it is only a matter of timne before your log file grows so big that it will consume the entire hard drive !

What I need to solve now is those 30,000 temporary files !

PeterC

[crankshaft]

Something like this :

Code: Select all

omscan -Aavfx

Hi thanks, but I am curious, does this delete all of the temporary files or ???

Cheers

[jryden]

I would really like to see one authoritative and official answer on what to do with the temporary files too... You would think there would be one?

[ls-al]

I would really like to see one authoritative and official answer on what to do with the temporary files too... You would think there would be one?

the most official answer to this is in

Code: Select all

man omscan

SCNR

I would advise everyone to use and understand http://www.scalix.com/wiki/index.php?title=Admin_Resource_Kit#Basic_monitoring_of_Scalix_with_ommaint

[mikethebike]

I would also recommend protecting your service by having a seperate mount point for your logfiles.

Those ofd files should only be created while one of your users is setting up offline folder sync, they sometimes hang around if that process fails, so maybe set up a cron job to delete those if they are more than 2 days old? The .gz ones must have been created manually bu someone...maybe who does not understand what they were for?

I would also say that if you have a regular housekeeping job that shuts down scalix to do backups etc, you can safely delete all the files in temp while scalix is down.

Mick

[jryden]

I would really like to see one authoritative and official answer on what to do with the temporary files too... You would think there would be one?

the most official answer to this is in

Code: Select all

man omscan

SCNR

I would advise everyone to use and understand http://www.scalix.com/wiki/index.php?title=Admin_Resource_Kit#Basic_monitoring_of_Scalix_with_ommaint

As we do. Ommaint is a pretty basic thing to set up on your server the first thing you do if you plan on running this in production. Ommaint and ommscan do NOT help with the temporary files though, so if that is the official response, the official response doesn't work. There are still tons of files in the temporary folder after an omscan, dating all the way to when the server was first installed about 1.5 years ago.

[ls-al]

[...

As we do. Ommaint is a pretty basic thing to set up on your server the first thing you do if you plan on running this in production. Ommaint and ommscan do NOT help with the temporary files though, so if that is the official response, the official response doesn't work. There are still tons of files in the temporary folder after an omscan, dating all the way to when the server was first installed about 1.5 years ago.

what is the omscan command line from your ommaint-tool?

If my answer would be an official response you would see another logo.