Managing Log Files Created by Cron Jobs

How to log cron jobs?

* * * * * myjob.sh >> /var/log/myjob.log 2>&1

will log all output from the cron job to /var/log/myjob.log

You might use mail to send emails. Most systems will send unhandled cron job output by email to root or the corresponding user.

Remove log files using cron job

Use wildcard. And just put it in your crontab use the crontab -e option to edit your crontab jobs.

See example:

* * * * *  find  /path/to/*.log -mtime +7 -exec rm -f {} \; 

Just to increment the answer check this nice article on how to work with your crontab ! in Linux .

How can cron output to a new log file based on date?

This will fix your issue:

0 0 * * * /some/path/to/a/file.php >> /tmp/log/cron-`date +\%F`.log 2>&1

How to manage logs of two seperate cron in a single project in java

Spring by default uses a single threaded Executor. so no two
@Scheduled tasks will be execute simultaneously. even if there are two
@Scheduled methods in completely unrelated classes will not overlap
and that is because there is only a single thread to execute tasks.

the only possiblity for task to be executed at the same time is to have multi thread executors which defined as:

@EnableScheduling
@Configuration
public class MyConfiguration implements SchedulingConfigurer {

    @Override
    public void configureTasks(ScheduledTaskRegistrar 
     scheduledTaskRegistrar) {
        scheduledTaskRegistrar.setScheduler(taskExecutor());
    }

    @Bean(destroyMethod="shutdown")
    public Executor taskExecutor() {
        return Executors.newScheduledThreadPool(5);
    }
}

• If you have such custom configuration that defines a thread pool for schedule tasks, you should remove it.

cron that keeps a log of file names that it removes

If you add -print to your cron job command line, cron prints the names of the files it deletes. If you put your commandline into a script you have more flexibility in controlling where the output goes.

access logs in cron jobs kubernetes

I guess you know that the pod is kept around as you have successfulJobsHistoryLimit: 3. Presumably your point is that your logging is going logged to a file and not stdout and so you don't see it with kubectl logs. If so maybe you could also log to stdout or put something into the job to log the content of the file at the end, for example in a PreStop hook.

creating cron job that sends output to file every day and overwrites this file every month

You could run it every day but use date +%w to print the day number and act differently (call with > to clobber the file instead of >> to append) based on that.

Note that some cron daemons require % to be escaped, hence \%.

# Run every day at 00:30 but overwrite file on Mondays; append every other day.
# Note that this requires bash as your shell.
# May need to override with SHELL=/bin/bash
30 00 * * * if [ "$(date +\%w)" = "1" ]; then /your/command > /your/logfile; else /your/command >> /your/logfile; fi

Edit:

You mention in comments above that your actual goal is log rotation.

The norm for Linux systems is to use something like logrotate to manage logs like this. That also has the advantage that you can keep multiple previous log files and compress them if you like.

I would recommend making use of a logrotate config snippet to accomplish your goal instead of doing it in the cron job itself. To put this in the cron job is counter-intuitive if it's merely for log rotation.

Here's an example logrotate snippet, which may go in a location like /etc/logrotate.d/yourapp depending on which Linux distribution you're using.

/var/log/yourlog {
    daily
    missingok
    # keep one year of logs
    rotate 365
    compress
    # keep the first one uncompressed for ease of viewing
    delaycompress
}

This will result in your log file being rotated daily, with the first iteration being like /var/log/yourlog.1 and then compressed iterations like /var/log/yourlog.2.gz, /var/log/yourlog.3.gz and so on.

In my opinion therefore, your question is not actually a cron question. The kind of cron trickery used above would only be appropriate in situations such as when you want a job to fire on the last Sunday of the month, or the last day of the month, or other criteria that can't be expressed in cron syntax.

---

Related Topics