SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It should be completely safe to erase all files under /var/log but if you happen to have some program that creates log files there and for some reason goes crazy if no existing file is present (should not be so), you could just as well clear the files instead of removing:
Code:
echo "" > /var/log/syslog
(for example like that)
But like I said, it should be ok to remove them too. It's a different matter if you happen to need the logfiles afterwards, but surely if they're as big as 100M/file, they have quite a lot of (oldish) information inside and if you feel you don't need them, go ahead and remove Or if you feel troubled, move everything under /var/log/ off to some other directory, and if everything still works after that (i.e. after a day or two), remove the contents you moved away. Basically if a logfile doesn't exist, logger should just create it. I myself remove logfiles from time to time if there's nothing interesting in them, and there's no use to have them (at least on the root partition; maybe at some backup location, if needed later?) wasting space more than is really needed. It's very useful to have logfiles over some period of time, in case you face troubles (then you're able to compare the logs to see what is going wrong), but definitely there's no use having too old information there at your /var. If you have an external disc you store backup data, maybe move the logs there and next time you face this situation, remove old logs and move newer ones there again etc..that way you have logs over a good period of time without having to waste precious disk space.
Yeah, look up LOGROTATE. I have syslog moved to syslog.1 and syslog.1 moved to syslog.2 every week. Once it hits syslog.4 it is deleted. That way I have nothing over a month old in the var/log.
The config file is /etc/logrotate.conf
Actually, interesting thing about logrotate. It's default is set to switch the logs at 3 in the morning or so. My computer is never on at that time, so I always have it check to see if they need rotated at bootup.
Actually, interesting thing about logrotate. It's default is set to switch the logs at 3 in the morning or so.
No, that's not logrotate but cron. If you choose Vixie crond you'll have nifty shortcuts like "onboot" which, as the name suggests, runs entries you want when you boot the box. If you, for some obscure reason, don't favour Vixie the look into Anacron.
In /var/log there was some .1 .2 .3 .4 files.
Yes, that's logrotate w/o the compression setting.
now, uhhh, can't you just put things you wanna run on boot in '/etc/rc.d/rc.local' ?
Theoretically: yes.
Practically: in case of log-file deletion, no. Because
rc.local is the last thing that runs before logins become
allowed/possible; but for logrotate it would work, it's
just that all process that would be writing to logs will
need to be HUPed right after they started
Yes, that's logrotate w/o the compression setting.
Found the thread interesting and informative, so I took a look at my own system. Obviously, Debian sets this thing up to run automatically, because I sure never initialized it.
There are lots more, of course, but this sample shows the variable treatment received by the different logs. "syslog" gets 6 generations saved with compression; "aptitude" gets 5; "vsftpd" gets only 4, and no compression.
There must be more to how this works than the information that can be seen in /etc/logrotate.conf
This seems to be the applicable lines from there:
Code:
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
#compress
Even though the "compress" line is commented, most of my generational logs are compressed.
I'm not really looking for a solution since I don't consider the way logs are being handled a problem, but a brief explanation of why they are handled differently would be gratifying.
Obviously, Debian sets this thing up to run automatically
I'd think most distro's would do that by now?..
I don't consider the way logs are being handled a problem,
Say that again after Apache is mysteriously dying on you and you don't know why ;-p
but a brief explanation of why they are handled differently would be gratifying.
The "why" part starts by looking in /etc/logrotate.d. You'll see per-daemon logs and syslogs grouped since they are opened by one single daemon. As for using no compression IIRC that's the shipped defaults. Why it's that way is beyond me. It's one of those post-install things to correct. * As far as there's any "fun with logrotate" to be had, look for pre and postrotate clauses: you can for instance strip stuff out of logs or run a parser before you rotate or send alerts after rotation. Come in handy wrt reporting and such.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.