Harry Putnam wrote: > Chris Bannister writes: > > Harry Putnam wrote: > >> Logrotation is not happening for some reason, so stumbling around A cron related problem. > > What is output of: > > apt-cache policy logrotate Just to show that you do have logrotate installed. You do. So it is on the cron side of things. > >> investigating and ran up on /etc/cron.daily/apt > > > > Are we on the same page here? > > Not really sure what you mean there. I think that comment was basically that /etc/cron.daily/apt doesn't have anything to do with log rotation. So you are barking up the wrong tree. For log rotation you would look at cron. Cron calls logrotate. Logrotate loads /etc/logrotate.conf, which loads /etc/logrotate.conf.d/* which includes the configuration of which log files to rotate. This is all unrelated to apt. > I guess it was a little off the wall, just asking what it does with no > explanation of why I wonder, its just that I was trying to figure out If you had just asked what /etc/cron.daily/apt did and didn't say anything about logrotate then I think the reasoning for the script would have been explained. But since you started out asking about logrotate the switch over to apt was a non-sequitur. Basically /etc/cron.daily/apt is not documented. It does internal housekeeping for apt. Since it is undocumented I can only assume it is some work in progress of the apt team and isn't meant for external consumption. (There. Maybe that will spark someone to document it.) The script itself squirrels away some copies of critical files into the /var/backups directory. That same directory is used for some other useful ad-hoc backups of other files too. The script appears to be able to install security upgrades and other upgrades automatically in conjuction with the "unattended-upgrades" package. For more information I suggest looking into that package. I have my own scheme and so I don't use it and don't know more about it. > why the cron.daily jobs are not getting run. In particular, my logs > are not getting rotated, yet, I see no difficulties when running > logrotate by hand. To be clear that has nothing to do with apt. > Those things happen from /etc/crontab, and logrotate gets run out of > /etc/cron.daily, along with all the other scripts in there (shown > below) Yes! Exactly such. > I'm still homed in on /etc/cron.daily/apt as possible culprit. Here's > why: The way /etc/crontab executes run-parts, > > test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) What does that have to do with apt? > But anacron just runs the same `run-parts' command when it was missed > at the regular /etc/crontab specified time, so testing Sorry, but those words did not parse. Do you have anacron installed? The above line does nothing if anacron is installed. The test || case means that the test -x is true and so the OR part right hand side is never tried. It is only run if anacron is not installed. A "normal" system (normal to me) is one that does not have anacron installed. Then cron runs. Cron reads /etc/crontab and /etc/cron.d/* and acts upon all of the configuration files. /etc/crontab configures to run-parts all of the scripts in /etc/cron.daily/* and others. A laptop system or other mobile device may not be power up and online during those fixed times. Therefore anacron may be used on those devices to opportunistically run cron tasks not at specified times but at intervals. Intervals not times. Once a day at some time that the device is powered on anacron will run the daily tasks. When? Whenever it meets the anacron criteria. See the anacron documentation for all of the details. It isn't as specified by /etc/crontab and it isn't on a fixed schedule. It is opportunistic. I think perhaps you have anacron installed and the opportunistic nature of it is creating confusion. If so then you might consider removing anacron from your system and then returning to the normal traditional Unix behavior of cron running tasks at fixed times. > `cd / && run-parts --report /etc/cron.daily', like this: (from /) > > time run-parts --report /etc/cron.daily > > real 25m20.071s > user 0m5.876s > sys 0m16.549s Sure. Doesn't seem out of limits from my systems that take a long time to index files. > It seems to take an exceptionally long while... That is typical. If you have long running tasks in the cron.daily directory then it will take a while. Look at anything that indexes the disk such as *locate* or *find* scripts. There are several packages that index files and those take a considerable amount of time to run. Also if you have a networked file system environment then you may need to configure those index scripts to avoid crawling through network mounted file systems. Taking a long time will not affect logrotate. Whether it happens immediately or happens after a half hour the logrotate will still happen. $Begin sales pitch for dateext$ This is an opportunity for me to mention the "dateext" option. This is a wonderful SuSE addition to logrotate and all of the distros now have it available. Instead of rotating logs to .1, .2, .3, and so forth where every day every file changes (more noise, more backup traffic) the "dateext" option turns on date encoding. Then backups are made once by date and the file never changes again until it is removed when it expires. To enable this add this option to the /etc/logrotate.conf file. I usually add this comment too to document it like the other options in the file. # Archive old versions of log files adding a daily extension like # YYYYMMDD instead of simply adding a number. dateext And with that configuration I end up with this type of file naming from the rotation. And so backup is less noisy since every file does not need to be backed up every day. The $DATE.gz files are static once created. -rw-r----- 1 root adm 686247 Oct 6 15:31 syslog -rw-r----- 1 root adm 1525309 Oct 6 06:53 syslog-20131006 -rw-r----- 1 root adm 250863 Sep 30 06:53 syslog-20130930.gz -rw-r----- 1 root adm 228334 Oct 1 07:03 syslog-20131001.gz -rw-r----- 1 root adm 267986 Oct 2 06:54 syslog-20131002.gz -rw-r----- 1 root adm 232099 Oct 3 06:46 syslog-20131003.gz -rw-r----- 1 root adm 195849 Oct 4 06:54 syslog-20131004.gz -rw-r----- 1 root adm 182438 Oct 5 06:48 syslog-20131005.gz $End sales pitch for dateext$ > ls /etc/cron.daily > > 0anacron aptitude dpkg man-db samba > apache2 bsdmainutils htdig mlocate sendmail > apt debsums logrotate passwd spamassassin You have mlocate installed. That would have been my guess at what takes a long time. It will index the disk. > and I'm not seeing any messages from cron about `run-parts' If cron.daily produced output that would produce bug reports from annoyed admins that it was producing output. If there aren't any errors then there should not be any output. > And shouldn't I be seeing some kind of report from cron about > `run-parts'? No. It should be silent unless there is an error or other abnormal output to report. Can you imagine the outrage if a pristine installed system mailed out every day? Most people would not even read the mail and it would eventually fill up the disk. > Once it gets past that nasty apt script... the other scripts finish > quickly. > Running that `apt' just by itself takes: > > time /etc/cron.daily/apt > > real 25m22.866s > user 0m0.608s > sys 0m0.088s > > So, its clear the absolute biggest time sink is `apt'.. And like I > said, I had a hard time following the action, trying to read it. Wow. The apt script takes a while to run? > Is 25.5 minutes normal for that script? No. On my system it runs very quickly. # time /etc/cron.daily/apt real 0m0.456s user 0m0.356s sys 0m0.004s Perhaps you have configured one of the controls for that script to do something such as to 'apt-get update' pulling fresh index files. Or 'apt-get upgrade -d -y' such that it will automatically download packages that are candidates for installation. Or some other. Any of those actions may take a while as the system must interact with the network and download much data. If I were looking I would run the following and browse the output and look to see what it is doing. time sh -xe /etc/cron.daily/apt 2>&1 | tee /tmp/cron.daily.apt.trace Also if you have "unattended-upgrades" installed then the presence of those files may be producing actions that take a while. You might try removing that package if you have it and seeing if that is what is slowing things down for you. Hope these hints lead you to the root cause and understanding of your problem. Bob
Attachment:
signature.asc
Description: Digital signature