Solved Cron don't work

Code:
crontab -e
30 8 * * * /home/pal/cleaner
Code:
crontab -l
30 8 * * * /home/pal/cleaner
cleaner
Code:
#!/bin/sh
# cleanup

cd /var/log
cat /dev/null > messages
cat /dev/null > wtmp
cat /dev/null > cron
cat /dev/null > dmesg
cat /dev/null > maillog
cat /dev/null > Xorg.0.log
cat /dev/null > anaconda.log
cat /dev/null > anaconda.ifcfg.log
cat /dev/null > anaconda.syslog
cat /dev/null > anaconda.xlog
cat /dev/null > auth.log
cat /dev/null > btmp
cat /dev/null > boot.log
cat /dev/null > dracut.log
cat /dev/null > last.log

cat /dev/null > messages
cat /dev/null > ntp.log
cat /dev/null > mount.today
cat /dev/null > ipfw.today
cat /dev/null > security
cat /dev/null > unbound.log
cat /dev/null > setuid.today
cat /dev/null > debug.log
cat /dev/null > dmesg.today
cat /dev/null > dmesg.yesterday
cat /dev/null > ipfw.yesterday
cat /dev/null > daemon.log
cat /dev/null > rinetd.log
cat /dev/null > utx.log
cat /dev/null > utx.lastlogin
The script works from the command line.
 
Is the cleaner script readable and executable? Meaning its permissions have the r and x flags? For the correct owner? Remember, the script will be run as the owner of the crontab file.

And: With normal permissions, the script above will not work, because normal users (such as "pal") can't modify files in /var/log. Unless pal is root (has user id 0).
 
Is the cleaner script readable and executable? Meaning its permissions have the r and x flags? For the correct owner? Remember, the script will be run as the owner of the crontab file.

And: With normal permissions, the script above will not work, because normal users (such as "pal") can't modify files in /var/log. Unless pal is root (has user id 0).
ls -l cleaner
-rwxr-xr-x 1 nat nat 1010 Jul 23 07:17 cleaner
 
sudo chown pal : pal cleaner
Password:
pal@cel:~% ls -l cleaner
-rwxr-xr-x 1 pal pal 1010 Jul 23 07:17 cleaner
 
Last edited:
Thanks after:
sudo chown pal : pal cleaner
Password:
pal@cel:~% ls -l cleaner
-rwxr-xr-x 1 pal pal 1010 Jul 23 07:17 cleaner

all works
 
Last edited:
I rejoiced too early, cron starts
Jul 24 09:00:00 cel /usr/sbin/cron[21730]: (pal) CMD (/home/pal/cleaner )

but does not clear the logs fully:


>sudo ls -la /var/log
Password:
total 44840
drwxr-xr-x 2 root wheel 1024 Jul 24 08:12 .
drwxr-xr-x 25 root wheel 512 Jul 18 15:20 ..
-rw------- 1 root wheel 4777 Jul 24 09:16 auth.log
-rw------- 1 root wheel 33768 Jul 24 09:15 cron
-rw------- 1 root wheel 93080 Jul 24 03:01 dmesg.today
-rw------- 1 root wheel 338 Jul 24 03:01 ipfw.today
-rw-r----- 1 root wheel 1161 Jul 24 09:00 maillog
-rw-r--r-- 1 root wheel 9742 Jul 24 09:16 messages
-rw------- 1 root wheel 146 Jul 24 03:01 mount.today
-rw------- 1 root wheel 2917 Jul 24 03:01 setuid.today
-rw-r--r-- 1 unbound unbound 22723235 Jul 24 09:16 unbound.log
-rw-r--r-- 1 root wheel 197 Jul 24 09:16 utx.lastlogin
-rw-r--r-- 1 root wheel 2853 Jul 24 09:16 utx.log
For example maillog

Jul 24 00:00:00 cel newsyslog[19800]: logfile turned over
Jul 24 03:02:38 cel dma[324918c][20468]: new mail from user=root uid=26 envelope_f>
Jul 24 03:02:38 cel dma[324918c][20468]: mail to=<root> queued as 324918c.55e87fe4>
Jul 24 03:02:38 cel dma[324918c.55e87fe47000][20473]: <root> trying delivery
Jul 24 03:02:38 cel dma[324918c.55e87fe47000][20473]: <root> delivery successful
Jul 24 03:02:41 cel dma[324918e][20556]: new mail from user=root uid=26 envelope_f>
Jul 24 03:02:41 cel dma[324918e][20556]: mail to=<root> queued as 324918e.49a674c4>
Jul 24 03:02:41 cel dma[324918e.49a674c47000][20559]: <root> trying delivery
Jul 24 03:02:41 cel dma[324918e.49a674c47000][20559]: <root> delivery successful
Jul 24 09:00:00 cel dma[324918c][21732]: new mail from user=pal uid=1006 envelope_>
Jul 24 09:00:00 cel dma[324918c][21732]: mail to=<pal> queued as 324918c.3720ba047>
Jul 24 09:00:00 cel dma[324918c.3720ba047000][21743]: <pal> trying delivery
Jul 24 09:00:00 cel dma[324918c.3720ba047000][21743]: <pal> delivery successfu

In the command line, the script cleans logs without problems
#!/bin/sh
# cleanup
cd /var/log
cat /dev/null > messages
cat /dev/null > cron
cat /dev/null > maillog
cat /dev/null > auth.log
cat /dev/null > unbound.log
cat /dev/null > utx.log
cat /dev/null > utx.lastlogin
cat /dev/null > dmesg.today
cat /dev/null > ipfw.today
cat /dev/null > setuid.today
cat /dev/null > mount.today
 
does the cron service run - what gives
Code:
$ ps faux | fgrep cron
home/pal >ps faux | fgrep cron
root 4172 0.0 0.0 13944 2656 - Is Fri13 0:01.29 /usr/sbin/cron -s
pal 21858 0.0 0.0 13836 2352 6 S+ 09:33 0:00.00 fgrep cron
 
Then who can?
root
It was alreadys said by others, but maybe they were not clear enough:

If you want to run a root's job with cron you have to use root's cron.

But as also already said I strongly recommend to reconsider what you're trying to do.
Sure, there are lots of log files - and that is a good thing.
A FreeBSD newbie may find them just as wasted space. But they are very valuable - even if it's figured out later.
They also don't use that much space. In a 'normal' today's system the storage space they need are negliably.
I strongly recommend to keep them, or at least clean them reasonbly, but not nuke them periodically.

But if you really get storage issues because /var/log grows too large (maybe because you have a multiuser system with very much traffic on a machine with tiny storage...) you may reconsider your setup, look for another way to store them, but I recommend to keep them.
 
My rinetd.log has grown to 860 GB after repelling the password generator attack. (4 GB per minute).I disabled rinetd but I will need it soon
The unbound.log is also growing rapidly.
 
Thanks, but I don't think it's much easier than
Yes, it's so easy you haven't been able to make it work. Besides that, it's not the only thing you have in your scripts, /var/log/messages for example (which is already taken care of with newsyslog(8)), or /var/log/utx.log, /var/log/utx.lastlogin, which you really, really don't want to get messed up.

Seriously, use newsyslog(8)/newsyslog.conf(5).

Code:
mkdir /usr/local/etc/newsyslog.conf.d/
echo "/var/log/rinetd.log                       600  7     1000 *     JC" > /usr/local/etc/newsyslog.conf.d/rinetd.conf

There. That's a basic entry. It might need a signal, to reopen the log file after it got rotated, but I don't use rinetd so can't really test it.

Run # newsyslog -v to check if the rotation works. Maybe adjust the number of old logs it should keep, or how often it gets rotated, or how big it may get. Plenty of simple variables to change in order to adjust for the amount of storage you're willing (or able) to use for logging.
 
Code:
crontab -e
30 8 * * * /home/pal/cleaner
For the love of God, put system maintenance tasks into the system‑wide /etc/crontab (or a /etc/cron.d/… file).​
[…].log has grown to 860 GB […]
[…] cat /dev/null > rinetd.log
Why don’t you say so? Focus your “solution” on the problem – unnecessarily huge log files – by checking their size. If you insist on the sledgehammer method, use truncate(1):​
Bash:
#!/bin/sh
#        name: cleaner
# description: nuke logs exploding in size
#      author: kerogaz <mailbox@somewhere.anywhere>

# Find files allocating 1 GiB or more worth of 512 B-blocks
# and truncate them to a size of 0 B.
exec find /var/log -size +1G -exec truncate -s 0 '{}' '+'
 
Thanks, but I don't think it's much easier than
#!/bin/sh
cat /dev/null > rinetd.log
well, as others also pointed out: log rotation via newsyslog(8)() *is* much easier - especially because it deals with things like services that need e.g. a SIGHUP to re-open their logfile, logfiles in some special or binary format and file modes/owner:group properties.

For maintenance tasks you should always use the system-provided mechanisms - they are proven to work reliably and you can simply come back in several moths/years and follow the manpage to change/extend your configuration instead of having to remember some 'very special non-default way'.
 
Thanks, but I prefer sending log contents to a "black hole" cat /dev/null . You won't get confused in Arch, Debian and Rocky it works and newsyslog is missing there, but for rotation you still need to write a more complex script.I clean logs in all these systems like this and don't get confused.
I try to use commands common to all systems, rather than a local exotic product
 
Understanding what you are doing is far more valuable (today and beyond) than just copying something from another operating system.

Just because something works in one Linux distribution doesn't mean it will work in another and it certainly doesn't mean it will work in FreeBSD, Solaris, AIX, HP-UX etc etc etc... in fact its a good way to get in trouble :)

Good luck!
 
You won't get confused in Arch, Debian and Rocky it works and newsyslog is missing there, but for rotation you still need to write a more complex script
Linux typically uses logrotate.conf(5). And its scripts are indeed a bit more complex than FreeBSD's, but not that complex.

Thanks, but I prefer sending log contents to a "black hole" cat /dev/null .
You know you can just turn logging off, right? Remove the logfile line from rinetd.conf. Why log something and send it to a blackhole?
Code:
       By  default,  rinetd  does not produce a	log file. To activate logging,
       add the following line to the configuration file:

       logfile log-file-location

       Example:	logfile	/var/log/rinetd.log
rinetd(8)
 
Linux typically uses logrotate.conf(5). And its scripts are indeed a bit more complex than FreeBSD's, but not that complex.


You know you can just turn logging off, right? Remove the logfile line from rinetd.conf. Why log something and send it to a blackhole?
Code:
       By  default,  rinetd  does not produce a    log file. To activate logging,
       add the following line to the configuration file:

       logfile log-file-location

       Example:    logfile    /var/log/rinetd.log
rinetd(8)
Skript for Debian
root@ivpn:/etc/cron.hourly# cat logrotate
#!/bin/sh
/usr/sbin/logrotate -s /var/lib/logrotate/status /etc/logrotate.conf
 
Back
Top