Originally posted by: SystemAdmin

I have a job that get started with the 'at' command. The job runs 24x7 until shutdown. All the 'echo' statements from the job gets written a log file (not in /tmp) but also to a crout file in /tmp. The crout file continues to grow until the /tmp filesystem is full. Should I be starting this process by another method (run as a daemon) so they don't fill up /tmp? Thanks.

Originally posted by: orphy

My first question is: Do you need the content of /tmp/crout? Does anyone look at it? For debugging? Anyone? If not, the easiest fix would be to simply symlink it to /dev/null. To really fix the issue, assuming that you have access to the script/source code, just don't send anything unnecessary to stdout but you probably do want to send errors and possibly warnings to stderr. Another fix is to rotate the log file by size/date so that you can properly trim it as needed. It all depends on what you can do with the "job". Simply leaving crout to grow to fill up /tmp is just a bad idea...
Orphy

Originally posted by: SystemAdmin

Nobody needs the crout file. We didn't even know it existed until it filled up /tmp. The crout file contains a subset of my error log.

My error log, which is not in /tmp, contains:

Mon Jun 4 12:58:03 2012: FOSENTSVR275 is reachable
Mon Jun 4 12:58:14 2012: FOSENTSVR275 is reachable
Mon Jun 4 12:58:25 2012: FOSENTSVR275 is reachable
Mon Jun 4 12:58:36 2012: FOSENTSVR275 is reachable
Mon Jun 4 12:58:48 2012: FOSENTSVR275 is reachable
The crout file in /tmp contains:

FOSENTSVR275 is reachable
FOSENTSVR275 is reachable
FOSENTSVR275 is reachable
FOSENTSVR275 is reachable
FOSENTSVR275 is reachable
I think I found the culprit. We have a routine that we call for logging errors. It optionally writes to stdout so there's more usefull info in the mail message that the system sends when a detached process dies. I removed that optional parameter and now an empty crout file is created, but not written to.

Thanks.