Manually executing a logfile rotation using logrotate

If you change some parameters in /etc/logrotate.conf or /etc/logrotate.d/* the most common way to use the new configuration is to call logrotate like:

logrotate /etc/logrotate.conf

That way will read the whole configuration of logrotate using parameters like minsize, age and so on.

But you can force logrotate to ignore those parameters so the rotation will happen even if the size is smaller than minsize (minsize as an example)

Simply call logrotate as seen from above with the -f parameter:

logrotate -f /etc/logrotate.conf

Setting the tab-width in a linux-shell

If you don’t use the same tab-width whithin all your favourite applications then the following might happen from time to time:

mail:/tmp# cat /etc/crontab

0  *  *  *  *     root     /usr/bin/php /root/bin/check_open_ports.php
5    2  *  *  *    root    /root/bin/wittnet_check.sh
18    22  *  *  *    root     /root/bin/check_sites.sh
0     19  *  *  *    root     /root/bin/check_diskspace.sh
0    6  *  *  *    root     /root/bin/daily_db_backup.sh
0      6  *  *  *    root     /root/bin/postgresql_backup.sh
0      7  *  *  *    root     /root/bin/ics/start.sh
0    0  *  *  *    root     /root/bin/learn_spam.sh

This is the output of a crontab which was usually modified by vi(m) and because of the different indentations this looks really bad. In vim i’m using a tab-width of 4 characters, in the shell my tab-width is … unknown!

Unknown until now – I’ve found the tabs command which takes one parameter and this parameter is the size of a tabulator in chars. With tabs it’s easy to set the tab-width in a shell which will be used by programs like cat, tail, …

mail:/tmp# tabs 4
mail:/tmp# cat /etc/crontab

0   *   *  *  *    root     /usr/bin/php /root/bin/check_open_ports.php
5    2  *  *  *    root     /root/bin/wittnet_check.sh
18  22  *  *  *    root     /root/bin/check_sites.sh
0   19  *  *  *    root     /root/bin/check_diskspace.sh
0    6  *  *  *    root     /root/bin/daily_db_backup.sh
0    6  *  *  *    root     /root/bin/postgresql_backup.sh
0    7  *  *  *    root     /root/bin/ics/start.sh
0    0  *  *  *    root     /root/bin/learn_spam.sh

Now everything look’s fine and it’s easier to read this crontab as it was before.

Crontabs and Cronjobs

Introduction

Crontab is one of the famouse services on a linux- and unix-system which hasn’t changed over decades. The configuration-layout is still the same as it was many years and more ago.

Crontab is a system service which starts shell-scripts or programs on a given date and/or time. Each user has his own crontab which can be modified by using the command crontab -e. A typical crontab looks like the following:

*  *  *  *  *   <scriptname>

The first column (first star) represents the minute. The second one the hour followed by day, month and weekday (where 0 means sunday) You can take the example from above if you want to execute your script or command each minute. The placeholder * stands for “every”.

A more realistic example will look like the following. In this case a program named /usr/local/bin/test starts daily at 10 O `clock:

0  10  *  *  *   /usr/local/bin/test

Intervals

In order to define intervals, simply add a slash followed by the interval specified. The following entry starts the program every 5 minutes:

*/5  *  *  *  *   /usr/local/bin/test

Handling output- and error-messages

One must make sure that the script did not output generated because this is the current user by e-mail sent . Runs Amok a job so it can easily be suddenly thousands of messages in the mailbox waiting .

In order to prevent this , the output will be redirected directly in crontab:

0  10  *  *  *   /usr/local/bin/test &> /dev/null

In that case the whole output will be redirected to /dev/null

Using Scripts which are not stored in PATH

A simple user doesn’t have write-permissions to locations like /usr/bin, /bin and so on. Many user will save their scripts to /usr/local/bin but that path isn’t known by the most linux-systems per default.

So you have to extend the PATH-variable with /usr/local/bin. If you only call the script from within cron the best place for modifying PATH will be in the crontab itself. To do this simply add the following PATH-entry to your crontab (Check your current PATH-value and just add /usr/local/bin to it, don’t you use my example if you’re not sure because some path may be missing and this will possibly break your crontab as program’s won’t be found anymore)

PATH=/usr/local/bin:/usr/bin:/bin

0  10  *  *  *   /usr/local/bin/test &> /dev/null

/etc/crontab

This is the system-wide crontab. It is similar to the user crontab with the difference that the user, under which the script/program is executed, has to be specified.

PATH=/usr/local/bin:/usr/bin:/bin

0  10  *  *  *   root  /usr/local/bin/test &> /dev/null

In this case, our script will be started as the root user.

Keep-Alive of SSH connections

Who constantly keeps numerous SSH connections open knows the problem. If you in a compound just not as active as it can happen that the connection breaks off. The reason for this are usually SSH-setting of the client and the SSH server. These detect some “inactivity” (no traffic on the lines going) and end the session.

To prevent this, there is a SSH option named keep-alive specifically located in /etc/ssh/ssh_config and is called:

ServerAliveInterval 5

The interval refers to seconds. In this case, every 5 seconds a keep-alive through the SSH tunnel shipped to signal an activity.