Re: Once again about anacron cron cron.daily
Bob Proulx b...@proulx.com writes: The particular part I was pedantically talking about was your comment that said checks that it is executable, yes, all good, and then you go on to say *and* sees to it that this user has permission. It was that last part, the second part of the _and_ that I was pedantically commenting upon. Because while true for non-root for root if it is root there isn't any user test. For the root user it is purely a Alright... at last. I've been laying for a chance to pedantic right back at you... check to see if there is at least one 'x' bit set. The user part does not matter. So the description really stops at the checks that it is executable part. Full stop there. OMG! Did he really say: The user part does not matter. Except when it does ... like when some thoughtful or even sinister user decides to monkey around with cron. So, it has to be said if pedantry is to live and grow... The user part is very important. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hac6abdg@newsguy.com
Re: Once again about anacron cron cron.daily
Harry Putnam wrote: Bob Proulx writes: commenting upon. Because while true for non-root for root if it is root there isn't any user test. For the root user it is purely a Alright... at last. I've been laying for a chance to pedantic right back at you... :-) check to see if there is at least one 'x' bit set. The user part does not matter. So the description really stops at the checks that it is executable part. Full stop there. OMG! Did he really say: The user part does not matter. Yes. But only if in context! For the root user it is purely a check to see if there is at least one 'x' bit set. The user part does not matter. Does not matter for root using test. I should have put both of those into one long run-on sentence like I usually do so the context can't be split but didn't that time. :-) Except when it does ... like when some thoughtful or even sinister user decides to monkey around with cron. As root? Or as non-root? Hard for a non-root to have leverage against cron. And for the root user it isn't a challenge because all files are readable and writable for root. So, it has to be said if pedantry is to live and grow... The user part is very important. Not if you are root using 'test'. It is only important to the poor unwashed masses of non-root processes. :-) Bob signature.asc Description: Digital signature
Re: Once again about anacron cron cron.daily
Bob Proulx b...@proulx.com writes: Harry Putnam wrote: I'm still not getting the whole picture of what is supposed to happen on a machine with both anacron and cron installed. And you might be tired of having me respond about it. :-) Not on your life! I have a certain fondness for descriptive and very helpful posts here. I have lines like the one below in /etc/crontab [...] test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily ) Ok, it tests for the presence of /usr/sbin/anacron, checks that it is executable and sees to it that this user has permission to run it. Yes. The this user part is part that you trimmed off. It runs as the root user. The root user will always have permission. Let me show the part you trimmed off. (Times might be different.) I was trying to say... I 'got' all that. But I think your formulation is a bit off. test -x doesn't care who is running what... it checks to see that the soul calling test -x has permission to run the app it is called against... at least, that was my reading of `man test'. But yes, in our subject case it is expected to be root.. From `man test' -x FILE FILE exists and execute (or search) permission is granted [...] But where and when does anacron actually get called to run? That line appears to expect anacron to be called somewhere else. Yes. The anacron itself is actually called from ... cron! :-) $ dpkg -L anacron /etc/cron.d/anacron ... Bingo, thank you sir... now it starts to make sense... and thanks too for pointing out what I should have thought of as a way to get a clue using `dpkg -L'. And just a small supplement to help you understand why I didn't quite follow the setup... On the first sign of trouble with logs not getting processed, I checked what state anacron was in with `/etc/init.d/anacron status', which gave a blank no reply which made me assume, (apparently wrongly) that anacron was not running. So, I started thinking it was not getting called. [...] /etc/init.d/anacron start. Why invoke-rc.d? Because the local admin may have set up a policy-rc.d configuration that disables it. I was just wondering why `invoke-rc.d', now I get that too, thanks. [...] I've never taken any actions on anacron and don't remember even installing it purposely... so am I supposed to put it into a run level? I can't believe I didn't recommend to you at some previous time that you should probably just remove anacron. Do you need it? If not then remove it. (I would 'purge' it and remove the config files too.) You did, on the very first response to slightly different subject but still involving `cron' and `anacron', might have been on the emacs list though. And about needing anacron. Yes, I guess I'm just the type of user that anacron was designed for. My machine is shut off nearly every day, and sometimes isn't started for a day or two. When it is, there is no rigid pattern time wise. Seems like, if not anacron then I'd need to be a lot more trick and careful with cron scheduling or do some scripting or the like. [...] Or, does it get called somewhere else in the cron setup? Yes! You have guessed it. Also there is apm support. When power is plugged in and unplugged then anacron is run or stopped. Interesting... and good to know. It doesn't effect me at the moment but at some point I will probably have debian running on a laptop. Oh, and I hope you do not tire of answering my often poorly worded queries. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppqw9ok5@newsguy.com
Re: Once again about anacron cron cron.daily
Harry Putnam wrote: Bob Proulx writes: Harry Putnam wrote: I'm still not getting the whole picture of what is supposed to happen on a machine with both anacron and cron installed. And you might be tired of having me respond about it. :-) Not on your life! I have a certain fondness for descriptive and very helpful posts here. Thank you for the kind words! They make my day. Ok, it tests for the presence of /usr/sbin/anacron, checks that it is executable and sees to it that this user has permission to run it. Yes. The this user part is part that you trimmed off. It runs as the root user. The root user will always have permission. Let me show the part you trimmed off. (Times might be different.) I was trying to say... I 'got' all that. But I think your formulation is a bit off. test -x doesn't care who is running what... it checks to see that the soul calling test -x has permission to run the app it is called against... at least, that was my reading of `man test'. True. But it is important to know that the user is root or not. Since root is the superuser it makes a difference. I agree completely with the exact words above. But... But yes, in our subject case it is expected to be root.. -x FILE FILE exists and execute (or search) permission is granted Correct. And the superuser always has execute permission if any execute permission exists. And for reading and writing the superuser always has write permission even if no 'r' or 'w' bits are set. That last also tends to trip people. Test always returns true for the superuser for -r and -w. The particular part I was pedantically talking about was your comment that said checks that it is executable, yes, all good, and then you go on to say *and* sees to it that this user has permission. It was that last part, the second part of the _and_ that I was pedantically commenting upon. Because while true for non-root for root if it is root there isn't any user test. For the root user it is purely a check to see if there is at least one 'x' bit set. The user part does not matter. So the description really stops at the checks that it is executable part. Full stop there. Yes, I am being very pedantic. But the smallest of details can sometimes make very big differences. :-) And just a small supplement to help you understand why I didn't quite follow the setup... On the first sign of trouble with logs not getting processed, I checked what state anacron was in with `/etc/init.d/anacron status', which gave a blank no reply which made me assume, (apparently wrongly) that anacron was not running. Well look at that. I think that is certainly a bug. Or at least a mis-feature. case $1 in status) exit 4 ;; That does not seem right. Anyone on the list care to look up the policy for init scripts and see what they should do if they do not have a daemon? (I have no time at the moment.) So, I started thinking it was not getting called. I can see that happening! It didn't say anything. That isn't nice. /etc/init.d/anacron start. Why invoke-rc.d? Because the local admin may have set up a policy-rc.d configuration that disables it. I was just wondering why `invoke-rc.d', now I get that too, thanks. I think that is too convoluted. The invoke-rc.d was originally intended to be called by dpkg and so policy-rc.d allowed a way to install a chroot'd system but not start daemons that were running in the parent. In the chroot you can install a full system but not have daemons started. Sure it is a general purpose interface and can be used here too but it isn't needed there and I think IMNHO that it just adds confusion by using it there. And about needing anacron. Yes, I guess I'm just the type of user that anacron was designed for. My machine is shut off nearly every day, and sometimes isn't started for a day or two. When it is, there is no rigid pattern time wise. Then it should be perfect for you! :-) Seems like, if not anacron then I'd need to be a lot more trick and careful with cron scheduling or do some scripting or the like. Yes. And since so many people have needed to do it then anacron is better because it is shared among everyone now. Oh, and I hope you do not tire of answering my often poorly worded queries. Not at all. It is fun! Keep them coming. Bob signature.asc Description: Digital signature
Once again about anacron cron cron.daily
I'm still not getting the whole picture of what is supposed to happen on a machine with both anacron and cron installed. I understand the reasoning for machines that are not up all the time, where anacron picks up the slack for cron jobs that came up with the machine down. I get that. But in my case and I'm kind of guessing it is the general case. I have lines like the one below in /etc/crontab [...] test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily ) Ok, it tests for the presence of /usr/sbin/anacron, checks that it is executable and sees to it that this user has permission to run it. But where and when does anacron actually get called to run? That line appears to expect anacron to be called somewhere else. So is anacron supposed to be started at some run level? In my case it is not listed in any run levels. A hasty read of 'man update-rc.d' appears to indicate it is incapable of the most basic job... simply showing the run levels and what is running on them. Maybe there is some better tool, but using rcconf I see that anacron has not been set to run .. no asterisk in box. I've never taken any actions on anacron and don't remember even installing it purposely... so am I supposed to put it into a run level? Or, does it get called somewhere else in the cron setup? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txgamam2@newsguy.com
Re: Once again about anacron cron cron.daily
Harry Putnam wrote: I'm still not getting the whole picture of what is supposed to happen on a machine with both anacron and cron installed. And you might be tired of having me respond about it. :-) I have lines like the one below in /etc/crontab [...] test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily ) Ok, it tests for the presence of /usr/sbin/anacron, checks that it is executable and sees to it that this user has permission to run it. Yes. The this user part is part that you trimmed off. It runs as the root user. The root user will always have permission. Let me show the part you trimmed off. (Times might be different.) 25 6 * * * root test -x /usr/sbin/anacron || ( cd / run-parts --report /etc/cron.daily ) runs as root So basically if anacron is installed then it does nothing. But if anacron is not installed then it basically is the same as this and runs the expected cron.daily. 25 6* * * rootcd / run-parts --report /etc/cron.daily But where and when does anacron actually get called to run? That line appears to expect anacron to be called somewhere else. Yes. The anacron itself is actually called from ... cron! :-) $ dpkg -L anacron /etc/cron.d/anacron ... The cron.d file is file you are looking for. That is the cron table used by cron to run anacron. Ignore the other files for the moment. 30 7* * * roottest -x /etc/init.d/anacron /usr/sbin/invoke-rc.d anacron start /dev/null Personally the above is too convoluted for my taste. But basically this runs anacron by cron. It checks that /etc/init.d/anacron is installed. Why? Because it is a 'conffile' and the local admin may have removed it. If it exists then it calls invoke-rc.d to launch /etc/init.d/anacron start. Why invoke-rc.d? Because the local admin may have set up a policy-rc.d configuration that disables it. It is this last part that I think is too far. If the local admin were to disable anacron wouldn't they also have disabled cron? And if cron is disabled then anacron which is downstream won't be run by it. So I think this is too convoluted. But I wouldn't be surprised to find that it was the result of a bug report. I've never taken any actions on anacron and don't remember even installing it purposely... so am I supposed to put it into a run level? I can't believe I didn't recommend to you at some previous time that you should probably just remove anacron. Do you need it? If not then remove it. (I would 'purge' it and remove the config files too.) But because cron has added anacron in the cron package you will still see anacron lint left behind even if anacron is not installed! Because cron will be installed. And cron has included config for anacron in /etc/crontab. Or, does it get called somewhere else in the cron setup? Yes! You have guessed it. Also there is apm support. When power is plugged in and unplugged then anacron is run or stopped. /etc/apm/event.d/anacron # This script makes anacron jobs start to run when the machine is # plugged into AC power, or woken up. For a laptop, these are the # closest parallels to turning on a desktop. # The /etc/init.d/anacron script now normally tries to avoid running # anacron unless on AC power, so as to avoid running down the battery. # (Things like the slocate updatedb cause a lot of IO.) Rather than # trying to second-guess which events reflect having or not having # power, we just try to run anacron every time and let it abort if # there's no AC. You'll see a message on the cron syslog facility # (typically /var/log/cron) if it does run. So in addition to cron starting anacron it is also run when AC power is applied to the system. Bob signature.asc Description: Digital signature
Re: Anacron/Cron
-BEGIN PGP SIGNED MESSAGE- On Mon, 14 Jul 1997, Robert D. Hilliard wrote: Now that anacron is taking over the daily, weekly and monthly cron jobs, can I safely remove cron, or is it required for other system functions? I wouldn't particuarly recomend removing cron. Most of the time it is sitting blocked and gets paged out anyway. smail uses cron to run its mail que. And it is useful for running tasks every x/minutes or whatever. - -- |The mark of your ignorance is the depth of Scott K. Ellis| your belief in injustice and tragedy. [EMAIL PROTECTED]| What the caterpillar calls the end of the world, | the master calls a butterfly. | -- Illusions -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBM8rD+KCk2fENdzpVAQGNkQP/QTqyOzAEx7uEivuTTNBoSe2e1ny3FonY 1lUhFXQbNQpAeVz5hu7N5ryBLAKS7w1PzrnAuhvJ7mEvQKnBo+HIndDxSaifPz2u g3i/qp7goS7MxuPZwh6Tpu0C1atKBS3/CI4pfTzrgi7r3x4iutoz0q1egNKOKU1l Hac1d74wVoQ= =KuMy -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Anacron/Cron
I have finally installed anacron. Since my machine doesn't run 24 hours a day, no cron scripts have ever run, so my log files are getting out of hand. The package description for anacron says It's also a good replacement for cron on systems, that don't run continuously 24 hours a day but are powered on and shut down several times a day. Now that anacron is taking over the daily, weekly and monthly cron jobs, can I safely remove cron, or is it required for other system functions? Bob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
