Re: crontab and /usr/local/{,s}bin
Todd C. Miller wrote: > The default root crontab on OpenBSD sets a more limited PATH: > > PATH=/bin:/sbin:/usr/bin:/usr/sbin > > Perhaps that is what you are talking about? We might want to > consider removing PATH from root's crontab and just use the value > from login.conf. The reason it is done this way is that root often installs packages into /usr/local for regular users of the system, but may not consider that there are impacts upon cron jobs. Like many behaviours in OpenBSD, the safe decision is the default, and Tuning this is left as an easy task for the administrator.
Re: crontab and /usr/local/{,s}bin
The default root crontab on OpenBSD sets a more limited PATH: PATH=/bin:/sbin:/usr/bin:/usr/sbin Perhaps that is what you are talking about? We might want to consider removing PATH from root's crontab and just use the value from login.conf. - todd
Re: crontab and /usr/local/{,s}bin
On Tue, 14 Feb 2023 23:45:29 +0100, "Thomas L." wrote:
> what is the reason that /usr/local/{,s}bin is not in PATH in crontab?
> this seems to be the case on all unix-like systems and it regularly
> bites people. sometimes someone says it's for security w/o being
> able to tell what is being prevented by this. or is it just some
> historic default noone bothered to change?
On OpenBSD, the path setting in the /etc/login.conf file determines
what the default PATH will be used for commands run via cron. By
default this is:
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbi
n
If you have PATH set in the crontab file that will override the
default.
- todd
crontab and /usr/local/{,s}bin
hi,
what is the reason that /usr/local/{,s}bin is not in PATH in crontab?
this seems to be the case on all unix-like systems and it regularly
bites people. sometimes someone says it's for security w/o being
able to tell what is being prevented by this. or is it just some
historic default noone bothered to change?
kind regards,
thomas
Re: Is CRONTAB(5) random really random ?
On Fri, Jan 06, 2023 at 12:58:48AM +0100, Rachel Roch wrote: > > > > 5 Jan 2023, 18:24 by purushar...@gmx.com: > > > Namaste Rachel, Theo(s), > > > >> Sent: Thursday, January 05, 2023 at 5:50 PM > >> From: "Theo de Raadt" > >> To: "Theo Buehler" > >> Cc: "Rachel Roch" , "Misc" > >> Subject: Re: Is CRONTAB(5) random really random ? > >> > >> Theo Buehler wrote: > >> > >> > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > >> > > According to the docs : > >> > > > >> > > > A random value (within the legal range) may be obtained by using > >> > > > the ???~??? character in a field. > >> > > >> > The random numbers are drawn once and then repeated regularly. This > >> > behavior has always bothered me but never enough to spend the time > >> > needed to fix it (it's not immediately obvious how to do it). A > >> > workaround is to use a > >> > > >> > sleep $((RANDOM \% 512)) && run_whatever > >> > > >> > construct. The number to the right of the modulo should be a power of 2 > >> > to avoid modulo bias. > >> > >> Any solution would need to be careful, so that a operation doesn't run > >> multiple times in an hour. Each column should be '0 + random % range', > >> but multiple columns contain ~, it gets weird. > >> > > > > The following thread may be helpful: > > > > "Regarding randomized times in crontab" > > https://marc.info/?l=openbsd-misc&m=158705405304672&w=2 > > > > Dhanyavaad, > > Dharma Artha Kama Moksha > > > > Thank you all for your insightful input, looks like the $RANDOM prefix idea > is the only quick-fix to this. > > I didn't realise the random value was only set once. Maybe someone should > update the man page accordingly ? > To be clear, it is "once per ~ occurrence in the crontab", not once for all ~ or once per crontab line. -Otto
Re: Is CRONTAB(5) random really random ?
5 Jan 2023, 18:24 by purushar...@gmx.com: > Namaste Rachel, Theo(s), > >> Sent: Thursday, January 05, 2023 at 5:50 PM >> From: "Theo de Raadt" >> To: "Theo Buehler" >> Cc: "Rachel Roch" , "Misc" >> Subject: Re: Is CRONTAB(5) random really random ? >> >> Theo Buehler wrote: >> >> > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: >> > > According to the docs : >> > > >> > > > A random value (within the legal range) may be obtained by using >> > > > the ‘~’ character in a field. >> > >> > The random numbers are drawn once and then repeated regularly. This >> > behavior has always bothered me but never enough to spend the time >> > needed to fix it (it's not immediately obvious how to do it). A >> > workaround is to use a >> > >> >sleep $((RANDOM \% 512)) && run_whatever >> > >> > construct. The number to the right of the modulo should be a power of 2 >> > to avoid modulo bias. >> >> Any solution would need to be careful, so that a operation doesn't run >> multiple times in an hour. Each column should be '0 + random % range', >> but multiple columns contain ~, it gets weird. >> > > The following thread may be helpful: > > "Regarding randomized times in crontab" > https://marc.info/?l=openbsd-misc&m=158705405304672&w=2 > > Dhanyavaad, > Dharma Artha Kama Moksha > Thank you all for your insightful input, looks like the $RANDOM prefix idea is the only quick-fix to this. I didn't realise the random value was only set once. Maybe someone should update the man page accordingly ?
Re: Is CRONTAB(5) random really random ?
Namaste Rachel, Theo(s), > Sent: Thursday, January 05, 2023 at 5:50 PM > From: "Theo de Raadt" > To: "Theo Buehler" > Cc: "Rachel Roch" , "Misc" > Subject: Re: Is CRONTAB(5) random really random ? > > Theo Buehler wrote: > > > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > > > According to the docs : > > > > > > > A random value (within the legal range) may be obtained by usingthe > > > > ‘~’ character in a field. > > > > The random numbers are drawn once and then repeated regularly. This > > behavior has always bothered me but never enough to spend the time > > needed to fix it (it's not immediately obvious how to do it). A > > workaround is to use a > > > > sleep $((RANDOM \% 512)) && run_whatever > > > > construct. The number to the right of the modulo should be a power of 2 > > to avoid modulo bias. > > Any solution would need to be careful, so that a operation doesn't run > multiple times in an hour. Each column should be '0 + random % range', > but multiple columns contain ~, it gets weird. > > The following thread may be helpful: "Regarding randomized times in crontab" https://marc.info/?l=openbsd-misc&m=158705405304672&w=2 Dhanyavaad, Dharma Artha Kama Moksha
Re: Is CRONTAB(5) random really random ?
Theo Buehler wrote: > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > > According to the docs : > > > > > A random value (within the legal range) may be obtained by usingthe > > > ‘~’ character in a field. > > The random numbers are drawn once and then repeated regularly. This > behavior has always bothered me but never enough to spend the time > needed to fix it (it's not immediately obvious how to do it). A > workaround is to use a > > sleep $((RANDOM \% 512)) && run_whatever > > construct. The number to the right of the modulo should be a power of 2 > to avoid modulo bias. Any solution would need to be careful, so that a operation doesn't run multiple times in an hour. Each column should be '0 + random % range', but multiple columns contain ~, it gets weird.
Re: Is CRONTAB(5) random really random ?
On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > According to the docs : > > > A random value (within the legal range) may be obtained by usingthe ‘~’ > > character in a field. The random numbers are drawn once and then repeated regularly. This behavior has always bothered me but never enough to spend the time needed to fix it (it's not immediately obvious how to do it). A workaround is to use a sleep $((RANDOM \% 512)) && run_whatever construct. The number to the right of the modulo should be a power of 2 to avoid modulo bias.
Re: [SPAM?] Is CRONTAB(5) random really random ?
Am Do., 5. Jan. 2023 um 18:16 Uhr schrieb Rachel Roch : > Especially given three of my crontab fields are supposed to be random > (minute, hour, day-of-month) I would expect to see at least one of the three > to be different ?!? AFAIK there is only one random value and it's created at startup of the daemon. Best Martin
Is CRONTAB(5) random really random ?
According to the docs : > A random value (within the legal range) may be obtained by usingthe ‘~’ > character in a field. However I've been running release versions of OpenBSD with the following definition: ~ ~ ~ * * /my/task/goes/here && /usr/bin/logger -t foo "Task done" Feb 18 18:09:01 foobar foo: Task done Mar 18 18:09:01 foobar foo: Task doneMar 24 23:42:01 foobar foo: Task doneApr 20 11:41:01 foobar foo: Task doneMay 16 18:24:01 foobar foo: Task doneJun 6 17:24:01 foobar foo: Task doneJul 6 17:24:01 foobar foo: Task doneAug 6 17:24:01 foobar foo: Task doneSep 6 17:24:01 foobar foo: Task doneOct 6 17:24:01 foobar foo: Task doneOct 31 08:44:01 foobar foo: Task doneNov 19 12:02:01 foobar foo: Task doneDec 19 12:02:02 foobar foo: Task done Surely it would be clutching at straws to describe an event happening at exactly the same time 5 months in a row (Jun–Oct) as genuinely statistically random ? The same with Nov & Dec. Especially given three of my crontab fields are supposed to be random (minute, hour, day-of-month) I would expect to see at least one of the three to be different ?!?
at(1) and cron(8) (was: Re: Regarding randomized times in crontab)
Just as a note for the future: mefeels that it'd be great (for clarity as well as simplicity) if cron(8) would be merged into at(1) at some point: % echo make-coffee | at teatime every day (Or similar.) Such a change would allow each job to be individually manipulated, as well. --zeurkous. P.S.: No patch for UNIX, at least from me: you folks'll have to do w/ me advice :) -- Friggin' Machines!
Re: Regarding randomized times in crontab
On Sat, Apr 18, 2020 at 10:56:09AM -0600, Theo de Raadt wrote: > Raul Miller wrote: > > > On Sat, Apr 18, 2020 at 12:25 PM Aham Brahmasmi > > wrote: > > > The examples and Theo's reply helped in understanding the nuance. It > > > might seem logical and common sense on further thought, as Janne has > > > pointed out. But at least in my case, it was not immediately apparent. > > > > Yeah, after rethinking it, I had goofed in my reading. > > > > I guess it's nothing that a simple experiment wouldn't have shown up. > > > > That said, it wouldn't have been difficult to also calculate the first > > minute of each new ~ delimited interval and (re-)randomize it at that > > point in time. (The system already calculates the min and max for each > > ~ instance.) > > OK, so one time it chooses 59, and then it re-randomizes as 1, but the job > takes >2 minutes. > > Awesome I would honestly say that would be a user error tho. You have the same issue in -stable today with jobs possibly overlapping due to less than careful scheduling. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Regarding randomized times in crontab
Raul Miller wrote: > On Sat, Apr 18, 2020 at 12:25 PM Aham Brahmasmi > wrote: > > The examples and Theo's reply helped in understanding the nuance. It > > might seem logical and common sense on further thought, as Janne has > > pointed out. But at least in my case, it was not immediately apparent. > > Yeah, after rethinking it, I had goofed in my reading. > > I guess it's nothing that a simple experiment wouldn't have shown up. > > That said, it wouldn't have been difficult to also calculate the first > minute of each new ~ delimited interval and (re-)randomize it at that > point in time. (The system already calculates the min and max for each > ~ instance.) OK, so one time it chooses 59, and then it re-randomizes as 1, but the job takes >2 minutes. Awesome
Re: Regarding randomized times in crontab
On Sat, Apr 18, 2020 at 12:25 PM Aham Brahmasmi wrote: > The examples and Theo's reply helped in understanding the nuance. It > might seem logical and common sense on further thought, as Janne has > pointed out. But at least in my case, it was not immediately apparent. Yeah, after rethinking it, I had goofed in my reading. I guess it's nothing that a simple experiment wouldn't have shown up. That said, it wouldn't have been difficult to also calculate the first minute of each new ~ delimited interval and (re-)randomize it at that point in time. (The system already calculates the min and max for each ~ instance.) Thanks, -- Raul
Re: Regarding randomized times in crontab
Namaste Andreas, > Sent: Friday, April 17, 2020 at 8:53 AM > From: "Andreas Kusalananda Kähäri" > To: "Janne Johansson" > Cc: "openbsd-misc" > Subject: Re: Regarding randomized times in crontab > > On Fri, Apr 17, 2020 at 09:06:10AM +0200, Janne Johansson wrote: > > Den tors 16 apr. 2020 kl 20:22 skrev Andreas Kusalananda Kähäri < > > andreas.kah...@abc.se>: > > > > > On Thu, Apr 16, 2020 at 11:14:59AM -0600, Theo de Raadt wrote: > > > > That is a lot of words to cover a simple concept: > > > > > > > > The specific random values are selected when cron(5) loads > > > > the crontab file. New numbers are chosen when crontab -e is used. > > > > If you understand that, the conclusions are obvious. > > > > > > Ah. Good. Then I know the restrictions. The random times are random, > > > but fixed for the lifetime of the cron daemon (or until the crontab is > > > reloaded due to being edited). > > > > > > > It would be very weird otherwise, if the 24h random example was used, then > > it chose 00:01, > > ran your "bin/true" command and then re-randomized, it would most certainly > > end up wanting > > to run again, perhaps twice or more. So if it re-randomized after each > > execution > > it would have to keep a 24h timer going (in your example, a per-week, a > > per-month timer also) > > to make sure the newly randomized 11:12 time is actually tomorrows 11:12 > > and not the upcoming > > one in this day. Also, re-randomization would also mean it could start your > > one hour backup at 23:59 > > and once more in 00:01 the next day, which would cause lots of unexpected > > chaos for anyone expecting > > a daily one-hour job to not collide with itself. > > Well, not weird but unexpected if you didn't think about it when you > picked the randomized time intervals. The issue with overlapping jobs > could be sorted out fairly easily with manual locking, or with the -s > crontab(5) feature that I saw a patch for on the tech list recently. > > I suppose there is no technical issue with actually re-randomizing the > picking of the time whenever a job is about to enter the time frame of > when the if would possibly start (not directly after each execution, > obviously). That would have the same effect as delaying the job with > sleep and $RANDOM. Tusen tack for asking this question. After seeing your mail, I looked at the manpage and incorrectly inferred the "~" as a replacement of the sleep and RANDOM combination. The examples and Theo's reply helped in understanding the nuance. It might seem logical and common sense on further thought, as Janne has pointed out. But at least in my case, it was not immediately apparent. > > -- > > May the most significant bit of your life be positive. > > :-) > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . Dhanyavaad, ab -|-|-|-|-|-|-|--
Re: Regarding randomized times in crontab
On Fri, Apr 17, 2020 at 09:06:10AM +0200, Janne Johansson wrote: > Den tors 16 apr. 2020 kl 20:22 skrev Andreas Kusalananda Kähäri < > andreas.kah...@abc.se>: > > > On Thu, Apr 16, 2020 at 11:14:59AM -0600, Theo de Raadt wrote: > > > That is a lot of words to cover a simple concept: > > > > > > The specific random values are selected when cron(5) loads > > > the crontab file. New numbers are chosen when crontab -e is used. > > > If you understand that, the conclusions are obvious. > > > > Ah. Good. Then I know the restrictions. The random times are random, > > but fixed for the lifetime of the cron daemon (or until the crontab is > > reloaded due to being edited). > > > > It would be very weird otherwise, if the 24h random example was used, then > it chose 00:01, > ran your "bin/true" command and then re-randomized, it would most certainly > end up wanting > to run again, perhaps twice or more. So if it re-randomized after each > execution > it would have to keep a 24h timer going (in your example, a per-week, a > per-month timer also) > to make sure the newly randomized 11:12 time is actually tomorrows 11:12 > and not the upcoming > one in this day. Also, re-randomization would also mean it could start your > one hour backup at 23:59 > and once more in 00:01 the next day, which would cause lots of unexpected > chaos for anyone expecting > a daily one-hour job to not collide with itself. Well, not weird but unexpected if you didn't think about it when you picked the randomized time intervals. The issue with overlapping jobs could be sorted out fairly easily with manual locking, or with the -s crontab(5) feature that I saw a patch for on the tech list recently. I suppose there is no technical issue with actually re-randomizing the picking of the time whenever a job is about to enter the time frame of when the if would possibly start (not directly after each execution, obviously). That would have the same effect as delaying the job with sleep and $RANDOM. > > -- > May the most significant bit of your life be positive. :-) -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Regarding randomized times in crontab
Den tors 16 apr. 2020 kl 20:22 skrev Andreas Kusalananda Kähäri < andreas.kah...@abc.se>: > On Thu, Apr 16, 2020 at 11:14:59AM -0600, Theo de Raadt wrote: > > That is a lot of words to cover a simple concept: > > > > The specific random values are selected when cron(5) loads > > the crontab file. New numbers are chosen when crontab -e is used. > > If you understand that, the conclusions are obvious. > > Ah. Good. Then I know the restrictions. The random times are random, > but fixed for the lifetime of the cron daemon (or until the crontab is > reloaded due to being edited). > It would be very weird otherwise, if the 24h random example was used, then it chose 00:01, ran your "bin/true" command and then re-randomized, it would most certainly end up wanting to run again, perhaps twice or more. So if it re-randomized after each execution it would have to keep a 24h timer going (in your example, a per-week, a per-month timer also) to make sure the newly randomized 11:12 time is actually tomorrows 11:12 and not the upcoming one in this day. Also, re-randomization would also mean it could start your one hour backup at 23:59 and once more in 00:01 the next day, which would cause lots of unexpected chaos for anyone expecting a daily one-hour job to not collide with itself. -- May the most significant bit of your life be positive.
Re: Regarding randomized times in crontab
On Thu, Apr 16, 2020 at 11:14:59AM -0600, Theo de Raadt wrote: > That is a lot of words to cover a simple concept: > > The specific random values are selected when cron(5) loads > the crontab file. New numbers are chosen when crontab -e is used. > > If you understand that, the conclusions are obvious. Ah. Good. Then I know the restrictions. The random times are random, but fixed for the lifetime of the cron daemon (or until the crontab is reloaded due to being edited). And for Raul, yes I'm aware that randomly picked value can be the same as the last randomly picked value, but for most types of house keeping tasks, the quality of "random" is less interesting. You are however correct in that my question wasn't totally coherent, but at least Theo got my drift. Cheers, > > > Raul Miller wrote: > > > That's a poorly phrased question, to be honest. > > > > In one sense the point in time where the job is scheduled has to be > > different -- it's a point in time in a different 24 hour period. > > > > But in another sense (a sense closer to what you probably intended) > > the point in time can't be guaranteed to be different. There's a > > finite number of minutes in a day and picking one pseudo-randomly > > would occasionally collide. Consider, as an extreme example, a system > > which reboots often and is only up for 1 minute every 24 hour period. > > > > But, such collisions should be rare, and that specific extreme case > > example was ludicrous. > > > > Anyways, on a normally operating machine, you should expect the same > > minute to be used slightly more often than once every four years. And, > > a difference less than 2 minutes would happen more often (around once > > a year, depending on exactly where you draw the line). > > > > But, if you don't trust what I have said here (and maybe you should > > not) what you really want to understand is the algorithm being used, > > and the best way to discover that is to look at the implementation. > > https://www.openbsd.org/anoncvs.html -- Specifically, you'll want to > > look at the implementation of get_range() in usr.sbin/cron/entry.c > > > > FYI, > > > > > > -- > > Raul > > > > On Thu, Apr 16, 2020 at 12:41 PM Andreas Kusalananda Kähäri > > wrote: > > > > > > Thanks for that! > > > > > > Also, considering a job scheduled like > > > > > > ~ ~ * * * somecommand > > > > > > I'm assuming, provided that the cron daemon is not restarted, this would > > > run the job at a single random point in each 24h period, right? A > > > *different* point in time, each 24 period? > > > > > > > > > > > > On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > > > > Yes. > > > > > > > > But that problem already existed with the minutes field being >close to > > > > the moment cron was restarted. > > > > > > > > Only difference is now you don't know the minute. > > > > > > > > > > > > Andreas Kusalananda Kähäri wrote: > > > > > > > > > Thanks for the ~ crontab(5) feature! > > > > > > > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > > > > interval during which a cron job may be randomly triggered, is there a > > > > > risk (or even guarantee) that the job may run a second time? > > > > > > > > > > > > > > > Regards, > > > > > > > > > > -- > > > > > Andreas (Kusalananda) Kähäri > > > > > SciLifeLab, NBIS, ICM > > > > > Uppsala University, Sweden > > > > > > > > > > . > > > > > > > > > > > -- > > > Andreas (Kusalananda) Kähäri > > > SciLifeLab, NBIS, ICM > > > Uppsala University, Sweden > > > > > > . > > > > > -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Regarding randomized times in crontab
That is a lot of words to cover a simple concept: The specific random values are selected when cron(5) loads the crontab file. New numbers are chosen when crontab -e is used. If you understand that, the conclusions are obvious. Raul Miller wrote: > That's a poorly phrased question, to be honest. > > In one sense the point in time where the job is scheduled has to be > different -- it's a point in time in a different 24 hour period. > > But in another sense (a sense closer to what you probably intended) > the point in time can't be guaranteed to be different. There's a > finite number of minutes in a day and picking one pseudo-randomly > would occasionally collide. Consider, as an extreme example, a system > which reboots often and is only up for 1 minute every 24 hour period. > > But, such collisions should be rare, and that specific extreme case > example was ludicrous. > > Anyways, on a normally operating machine, you should expect the same > minute to be used slightly more often than once every four years. And, > a difference less than 2 minutes would happen more often (around once > a year, depending on exactly where you draw the line). > > But, if you don't trust what I have said here (and maybe you should > not) what you really want to understand is the algorithm being used, > and the best way to discover that is to look at the implementation. > https://www.openbsd.org/anoncvs.html -- Specifically, you'll want to > look at the implementation of get_range() in usr.sbin/cron/entry.c > > FYI, > > > -- > Raul > > On Thu, Apr 16, 2020 at 12:41 PM Andreas Kusalananda Kähäri > wrote: > > > > Thanks for that! > > > > Also, considering a job scheduled like > > > > ~ ~ * * * somecommand > > > > I'm assuming, provided that the cron daemon is not restarted, this would > > run the job at a single random point in each 24h period, right? A > > *different* point in time, each 24 period? > > > > > > > > On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > > > Yes. > > > > > > But that problem already existed with the minutes field being >close to > > > the moment cron was restarted. > > > > > > Only difference is now you don't know the minute. > > > > > > > > > Andreas Kusalananda Kähäri wrote: > > > > > > > Thanks for the ~ crontab(5) feature! > > > > > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > > > interval during which a cron job may be randomly triggered, is there a > > > > risk (or even guarantee) that the job may run a second time? > > > > > > > > > > > > Regards, > > > > > > > > -- > > > > Andreas (Kusalananda) Kähäri > > > > SciLifeLab, NBIS, ICM > > > > Uppsala University, Sweden > > > > > > > > . > > > > > > > > -- > > Andreas (Kusalananda) Kähäri > > SciLifeLab, NBIS, ICM > > Uppsala University, Sweden > > > > . > > >
Re: Regarding randomized times in crontab
That's a poorly phrased question, to be honest. In one sense the point in time where the job is scheduled has to be different -- it's a point in time in a different 24 hour period. But in another sense (a sense closer to what you probably intended) the point in time can't be guaranteed to be different. There's a finite number of minutes in a day and picking one pseudo-randomly would occasionally collide. Consider, as an extreme example, a system which reboots often and is only up for 1 minute every 24 hour period. But, such collisions should be rare, and that specific extreme case example was ludicrous. Anyways, on a normally operating machine, you should expect the same minute to be used slightly more often than once every four years. And, a difference less than 2 minutes would happen more often (around once a year, depending on exactly where you draw the line). But, if you don't trust what I have said here (and maybe you should not) what you really want to understand is the algorithm being used, and the best way to discover that is to look at the implementation. https://www.openbsd.org/anoncvs.html -- Specifically, you'll want to look at the implementation of get_range() in usr.sbin/cron/entry.c FYI, -- Raul On Thu, Apr 16, 2020 at 12:41 PM Andreas Kusalananda Kähäri wrote: > > Thanks for that! > > Also, considering a job scheduled like > > ~ ~ * * * somecommand > > I'm assuming, provided that the cron daemon is not restarted, this would > run the job at a single random point in each 24h period, right? A > *different* point in time, each 24 period? > > > > On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > > Yes. > > > > But that problem already existed with the minutes field being >close to > > the moment cron was restarted. > > > > Only difference is now you don't know the minute. > > > > > > Andreas Kusalananda Kähäri wrote: > > > > > Thanks for the ~ crontab(5) feature! > > > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > > interval during which a cron job may be randomly triggered, is there a > > > risk (or even guarantee) that the job may run a second time? > > > > > > > > > Regards, > > > > > > -- > > > Andreas (Kusalananda) Kähäri > > > SciLifeLab, NBIS, ICM > > > Uppsala University, Sweden > > > > > > . > > > > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . >
Re: Regarding randomized times in crontab
Thanks for that! Also, considering a job scheduled like ~ ~ * * * somecommand I'm assuming, provided that the cron daemon is not restarted, this would run the job at a single random point in each 24h period, right? A *different* point in time, each 24 period? On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > Yes. > > But that problem already existed with the minutes field being >close to > the moment cron was restarted. > > Only difference is now you don't know the minute. > > > Andreas Kusalananda Kähäri wrote: > > > Thanks for the ~ crontab(5) feature! > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > interval during which a cron job may be randomly triggered, is there a > > risk (or even guarantee) that the job may run a second time? > > > > > > Regards, > > > > -- > > Andreas (Kusalananda) Kähäri > > SciLifeLab, NBIS, ICM > > Uppsala University, Sweden > > > > . > > -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Regarding randomized times in crontab
Yes. But that problem already existed with the minutes field being >close to the moment cron was restarted. Only difference is now you don't know the minute. Andreas Kusalananda Kähäri wrote: > Thanks for the ~ crontab(5) feature! > > Question: If the cron daemon is restarted (e.g. via reboot) during the > interval during which a cron job may be randomly triggered, is there a > risk (or even guarantee) that the job may run a second time? > > > Regards, > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . >
Regarding randomized times in crontab
Thanks for the ~ crontab(5) feature! Question: If the cron daemon is restarted (e.g. via reboot) during the interval during which a cron job may be randomly triggered, is there a risk (or even guarantee) that the job may run a second time? Regards, -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Cron not executing @reboot command in crontab
> At the top of the file you'll see:
>
> PATH=/bin:/sbin:/usr/bin:/usr/sbin
>
> Either {pre,ap}pend /usr/local/{,s}bin or use the full command path.
>
> Regards,
>
> Raf
>
> Use a full path. cran has a very limited default PATH.
>
> -Otto
Thank you both, it works perfectly now!
Best,
Unicorn
Re: Cron not executing @reboot command in crontab
On Sun, Nov 17, 2019 at 11:57:44AM GMT, Unicorn wrote:
> Hello,
>
> I apologize if this is trivial, I genuinely read through all the cron-
> related manpages and tried several things, but this is my issue:
>
> I want to use 'autossh' to automatically establish reverse port
> forwarding on boot, so (as root) I can 'crontab -e' and added this line
> to the bottom:
>
> @reboot autossh [all my options]
>
> After adding the line, running 'crontab -l' shows that the line was
> correctly added; I have also confirmed that the 'autossh ...' part
> works perfectly when I just execute it in a terminal. When I reboot the
> system though, nothing happens.
>
> Even if I restart cron with rcctl, nothing happens. I even confirmed
> that sshd is started before cron in rc, I have tried everything I could
> come up with, I just have no clue what I'm missing.
>
> Since I am new to OpenBSD, I would appreciate your advice or any clues
> on what I have done wrong. Regarding system setup, this is a completely
> bare system, I have just run 'sysupgrade -s' and installed autossh.
>
> Thank you in advance!
>
At the top of the file you'll see:
PATH=/bin:/sbin:/usr/bin:/usr/sbin
Either {pre,ap}pend /usr/local/{,s}bin or use the full command path.
Regards,
Raf
Re: Cron not executing @reboot command in crontab
On Sun, Nov 17, 2019 at 12:57:44PM +0100, Unicorn wrote: > Hello, > > I apologize if this is trivial, I genuinely read through all the cron- > related manpages and tried several things, but this is my issue: > > I want to use 'autossh' to automatically establish reverse port > forwarding on boot, so (as root) I can 'crontab -e' and added this line > to the bottom: > > @reboot autossh [all my options] > > After adding the line, running 'crontab -l' shows that the line was > correctly added; I have also confirmed that the 'autossh ...' part > works perfectly when I just execute it in a terminal. When I reboot the > system though, nothing happens. > > Even if I restart cron with rcctl, nothing happens. I even confirmed > that sshd is started before cron in rc, I have tried everything I could > come up with, I just have no clue what I'm missing. > > Since I am new to OpenBSD, I would appreciate your advice or any clues > on what I have done wrong. Regarding system setup, this is a completely > bare system, I have just run 'sysupgrade -s' and installed autossh. > > Thank you in advance! > Use a full path. cran has a very limited default PATH. -Otto
Cron not executing @reboot command in crontab
Hello, I apologize if this is trivial, I genuinely read through all the cron- related manpages and tried several things, but this is my issue: I want to use 'autossh' to automatically establish reverse port forwarding on boot, so (as root) I can 'crontab -e' and added this line to the bottom: @reboot autossh [all my options] After adding the line, running 'crontab -l' shows that the line was correctly added; I have also confirmed that the 'autossh ...' part works perfectly when I just execute it in a terminal. When I reboot the system though, nothing happens. Even if I restart cron with rcctl, nothing happens. I even confirmed that sshd is started before cron in rc, I have tried everything I could come up with, I just have no clue what I'm missing. Since I am new to OpenBSD, I would appreciate your advice or any clues on what I have done wrong. Regarding system setup, this is a completely bare system, I have just run 'sysupgrade -s' and installed autossh. Thank you in advance!
Re: problems running an LUA script from crontab
On Tue, 28 May 2019 15:14:58 -0500 Carlos Aguilar wrote: > I am having lots of problems to execute a shell script at boot time. What problems Carlos?? Does the script work properly when you are logged in? Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: crontab
On Tue, May 28, 2019 at 05:43:03PM -0400, System Administrator wrote: > On 28 May 2019 at 15:14, Carlos Aguilar wrote: > > > Hi, > > > > I am having lots of problems to execute a shell script at boot time. > > > > My crontab is as follows; > > >> > > SHELL=/bin/ksh > > > > @reboot $HOME/bin/app-ferre > > << > > My shell script is as follows: > > >> > > #!/bin/ksh > > > > lua=/usr/local/bin/lua53 > > > > for f in $(ls /home/alberto/app/service-*.lua) ;do > > echo 'Initializing' $f '\n' > > $lua $f & > > done > > >> > > > > Thanks for any help or advice, > > > > // Carlos > > > > Hi Carlos, > > The $HOME environment variable is defined by the interactive shell for > login sessions. Moreover, unless you regularly log into your system as > root -- which is the user that kicks off cron tasks and runs them > unless changed with su or doas -- it does not point where you are > expecting (*your* home folder). > > When specifying crontab entries, it is best to spell out the program > path. > > -Jacob. Assuming that this is being run from the correct users' crontab, $HOME would be set correctly. Cron sets $HOME. There is too much information missing from the original post that it makes it difficult to debug (any mentioning of what the actual issue is, for example). -- Kusalananda Sweden
Re: crontab
On 28 May 2019 at 15:14, Carlos Aguilar wrote: > Hi, > > I am having lots of problems to execute a shell script at boot time. > > My crontab is as follows; > >> > SHELL=/bin/ksh > > @reboot $HOME/bin/app-ferre > << > My shell script is as follows: > >> > #!/bin/ksh > > lua=/usr/local/bin/lua53 > > for f in $(ls /home/alberto/app/service-*.lua) ;do > echo 'Initializing' $f '\n' > $lua $f & > done > >> > > Thanks for any help or advice, > > // Carlos > Hi Carlos, The $HOME environment variable is defined by the interactive shell for login sessions. Moreover, unless you regularly log into your system as root -- which is the user that kicks off cron tasks and runs them unless changed with su or doas -- it does not point where you are expecting (*your* home folder). When specifying crontab entries, it is best to spell out the program path. -Jacob.
Re: crontab
On Tue, May 28, 2019 at 03:14:58PM -0500, Carlos Aguilar wrote: > Hi, > > I am having lots of problems to execute a shell script at boot time. > > My crontab is as follows; > >> > SHELL=/bin/ksh > > @reboot $HOME/bin/app-ferre > << > My shell script is as follows: > >> > #!/bin/ksh > > lua=/usr/local/bin/lua53 > > for f in $(ls /home/alberto/app/service-*.lua) ;do > echo 'Initializing' $f '\n' > $lua $f & > done > >> > > Thanks for any help or advice, > > // Carlos I'm noticing that you don't actually mention what the problem is, or what your Lua scripts do. Do you get an error message? BTW, note that it's safer to use #!/bin/ksh PATH=$PATH:/usr/local/bin for f in /home/alberto/app/service-*.lua; do printf '%s\n' "$f" lua53 "$f" & done -- Kusalananda Sweden
Re: crontab
On May 28, 2019 3:14 PM, Carlos Aguilar wrote: > > Hi, > > I am having lots of problems to execute a shell script at boot time. > > My crontab is as follows; > >> > SHELL=/bin/ksh > > @reboot $HOME/bin/app-ferre > << > My shell script is as follows: > >> > #!/bin/ksh > > lua=/usr/local/bin/lua53 > > for f in $(ls /home/alberto/app/service-*.lua) ;do > echo 'Initializing' $f '\n' > $lua $f & > done > >> > > Thanks for any help or advice, > > // Carlos Have you tried using rc.local? May be easier.
crontab
Hi, I am having lots of problems to execute a shell script at boot time. My crontab is as follows; >> SHELL=/bin/ksh @reboot $HOME/bin/app-ferre << My shell script is as follows: >> #!/bin/ksh lua=/usr/local/bin/lua53 for f in $(ls /home/alberto/app/service-*.lua) ;do echo 'Initializing' $f '\n' $lua $f & done >> Thanks for any help or advice, // Carlos
Re: dump/restore and crontab(5)
On Mon, 2 Jul 2018 09:25:37 -0400 "trondd" wrote: > On Mon, July 2, 2018 8:14 am, Ed Ahlsen-Girard wrote: > [...] > > I'd have to look later to see if my dumps are coreectly grabbing the > crontabs. But first, try looking in /var/backups either on disk, or > in your dump. > > Tim. > In the backups. Thanks. -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: dump/restore and crontab(5)
On Mon, July 2, 2018 10:26 am, Ed Ahlsen-Girard wrote: > On Mon, 2 Jul 2018 09:25:37 -0400 > "trondd" wrote: > >> On Mon, July 2, 2018 8:14 am, Ed Ahlsen-Girard wrote: >> [...] >> >> I'd have to look later to see if my dumps are coreectly grabbing the >> crontabs. But first, try looking in /var/backups either on disk, or >> in your dump. >> >> Tim. >> > > In the backups. Thanks. > > -- > > Edward Ahlsen-Girard > Ft Walton Beach, FL > FYI. dump/restore is correctly saving and restoring my /var/cron/tabs/* so double check your dump and restore scripts, parameters, whatever. Tim.
Re: dump/restore and crontab(5)
trondd writes: > On Mon, July 2, 2018 8:14 am, Ed Ahlsen-Girard wrote: >> Having clobbered my crontab (5) file in error (-r and -e are close) I >> merrily went to my level 0 dump to restore it. It's present on the dump >> (which is to file) but the restored file is zero bytes. >> >> Should I have run those dumps manually instead of as cron jobs? >> >> -- >> >> Edward Ahlsen-Girard >> Ft Walton Beach, FL >> > > I'd have to look later to see if my dumps are coreectly grabbing the > crontabs. But first, try looking in /var/backups either on disk, or in > your dump. > > Tim. Indeed, you can find your last file in /var/backups/var_cron_tabs_root.backup or /var/backups/var_cron_tabs_root.current Those files are created by security(8) script, which should be run every day at 1h30.
Re: dump/restore and crontab(5)
On Mon, July 2, 2018 8:14 am, Ed Ahlsen-Girard wrote: > Having clobbered my crontab (5) file in error (-r and -e are close) I > merrily went to my level 0 dump to restore it. It's present on the dump > (which is to file) but the restored file is zero bytes. > > Should I have run those dumps manually instead of as cron jobs? > > -- > > Edward Ahlsen-Girard > Ft Walton Beach, FL > I'd have to look later to see if my dumps are coreectly grabbing the crontabs. But first, try looking in /var/backups either on disk, or in your dump. Tim.
Re: dump/restore and crontab(5)
Ed Ahlsen-Girard writes: > Having clobbered my crontab (5) file in error (-r and -e are close) I > merrily went to my level 0 dump to restore it. It's present on the dump > (which is to file) but the restored file is zero bytes. > > Should I have run those dumps manually instead of as cron jobs? What arguments did you use to backup with dump? What arguments did you use to restore with restore? If you found the file using restore, then it should not be zero-length.
dump/restore and crontab(5)
Having clobbered my crontab (5) file in error (-r and -e are close) I merrily went to my level 0 dump to restore it. It's present on the dump (which is to file) but the restored file is zero bytes. Should I have run those dumps manually instead of as cron jobs? -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
* Sélène [2014-04-11 12:25]: > Le 2014-04-09 00:48, czark...@gmail.com a écrit : > >Remy said: > >>here is a simple patch to replace /etc/crontab by /etc/cron.d/. > > > >FWIW why? > > I find it far easier to have multiples crontab files in /etc/cron.d/ i find /dev/var/local/etc.d/$hostname/etc/cron.d/modern/* easier. and now? -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
On Fri, Apr 11, 2014 at 12:05, Sélène wrote: > Le 2014-04-09 00:48, czark...@gmail.com a écrit : >> Remy said: >>> here is a simple patch to replace /etc/crontab by /etc/cron.d/. >> >> FWIW why? > > I find it far easier to have multiples crontab files in /etc/cron.d/ > than keeping a single crontab. > > At works, we are heavily using crontabs, and when we update our own apps > on the servers, I need to check the changes needed for the app in the > crontab. With a /etc/cron.d/my_app_1 file, I would just replace it with > the new one, or I can even let the developers update their cron file, > but I won't let them mess the global crontab (root or user). cat /etc/cron.d/* >> /etc/crontab
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
Le 2014-04-11 14:21, Tomas Bodzar a écrit : On Fri, Apr 11, 2014 at 12:05 PM, Sélène wrote: Le 2014-04-09 00:48, czark...@gmail.com a écrit : Remy said: here is a simple patch to replace /etc/crontab by /etc/cron.d/. FWIW why? I find it far easier to have multiples crontab files in /etc/cron.d/ than keeping a single crontab. At works, we are heavily using crontabs, and when we update our own apps on the servers, I need to check the changes needed for the app in the crontab. With a /etc/cron.d/my_app_1 file, I would just replace it with the new one, or I can even let the developers update their cron file, but I won't let them mess the global crontab (root or user). Of course, I can manage the crontab by hand because I don't modify it very often, but I find the cron.d easier. And why not to use CFEngine, Puppet and similar for that? I am using SALT Stack now, it changed my admin life :)
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
On Fri, Apr 11, 2014 at 12:05 PM, Sélène wrote: > Le 2014-04-09 00:48, czark...@gmail.com a écrit : > > Remy said: >> >>> here is a simple patch to replace /etc/crontab by /etc/cron.d/. >>> >> >> FWIW why? >> > > I find it far easier to have multiples crontab files in /etc/cron.d/ than > keeping a single crontab. > > At works, we are heavily using crontabs, and when we update our own apps > on the servers, I need to check the changes needed for the app in the > crontab. With a /etc/cron.d/my_app_1 file, I would just replace it with the > new one, or I can even let the developers update their cron file, but I > won't let them mess the global crontab (root or user). > > Of course, I can manage the crontab by hand because I don't modify it very > often, but I find the cron.d easier. > And why not to use CFEngine, Puppet and similar for that?
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
Le 2014-04-09 00:48, czark...@gmail.com a écrit : Remy said: here is a simple patch to replace /etc/crontab by /etc/cron.d/. FWIW why? I find it far easier to have multiples crontab files in /etc/cron.d/ than keeping a single crontab. At works, we are heavily using crontabs, and when we update our own apps on the servers, I need to check the changes needed for the app in the crontab. With a /etc/cron.d/my_app_1 file, I would just replace it with the new one, or I can even let the developers update their cron file, but I won't let them mess the global crontab (root or user). Of course, I can manage the crontab by hand because I don't modify it very often, but I find the cron.d easier.
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
wasn't the "registry database" a dead giveaway???
On 8 Apr 2014 at 17:22, Dag Richards wrote:
> all sarcasm on my part.
> hate the whole /etc/hourly /etc/daily /etc/whim-time cron crap
>
> was happy to see Theo's reaction. Was jerking the list's chain.
>
>
> sven falempin wrote:
> > Look what linux are accepting now : stuff like systemd, how modern ! and so
> > nicely done !
> >
> > Maybe having a .d looks .damned cool but does it really solve something ?
> >
> > New is not better, modern surely isn't.
> >
> > If there is a way for OpenBSD to move to a cron.d it probably needs a nice
> > explanation :
> > - problems to be solved
> > - why is it the best way to solved it
> > - what other solution has been discarded and why.
> > - (and does the gain of the change worth the work of the change)
> >
> > PS:
> > If you install a software that require recurrent task it should be done
> > with a user with specific priviledge , so set up a crontab for this user.
> >
> >
> > Geez don't you have a TLS server to patch !
> >
> > On Tue, Apr 8, 2014 at 4:59 PM, Dag Richards
> > wrote:
> >
> >> No Theo I don't think understand, if you accept the patch then you will be
> >> more like Ubuntu and other MODERN operating systems.
> >>
> >> Why put everything in a single easily readable file, when you can split it
> >> up in to multiple directories.
> >>
> >> Which reminds me when are you going to ditch /etc for a nice registry data
> >> base.
> >>
> >>
> >>
> >>
> >> Theo de Raadt wrote:
> >>
> >>> In your dreams.
> >>>
> >>>
> >>> here is a simple patch to replace /etc/crontab by /etc/cron.d/.
> >>>> You need to manually mkdir /etc/cron.d.
> >>>>
> >>>>
> >>>> --- pathnames_original.hMon Apr 7 22:31:53 2014
> >>>> +++ pathnames.h Tue Apr 8 16:12:30 2014
> >>>> @@ -92,8 +92,8 @@
> >>>> #define PIDFILE"cron.pid"
> >>>> #define _PATH_CRON_PID PIDDIR PIDFILE
> >>>>
> >>>> - /* 4.3BSD-style crontab */
> >>>> -#define SYSCRONTAB "/etc/crontab"
> >>>> + /* system crontab dir */
> >>>> +#define SYSCRON_DIR"/etc/cron.d"
> >>>>
> >>>> /* what editor to use if no EDITOR or VISUAL
> >>>> * environment variable specified.
> >>>> @@ -42,30 +42,31 @@
> >>>>
> >>>> Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
> >>>>
> >>>> - /* before we start loading any data, do a stat on SPOOL_DIR
> >>>> -* so that if anything changes as of this moment (i.e., before
> >>>> we've
> >>>> -* cached any of the database), we'll see the changes next time.
> >>>> + /* before we start loading any data, do a stat on SPOOL_DIR and
> >>>> +* SYSCRON_DIR so that if anything changes as of this moment
> >>>> +* (i.e., before we've cached any of the database), we'll see
> >>>> +* the changes next time.
> >>>> */
> >>>> if (stat(SPOOL_DIR, &statbuf) < OK) {
> >>>> log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
> >>>> return;
> >>>> }
> >>>>
> >>>> - /* track system crontab file
> >>>> -*/
> >>>> - if (stat(SYSCRONTAB, &syscron_stat) < OK)
> >>>> - syscron_stat.st_mtime = 0;
> >>>> + if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
> >>>> + log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
> >>>> + return;
> >>>> + }
> >>>>
> >>>> - /* if spooldir's mtime has not changed, we don't need to fiddle
> >>>> with
> >>>> -* the database.
> >>>> + /* if spooldir's and syscrondir's mtime has not changed, we don't
> >>>> +* need to fiddle with the database.
> >&
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
all sarcasm on my part.
hate the whole /etc/hourly /etc/daily /etc/whim-time cron crap
was happy to see Theo's reaction. Was jerking the list's chain.
sven falempin wrote:
Look what linux are accepting now : stuff like systemd, how modern ! and so
nicely done !
Maybe having a .d looks .damned cool but does it really solve something ?
New is not better, modern surely isn't.
If there is a way for OpenBSD to move to a cron.d it probably needs a nice
explanation :
- problems to be solved
- why is it the best way to solved it
- what other solution has been discarded and why.
- (and does the gain of the change worth the work of the change)
PS:
If you install a software that require recurrent task it should be done
with a user with specific priviledge , so set up a crontab for this user.
Geez don't you have a TLS server to patch !
On Tue, Apr 8, 2014 at 4:59 PM, Dag Richards wrote:
No Theo I don't think understand, if you accept the patch then you will be
more like Ubuntu and other MODERN operating systems.
Why put everything in a single easily readable file, when you can split it
up in to multiple directories.
Which reminds me when are you going to ditch /etc for a nice registry data
base.
Theo de Raadt wrote:
In your dreams.
here is a simple patch to replace /etc/crontab by /etc/cron.d/.
You need to manually mkdir /etc/cron.d.
--- pathnames_original.hMon Apr 7 22:31:53 2014
+++ pathnames.h Tue Apr 8 16:12:30 2014
@@ -92,8 +92,8 @@
#define PIDFILE"cron.pid"
#define _PATH_CRON_PID PIDDIR PIDFILE
- /* 4.3BSD-style crontab */
-#define SYSCRONTAB "/etc/crontab"
+ /* system crontab dir */
+#define SYSCRON_DIR"/etc/cron.d"
/* what editor to use if no EDITOR or VISUAL
* environment variable specified.
@@ -42,30 +42,31 @@
Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
- /* before we start loading any data, do a stat on SPOOL_DIR
-* so that if anything changes as of this moment (i.e., before
we've
-* cached any of the database), we'll see the changes next time.
+ /* before we start loading any data, do a stat on SPOOL_DIR and
+* SYSCRON_DIR so that if anything changes as of this moment
+* (i.e., before we've cached any of the database), we'll see
+* the changes next time.
*/
if (stat(SPOOL_DIR, &statbuf) < OK) {
log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
return;
}
- /* track system crontab file
-*/
- if (stat(SYSCRONTAB, &syscron_stat) < OK)
- syscron_stat.st_mtime = 0;
+ if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
+ log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
+ return;
+ }
- /* if spooldir's mtime has not changed, we don't need to fiddle
with
-* the database.
+ /* if spooldir's and syscrondir's mtime has not changed, we don't
+* need to fiddle with the database.
*
* Note that old_db->mtime is initialized to 0 in main(), and
* so is guaranteed to be different than the stat() mtime the
first
* time this function is called.
*/
if (old_db->mtime == HASH(statbuf.st_mtime,
syscron_stat.st_mtime)) {
- Debug(DLOAD, ("[%ld] spool dir mtime unch, no load
needed.\n",
- (long)getpid()))
+ Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load
needed.\n",
+ (long)getpid()))
return;
}
@@ -77,28 +78,45 @@
new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
new_db.head = new_db.tail = NULL;
- if (syscron_stat.st_mtime) {
- process_crontab(ROOT_USER, NULL, SYSCRONTAB,
&syscron_stat,
- &new_db, old_db);
- }
-
/* we used to keep this dir open all the time, for the sake of
* efficiency. however, we need to close it in every fork, and
* we fork a lot more often than the mtime of the dir changes.
*/
- if (!(dir = opendir(SPOOL_DIR))) {
- log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+ if (!(dir = opendir(SYSCRON_DIR))) {
+ log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
return;
}
- while (NULL != (dp = readdir(dir))) {
- char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+ char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+ while (NULL != (dp = readdir(dir))) {
/* avoid file
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
Look what linux are accepting now : stuff like systemd, how modern ! and so
nicely done !
Maybe having a .d looks .damned cool but does it really solve something ?
New is not better, modern surely isn't.
If there is a way for OpenBSD to move to a cron.d it probably needs a nice
explanation :
- problems to be solved
- why is it the best way to solved it
- what other solution has been discarded and why.
- (and does the gain of the change worth the work of the change)
PS:
If you install a software that require recurrent task it should be done
with a user with specific priviledge , so set up a crontab for this user.
Geez don't you have a TLS server to patch !
On Tue, Apr 8, 2014 at 4:59 PM, Dag Richards wrote:
> No Theo I don't think understand, if you accept the patch then you will be
> more like Ubuntu and other MODERN operating systems.
>
> Why put everything in a single easily readable file, when you can split it
> up in to multiple directories.
>
> Which reminds me when are you going to ditch /etc for a nice registry data
> base.
>
>
>
>
> Theo de Raadt wrote:
>
>> In your dreams.
>>
>>
>> here is a simple patch to replace /etc/crontab by /etc/cron.d/.
>>> You need to manually mkdir /etc/cron.d.
>>>
>>>
>>> --- pathnames_original.hMon Apr 7 22:31:53 2014
>>> +++ pathnames.h Tue Apr 8 16:12:30 2014
>>> @@ -92,8 +92,8 @@
>>> #define PIDFILE"cron.pid"
>>> #define _PATH_CRON_PID PIDDIR PIDFILE
>>>
>>> - /* 4.3BSD-style crontab */
>>> -#define SYSCRONTAB "/etc/crontab"
>>> + /* system crontab dir */
>>> +#define SYSCRON_DIR"/etc/cron.d"
>>>
>>> /* what editor to use if no EDITOR or VISUAL
>>> * environment variable specified.
>>> @@ -42,30 +42,31 @@
>>>
>>> Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
>>>
>>> - /* before we start loading any data, do a stat on SPOOL_DIR
>>> -* so that if anything changes as of this moment (i.e., before
>>> we've
>>> -* cached any of the database), we'll see the changes next time.
>>> + /* before we start loading any data, do a stat on SPOOL_DIR and
>>> +* SYSCRON_DIR so that if anything changes as of this moment
>>> +* (i.e., before we've cached any of the database), we'll see
>>> +* the changes next time.
>>> */
>>> if (stat(SPOOL_DIR, &statbuf) < OK) {
>>> log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
>>> return;
>>> }
>>>
>>> - /* track system crontab file
>>> -*/
>>> - if (stat(SYSCRONTAB, &syscron_stat) < OK)
>>> - syscron_stat.st_mtime = 0;
>>> + if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
>>> + log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
>>> + return;
>>> + }
>>>
>>> - /* if spooldir's mtime has not changed, we don't need to fiddle
>>> with
>>> -* the database.
>>> + /* if spooldir's and syscrondir's mtime has not changed, we don't
>>> +* need to fiddle with the database.
>>> *
>>> * Note that old_db->mtime is initialized to 0 in main(), and
>>> * so is guaranteed to be different than the stat() mtime the
>>> first
>>> * time this function is called.
>>> */
>>> if (old_db->mtime == HASH(statbuf.st_mtime,
>>> syscron_stat.st_mtime)) {
>>> - Debug(DLOAD, ("[%ld] spool dir mtime unch, no load
>>> needed.\n",
>>> - (long)getpid()))
>>> + Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load
>>> needed.\n",
>>> + (long)getpid()))
>>> return;
>>> }
>>>
>>> @@ -77,28 +78,45 @@
>>> new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
>>> new_db.head = new_db.tail = NULL;
>>>
>>> - if (syscron_stat.st_mtime) {
>>> - process_crontab(ROOT_USER, NULL, SYSCRONTAB,
>>> &syscron_stat,
>>>
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
Remy said: > here is a simple patch to replace /etc/crontab by /etc/cron.d/. FWIW why? -- Dmitrij D. Czarkoff
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
On 04/08/14 16:35, Remy wrote: > Hi guys, > > here is a simple patch to replace /etc/crontab by /etc/cron.d/. > You need to manually mkdir /etc/cron.d. > um. eight days late. I look forward to your contribution next year, but try to hit the right date next time. Nick.
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
No Theo I don't think understand, if you accept the patch then you will
be more like Ubuntu and other MODERN operating systems.
Why put everything in a single easily readable file, when you can split
it up in to multiple directories.
Which reminds me when are you going to ditch /etc for a nice registry
data base.
Theo de Raadt wrote:
In your dreams.
here is a simple patch to replace /etc/crontab by /etc/cron.d/.
You need to manually mkdir /etc/cron.d.
--- pathnames_original.hMon Apr 7 22:31:53 2014
+++ pathnames.h Tue Apr 8 16:12:30 2014
@@ -92,8 +92,8 @@
#define PIDFILE"cron.pid"
#define _PATH_CRON_PID PIDDIR PIDFILE
- /* 4.3BSD-style crontab */
-#define SYSCRONTAB "/etc/crontab"
+ /* system crontab dir */
+#define SYSCRON_DIR"/etc/cron.d"
/* what editor to use if no EDITOR or VISUAL
* environment variable specified.
@@ -42,30 +42,31 @@
Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
- /* before we start loading any data, do a stat on SPOOL_DIR
-* so that if anything changes as of this moment (i.e., before
we've
-* cached any of the database), we'll see the changes next time.
+ /* before we start loading any data, do a stat on SPOOL_DIR and
+* SYSCRON_DIR so that if anything changes as of this moment
+* (i.e., before we've cached any of the database), we'll see
+* the changes next time.
*/
if (stat(SPOOL_DIR, &statbuf) < OK) {
log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
return;
}
- /* track system crontab file
-*/
- if (stat(SYSCRONTAB, &syscron_stat) < OK)
- syscron_stat.st_mtime = 0;
+ if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
+ log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
+ return;
+ }
- /* if spooldir's mtime has not changed, we don't need to fiddle
with
-* the database.
+ /* if spooldir's and syscrondir's mtime has not changed, we
don't
+* need to fiddle with the database.
*
* Note that old_db->mtime is initialized to 0 in main(), and
* so is guaranteed to be different than the stat() mtime the
first
* time this function is called.
*/
if (old_db->mtime == HASH(statbuf.st_mtime,
syscron_stat.st_mtime)) {
- Debug(DLOAD, ("[%ld] spool dir mtime unch, no load
needed.\n",
- (long)getpid()))
+ Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load
needed.\n",
+ (long)getpid()))
return;
}
@@ -77,28 +78,45 @@
new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
new_db.head = new_db.tail = NULL;
- if (syscron_stat.st_mtime) {
- process_crontab(ROOT_USER, NULL, SYSCRONTAB,
&syscron_stat,
- &new_db, old_db);
- }
-
/* we used to keep this dir open all the time, for the sake of
* efficiency. however, we need to close it in every fork, and
* we fork a lot more often than the mtime of the dir changes.
*/
- if (!(dir = opendir(SPOOL_DIR))) {
- log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+ if (!(dir = opendir(SYSCRON_DIR))) {
+ log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
return;
}
- while (NULL != (dp = readdir(dir))) {
- char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+ char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+ while (NULL != (dp = readdir(dir))) {
/* avoid file names beginning with ".". this is good
* because we would otherwise waste two guaranteed calls
* to getpwnam() for . and .., and also because user
names
* starting with a period are just too nasty to
consider.
*/
+ if (dp->d_name[0] == '.')
+ continue;
+
+ if (strlcpy(fname, dp->d_name, sizeof fname) >= sizeof
fname)
+ continue; /* XXX log? */
+
+ if (snprintf(tabname, sizeof tabname, "%s/%s",
SYSCRON_DIR,
+ fname) >= sizeof(tabname))
+ continue; /* XXX log? */
+
+ process_crontab(ROOT_USER, NULL, tabname, &syscron_stat,
+ &new_db, old_db);
+ }
+
+ closedir(dir);
+
+ if (!(dir =
Re: feature patch -> replace /etc/crontab by /etc/cron.d/
In your dreams.
> here is a simple patch to replace /etc/crontab by /etc/cron.d/.
> You need to manually mkdir /etc/cron.d.
>
>
> --- pathnames_original.hMon Apr 7 22:31:53 2014
> +++ pathnames.h Tue Apr 8 16:12:30 2014
> @@ -92,8 +92,8 @@
> #define PIDFILE"cron.pid"
> #define _PATH_CRON_PID PIDDIR PIDFILE
>
> - /* 4.3BSD-style crontab */
> -#define SYSCRONTAB "/etc/crontab"
> + /* system crontab dir */
> +#define SYSCRON_DIR"/etc/cron.d"
>
> /* what editor to use if no EDITOR or VISUAL
> * environment variable specified.
> @@ -42,30 +42,31 @@
>
> Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
>
> - /* before we start loading any data, do a stat on SPOOL_DIR
> -* so that if anything changes as of this moment (i.e., before
> we've
> -* cached any of the database), we'll see the changes next time.
> + /* before we start loading any data, do a stat on SPOOL_DIR and
> +* SYSCRON_DIR so that if anything changes as of this moment
> +* (i.e., before we've cached any of the database), we'll see
> +* the changes next time.
> */
> if (stat(SPOOL_DIR, &statbuf) < OK) {
> log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
> return;
> }
>
> - /* track system crontab file
> -*/
> - if (stat(SYSCRONTAB, &syscron_stat) < OK)
> - syscron_stat.st_mtime = 0;
> + if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
> + log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
> + return;
> + }
>
> - /* if spooldir's mtime has not changed, we don't need to fiddle
> with
> -* the database.
> + /* if spooldir's and syscrondir's mtime has not changed, we
> don't
> +* need to fiddle with the database.
> *
> * Note that old_db->mtime is initialized to 0 in main(), and
> * so is guaranteed to be different than the stat() mtime the
> first
> * time this function is called.
> */
> if (old_db->mtime == HASH(statbuf.st_mtime,
> syscron_stat.st_mtime)) {
> - Debug(DLOAD, ("[%ld] spool dir mtime unch, no load
> needed.\n",
> - (long)getpid()))
> + Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load
> needed.\n",
> + (long)getpid()))
> return;
> }
>
> @@ -77,28 +78,45 @@
> new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
> new_db.head = new_db.tail = NULL;
>
> - if (syscron_stat.st_mtime) {
> - process_crontab(ROOT_USER, NULL, SYSCRONTAB,
> &syscron_stat,
> - &new_db, old_db);
> - }
> -
> /* we used to keep this dir open all the time, for the sake of
> * efficiency. however, we need to close it in every fork, and
> * we fork a lot more often than the mtime of the dir changes.
> */
> - if (!(dir = opendir(SPOOL_DIR))) {
> - log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
> + if (!(dir = opendir(SYSCRON_DIR))) {
> + log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
> return;
> }
>
> - while (NULL != (dp = readdir(dir))) {
> - char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
> + char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
>
> + while (NULL != (dp = readdir(dir))) {
> /* avoid file names beginning with ".". this is good
> * because we would otherwise waste two guaranteed calls
> * to getpwnam() for . and .., and also because user
> names
> * starting with a period are just too nasty to
> consider.
> */
> + if (dp->d_name[0] == '.')
> + continue;
> +
> + if (strlcpy(fname, dp->d_name, sizeof fname) >= sizeof
> fname)
> + continue; /* XXX log? */
> +
> + if (snprintf(tabname, sizeof tabname, "%s/%s",
> SYSCRON_DIR,
> + fname) >= sizeof(tabname))
> + continue;
feature patch -> replace /etc/crontab by /etc/cron.d/
Hi guys,
here is a simple patch to replace /etc/crontab by /etc/cron.d/.
You need to manually mkdir /etc/cron.d.
--- pathnames_original.hMon Apr 7 22:31:53 2014
+++ pathnames.h Tue Apr 8 16:12:30 2014
@@ -92,8 +92,8 @@
#define PIDFILE"cron.pid"
#define _PATH_CRON_PID PIDDIR PIDFILE
- /* 4.3BSD-style crontab */
-#define SYSCRONTAB "/etc/crontab"
+ /* system crontab dir */
+#define SYSCRON_DIR"/etc/cron.d"
/* what editor to use if no EDITOR or VISUAL
* environment variable specified.
@@ -42,30 +42,31 @@
Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
- /* before we start loading any data, do a stat on SPOOL_DIR
-* so that if anything changes as of this moment (i.e., before
we've
-* cached any of the database), we'll see the changes next time.
+ /* before we start loading any data, do a stat on SPOOL_DIR and
+* SYSCRON_DIR so that if anything changes as of this moment
+* (i.e., before we've cached any of the database), we'll see
+* the changes next time.
*/
if (stat(SPOOL_DIR, &statbuf) < OK) {
log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
return;
}
- /* track system crontab file
-*/
- if (stat(SYSCRONTAB, &syscron_stat) < OK)
- syscron_stat.st_mtime = 0;
+ if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
+ log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
+ return;
+ }
- /* if spooldir's mtime has not changed, we don't need to fiddle
with
-* the database.
+ /* if spooldir's and syscrondir's mtime has not changed, we
don't
+* need to fiddle with the database.
*
* Note that old_db->mtime is initialized to 0 in main(), and
* so is guaranteed to be different than the stat() mtime the
first
* time this function is called.
*/
if (old_db->mtime == HASH(statbuf.st_mtime,
syscron_stat.st_mtime)) {
- Debug(DLOAD, ("[%ld] spool dir mtime unch, no load
needed.\n",
- (long)getpid()))
+ Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load
needed.\n",
+ (long)getpid()))
return;
}
@@ -77,28 +78,45 @@
new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
new_db.head = new_db.tail = NULL;
- if (syscron_stat.st_mtime) {
- process_crontab(ROOT_USER, NULL, SYSCRONTAB,
&syscron_stat,
- &new_db, old_db);
- }
-
/* we used to keep this dir open all the time, for the sake of
* efficiency. however, we need to close it in every fork, and
* we fork a lot more often than the mtime of the dir changes.
*/
- if (!(dir = opendir(SPOOL_DIR))) {
- log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+ if (!(dir = opendir(SYSCRON_DIR))) {
+ log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
return;
}
- while (NULL != (dp = readdir(dir))) {
- char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+ char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+ while (NULL != (dp = readdir(dir))) {
/* avoid file names beginning with ".". this is good
* because we would otherwise waste two guaranteed calls
* to getpwnam() for . and .., and also because user
names
* starting with a period are just too nasty to
consider.
*/
+ if (dp->d_name[0] == '.')
+ continue;
+
+ if (strlcpy(fname, dp->d_name, sizeof fname) >= sizeof
fname)
+ continue; /* XXX log? */
+
+ if (snprintf(tabname, sizeof tabname, "%s/%s",
SYSCRON_DIR,
+ fname) >= sizeof(tabname))
+ continue; /* XXX log? */
+
+ process_crontab(ROOT_USER, NULL, tabname, &syscron_stat,
+ &new_db, old_db);
+ }
+
+ closedir(dir);
+
+ if (!(dir = opendir(SPOOL_DIR))) {
+ log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+ return;
+ }
+
+ while (NULL != (dp = readdir(dir))) {
if (dp->d_name[0] == '.')
continue;
--- cron_original.8 Mon Apr 7 22:31:53 2014
+++ cron.8 Tue Apr 8 16:12:30 2014
@@ -71,9 +71,8
Re: crontab(1) confused by su(1)?
On Jul 26 08:42:52, fluca1...@infinito.it wrote: > On Wed, Jul 24, 2013 at 8:32 AM, Jan Stary wrote: > > >> Could someone please provide an example > >> where su(1) confuses crontab(1)? > > If I get it right the problem is not running crontab, rather modifying > the crontrab files. > In such case the following could be an example: I ask su(1) to become > another user without modifying the environment, therefore I'm another > user running in the same environment of the former (than there's a > privilege problem, of course). Crontab searches for the current uid > while I would like to see the old one. > > > % id > ~ > uid=1001(luca) gid=1001(luca) groups=1001(luca),0(wheel) > % su -m pgsql %id > % echo $USER > ~ > luca > % crontab -l > ~ > crontab: no crontab for pgsql You have su'd to pgsql, and crontab -l is showing you the (nonexistent) crontab of pgsql. That's intended. I was asking for an example of su being "confused" by su.
Re: crontab(1) confused by su(1)?
On Wed, Jul 24, 2013 at 8:32 AM, Jan Stary wrote:
>> Could someone please provide an example
>> where su(1) confuses crontab(1)?
If I get it right the problem is not running crontab, rather modifying
the crontrab files.
In such case the following could be an example: I ask su(1) to become
another user without modifying the environment, therefore I'm another
user running in the same environment of the former (than there's a
privilege problem, of course). Crontab searches for the current uid
while I would like to see the old one.
% id
~
uid=1001(luca) gid=1001(luca) groups=1001(luca),0(wheel)
% su -m pgsql
~
% echo $USER
~
luca
% crontab -l
~
crontab: no crontab for pgsql
However I could have totally missed the point...but it's an interesting one.
Luca
Re: crontab(1) confused by su(1)?
On Jul 16 13:23:01, h...@stare.cz wrote: > crontab(1) says > > -u user Specifies the name of the user whose crontab(5) is to be > edited. If this option is not given, crontab examines ``your'' > crontab(5); i.e., the crontab of the person executing the > command. Note that su(1) can confuse crontab and that if you > are running inside of su(1) you should always use the -u option > for safety's sake. > > Is this actually true? > For me, it has always done the expected thing, > i.e., run as the user su(1)'d to. Realy, > Could someone please provide an example > where su(1) confuses crontab(1)? > > Jan
crontab(1) confused by su(1)?
crontab(1) says
-u user Specifies the name of the user whose crontab(5) is to be
edited. If this option is not given, crontab examines ``your''
crontab(5); i.e., the crontab of the person executing the
command. Note that su(1) can confuse crontab and that if you
are running inside of su(1) you should always use the -u option
for safety's sake.
Is this actually true?
For me, it has always done the expected thing,
i.e., run as the user su(1)'d to.
Could someone please provide an example
where su(1) confuses crontab(1)?
Jan
Re: spamd-setup in crontab
I had the same problem. I found that changing the default timing fixed it. Thousands of OpenBSD default crons hitting openbsd.org at the same time. Le 14/11/2011 10:13, Manuel Giraud a C)crit : > Hi, > > I've just set up a mail server with 5.0. I have put spamd in front (in > default greylisting mode). It works great following the man pages but > when I activate the spamd-setup entry in root's crontab, I receive the > following error by mail: > > spamd-setup: ftp: Could not add blacklist uatrapsWriting -: : Illegal seek > Broken pipe > > If i call spamd-setup as root i have no error message. (note: I've used > the default /etc/mail/spamd.conf file). How can I sort this out?
Re: spamd-setup in crontab
On 2011-11-15, Raymond Lillard wrote: > I question the wisdom of identifying the source of > your trapping info. It outs ualberta.ca as a trap. This is fine as far as I'm concerned. If it means the smarter spammers avoid sending to ualberta.ca as a result, that is good for UofA.
Re: spamd-setup in crontab
On 2011-11-15 20.55, Raymond Lillard wrote: > On 11/14/2011 06:28 AM, James J. Lippard wrote: >> That is, my spamd.conf now looks like this: >> uatraps:\ >> :black:\ >> :msg="Your address %A has sent mail to a ualberta.ca spamtrap\n\ >> within the last 24 hours":\ >> :method=file:\ >> :file=/etc/mail/traplist.gz: > > I question the wisdom of identifying the source of > your trapping info. It outs ualberta.ca as a trap. No, it doesn't. It might out University of Alberta as an organization that fights spam but there is nothing that says that the *domain* ualberta.ca itself contains any of the spam trap addresses. > Spammers who actually read (I know most don't) reply > messages will know to black list ualberta. Those > with infected machines who somehow might get see the > message need only know their machine is compromised. Spammers usually never get to see those messages, as they operate through compromised mail servers or pc:s and most likely use fake From: addresses anyway. > Knowing who trapped their spam does not enable the > owner of the compromised machine to do any thing > they wouldn't do anyhow. The still need to clean > up their machine. They won't get the messages either... Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / "Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted." /email: benny -at- internetlabbet.se
Re: spamd-setup in crontab
On 11/14/2011 06:28 AM, James J. Lippard wrote: I had the same problem, which I worked around by changing my spamd.conf to use a local file instead of FTP, and downloading the traplist.gz file in my daily.local. That is, my spamd.conf now looks like this: uatraps:\ :black:\ :msg="Your address %A has sent mail to a ualberta.ca spamtrap\n\ within the last 24 hours":\ :method=file:\ :file=/etc/mail/traplist.gz: And my daily.local now has this: echo "Getting traplist.gz." /usr/bin/ftp -o /etc/mail/traplist.gz http://www.openbsd.org/spamd/traplist.gz I question the wisdom of identifying the source of your trapping info. It outs ualberta.ca as a trap. Spammers who actually read (I know most don't) reply messages will know to black list ualberta. Those with infected machines who somehow might get see the message need only know their machine is compromised. Knowing who trapped their spam does not enable the owner of the compromised machine to do any thing they wouldn't do anyhow. The still need to clean up their machine. Regards, Ray
Re: spamd-setup in crontab
Thanks for the tips but does anyone know where this problem come from ? Le 14/11/2011 10:13, Manuel Giraud a C)crit : Hi, I've just set up a mail server with 5.0. I have put spamd in front (in default greylisting mode). It works great following the man pages but when I activate the spamd-setup entry in root's crontab, I receive the following error by mail: spamd-setup: ftp: Could not add blacklist uatrapsWriting -: : Illegal seek Broken pipe If i call spamd-setup as root i have no error message. (note: I've used the default /etc/mail/spamd.conf file). How can I sort this out?
Re: spamd-setup in crontab
Op Mon, 14 Nov 2011 15:28:43 +0100 schreef "James J. Lippard"
:
I had the same problem, which I worked around by changing my
spamd.conf to use a local file instead of FTP, and downloading the
traplist.gz file in my daily.local.
That is, my spamd.conf now looks like this:
uatraps:\
:black:\
:msg="Your address %A has sent mail to a ualberta.ca spamtrap\n\
within the last 24 hours":\
:method=file:\
:file=/etc/mail/traplist.gz:
And my daily.local now has this:
echo "Getting traplist.gz."
/usr/bin/ftp -o /etc/mail/traplist.gz
http://www.openbsd.org/spamd/traplist.gz
I have a slightly more complicated setup which fetches traplist and
nixspam every two hours:
root's crontab:
# update spamd on :15 every two hours
15 */2 * * * /etc/mail/spamd-setup.sh
spamd-setup.sh:
#!/bin/sh
# sleep 0..15 minutes
/bin/sleep $(($RANDOM / 72))
/usr/local/bin/wget -o /dev/null -NxP /home/ftp/pub/mirrors -nv \
http://www.openbsd.org/spamd/{traplist,nixspam}.gz
/usr/libexec/spamd-setup
Also, china and korea are fetched in daily.local:
# http://www.openbsd.org/spamd/{china,korea}cidr.txt.gz are not mirrored
# regularly, so we use the original source
/usr/local/bin/wget -NxP /home/ftp/pub/mirrors -nv \
http://www.okean.com/{china,korea}cidr.txt
The advantage of using wget(1) (or curl(1) if you like) is that it will
only fetch the file if the timestamp has changed.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(Remove the obvious prefix to reply.)
Re: spamd-setup in crontab
I had the same problem, which I worked around by changing my spamd.conf to use a local file instead of FTP, and downloading the traplist.gz file in my daily.local. That is, my spamd.conf now looks like this: uatraps:\ :black:\ :msg="Your address %A has sent mail to a ualberta.ca spamtrap\n\ within the last 24 hours":\ :method=file:\ :file=/etc/mail/traplist.gz: And my daily.local now has this: echo "Getting traplist.gz." /usr/bin/ftp -o /etc/mail/traplist.gz http://www.openbsd.org/spamd/traplist.gz -- Jim Lippardlippard-open...@discord.org http://www.discord.org/ GPG Key ID: 0xF8D42CFE On Mon, Nov 14, 2011 at 11:43:13AM +0100, Com??te wrote: > Same error message since one week on an old 4.6 install. But i didn't > find the origin yet... > > Le 14/11/2011 10:13, Manuel Giraud a C)crit : > >Hi, > > > >I've just set up a mail server with 5.0. I have put spamd in front (in > >default greylisting mode). It works great following the man pages but > >when I activate the spamd-setup entry in root's crontab, I receive the > >following error by mail: > > > >spamd-setup: ftp: Could not add blacklist uatrapsWriting -: : Illegal seek > >Broken pipe > > > >If i call spamd-setup as root i have no error message. (note: I've used > >the default /etc/mail/spamd.conf file). How can I sort this out?
Re: spamd-setup in crontab
Same error message since one week on an old 4.6 install. But i didn't find the origin yet... Le 14/11/2011 10:13, Manuel Giraud a C)crit : Hi, I've just set up a mail server with 5.0. I have put spamd in front (in default greylisting mode). It works great following the man pages but when I activate the spamd-setup entry in root's crontab, I receive the following error by mail: spamd-setup: ftp: Could not add blacklist uatrapsWriting -: : Illegal seek Broken pipe If i call spamd-setup as root i have no error message. (note: I've used the default /etc/mail/spamd.conf file). How can I sort this out?
spamd-setup in crontab
Hi, I've just set up a mail server with 5.0. I have put spamd in front (in default greylisting mode). It works great following the man pages but when I activate the spamd-setup entry in root's crontab, I receive the following error by mail: spamd-setup: ftp: Could not add blacklist uatrapsWriting -: : Illegal seek Broken pipe If i call spamd-setup as root i have no error message. (note: I've used the default /etc/mail/spamd.conf file). How can I sort this out? -- Manuel Giraud
Re: crontab mail
On Tue, Feb 01, 2011 at 10:53:26AM +0100, Leslie Jensen wrote: > If I specify > MAILTO="email@my.domain" > > in roots crontab. > > I'll recieve mail when cron runs what I've asked it to. > > With > MAILTO="root" > > Mails are delivered to the local mailbox on the system > > > In /etc/postfix/aliases I have > root: email@my.domain > > I've executed newaliases at the command prompt. > > > Has anyone got an idea on why I can't get the mails to root to my > external mail address? > > Thanks > > /Leslie My guess is that you have configured things so that postfix isn't used for local delivery. But since you neglect to describe your setup, I cannot help further. -Otto
crontab mail
If I specify MAILTO="email@my.domain" in roots crontab. I'll recieve mail when cron runs what I've asked it to. With MAILTO="root" Mails are delivered to the local mailbox on the system In /etc/postfix/aliases I have root: email@my.domain I've executed newaliases at the command prompt. Has anyone got an idea on why I can't get the mails to root to my external mail address? Thanks /Leslie
Re: Executing from crontab only does the job when I logged on.
ok, thanks, I resolve the issue. "Orestes Leal R." , at 2010-12-27 16:40:12, substantially ignored: "So, read the logs, describe your setup more completely such as by ^ ^^ including a full dmesg." ^ ^ ^ My experience has been that when the developers ask for a dmesg and I send it, they tell me more than they were able to before I sent it. You seem to think that they are kidding when they tell you that they don't know enough about your setup to answer your question. They are not kidding. And if you will not include a full dmesg, you are wasting their time **and your time**. This is not the first time that you have failed to provide system details when asked. That is why I am being so explicit in my criticism. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Executing from crontab only does the job when I logged on.
"Orestes Leal R." , at 2010-12-27 16:40:12, substantially ignored: "So, read the logs, describe your setup more completely such as by ^ ^^ including a full dmesg." ^ ^ ^ My experience has been that when the developers ask for a dmesg and I send it, they tell me more than they were able to before I sent it. You seem to think that they are kidding when they tell you that they don't know enough about your setup to answer your question. They are not kidding. And if you will not include a full dmesg, you are wasting their time **and your time**. This is not the first time that you have failed to provide system details when asked. That is why I am being so explicit in my criticism. -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: Executing from crontab only does the job when I logged on.
On Mon, 27 Dec 2010 20:22:30 -0500 "Eric Furman" wrote: > On Mon, 27 Dec 2010 13:41 -0600, "Orestes Leal R." > wrote: > > On Mon, 27 Dec 2010 12:33:25 -0600, Martin Schrvder > > > > wrote: > > > > > 2010/12/27 Orestes Leal R. : > > >> the 2 programs work ok, but the do not execute from crontab when > > >> I logged > > >> out from console,ssh. > > >> but when I logged on into an ssh session or console session then > > >> execute. > > > > > > Programs started by cron will have a different env(1) than those > > > started from interactive sessions; most notabily $PATH will be > > > different. > > > > > > Best > > >Martin > > > > > > > Is there any restriction on accesing networks sockets from cron? > > No, this is not normal behavior for cron on ANY flavor of UNIX. > Sounds like a good guess, Martin, but no one can know because he > still refuses to give any of the info he was asked for. > Any real info at all, actually. Expecting any real info whatsoever on misc@ seems to be futile. A guess is as much as they can or want to expect. Perhaps it's some kind of recruitment scheme. (On the other hand, they might just have gone to bed.)
Re: Executing from crontab only does the job when I logged on.
On Mon, 27 Dec 2010 13:41 -0600, "Orestes Leal R." wrote: > On Mon, 27 Dec 2010 12:33:25 -0600, Martin Schrvder > wrote: > > > 2010/12/27 Orestes Leal R. : > >> the 2 programs work ok, but the do not execute from crontab when I > >> logged > >> out from console,ssh. > >> but when I logged on into an ssh session or console session then > >> execute. > > > > Programs started by cron will have a different env(1) than those > > started from interactive sessions; most notabily $PATH will be > > different. > > > > Best > >Martin > > > > Is there any restriction on accesing networks sockets from cron? No, this is not normal behavior for cron on ANY flavor of UNIX. Sounds like a good guess, Martin, but no one can know because he still refuses to give any of the info he was asked for. Any real info at all, actually.
Re: Executing from crontab only does the job when I logged on.
On Mon, Dec 27, 2010 at 01:41:07PM -0600, Orestes Leal R. wrote: > Martin Schrvder wrote: > >2010/12/27 Orestes Leal R. : > >>the 2 programs work ok, but the do not execute from crontab when I > >>logged > >>out from console,ssh. > >>but when I logged on into an ssh session or console session then > >>execute. > > > >Programs started by cron will have a different env(1) than those > >started from interactive sessions; most notabily $PATH will be > >different. > > Is there any restriction on accesing networks sockets from cron? There are no such restrictions that do not also restrict programs started from the shell by/as the same user. Joachim -- PotD: databases/pgfouine - PostgreSQL log analyzer http://www.joachimschipper.nl/
Re: Executing from crontab only does the job when I logged on.
On Mon, 27 Dec 2010 12:33:25 -0600, Martin Schrvder wrote: 2010/12/27 Orestes Leal R. : the 2 programs work ok, but the do not execute from crontab when I logged out from console,ssh. but when I logged on into an ssh session or console session then execute. Programs started by cron will have a different env(1) than those started from interactive sessions; most notabily $PATH will be different. Best Martin Is there any restriction on accesing networks sockets from cron?
Re: Executing from crontab only does the job when I logged on.
2010/12/27 Orestes Leal R. : > the 2 programs work ok, but the do not execute from crontab when I logged > out from console,ssh. > but when I logged on into an ssh session or console session then execute. Programs started by cron will have a different env(1) than those started from interactive sessions; most notabily $PATH will be different. Best Martin
Re: Executing from crontab only does the job when I logged on.
He said read cron logs, not man page... -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation. "Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted." -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
Re: Executing from crontab only does the job when I logged on.
no virtualization, i386, I already read the manpage of cron, didn't say anithing that apply to this situation. thanks anyway. On Mon, Dec 27, 2010 at 9:02 AM, Orestes Leal R. wrote: It happens to me in 4.8 too. ...and yet you seem to have ignored my suggestion to read the cron log. Surprise: the same suggestion applies to 4.8! So, read the logs, describe your setup more completely such as by including a full dmesg. Right now, we don't know what architecture this is, whether virtualization is involved, what user are these cronjobs set up as, how you confirmed that they are running when you're logged in, nor how you confirmed that they are *not* running when you are not logged in. Without details, I don't see any way to help you other than guessing, so here's my random guess: it's obviously a bug in your virtualization setup. (You didn't say it _isn't_ such a setup, so I could be right.) Philip Guenther -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Executing from crontab only does the job when I logged on.
On Mon, Dec 27, 2010 at 9:02 AM, Orestes Leal R. wrote: > It happens to me in 4.8 too. ...and yet you seem to have ignored my suggestion to read the cron log. Surprise: the same suggestion applies to 4.8! So, read the logs, describe your setup more completely such as by including a full dmesg. Right now, we don't know what architecture this is, whether virtualization is involved, what user are these cronjobs set up as, how you confirmed that they are running when you're logged in, nor how you confirmed that they are *not* running when you are not logged in. Without details, I don't see any way to help you other than guessing, so here's my random guess: it's obviously a bug in your virtualization setup. (You didn't say it _isn't_ such a setup, so I could be right.) Philip Guenther
Re: Executing from crontab only does the job when I logged on.
It happens to me in 4.8 too. On Mon, Dec 27, 2010 at 7:35 AM, Orestes Leal R. wrote: Hi folks, I have setup a 2 crontabs jobs, one it's a compiled C program that checks if the pop3 server responds, if so it's die, if not it restart the pop3 server. and the other it's the same but for smtp server. the 2 programs work ok, but the do not execute from crontab when I logged out from console,ssh. but when I logged on into an ssh session or console session then execute. it this behavior right? I'm using 4.3 4.3 has been out of support for almost 20 months. You've apparently chosen to continue using it instead of upgrading, so supporting it is your problem. Good luck! I suggest you check the log file for cron (read the cron(8) manpage for details). Philip Guenther -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Executing from crontab only does the job when I logged on.
On Mon, Dec 27, 2010 at 7:35 AM, Orestes Leal R. wrote: > Hi folks, I have setup a 2 crontabs jobs, > > one it's a compiled C program that checks if the pop3 server responds, if so > it's die, > if not it restart the pop3 server. > > and the other it's the same but for smtp server. > > the 2 programs work ok, but the do not execute from crontab when I logged > out from console,ssh. > but when I logged on into an ssh session or console session then execute. > > it this behavior right? > > I'm using 4.3 4.3 has been out of support for almost 20 months. You've apparently chosen to continue using it instead of upgrading, so supporting it is your problem. Good luck! I suggest you check the log file for cron (read the cron(8) manpage for details). Philip Guenther
Executing from crontab only does the job when I logged on.
Hi folks, I have setup a 2 crontabs jobs, one it's a compiled C program that checks if the pop3 server responds, if so it's die, if not it restart the pop3 server. and the other it's the same but for smtp server. the 2 programs work ok, but the do not execute from crontab when I logged out from console,ssh. but when I logged on into an ssh session or console session then execute. it this behavior right? I'm using 4.3 LeaL
Re: set nano as deafult when editing crontab
On 2010/12/23 4:48 PM, Orestes Leal R. wrote: I want to edit the crontab with nano but by default vi it's invoked when I do 'crontab -e' Did you read crontab(1)?
Re: set nano as deafult when editing crontab
woww MG is new for me, thanks. On 12/23/10 15:48, Orestes Leal R. wrote: I want to edit the crontab with nano but by default vi it's invoked when I do 'crontab -e' What is wrong with mg? -luis -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: set nano as deafult when editing crontab
On Thu, 23 Dec 2010 15:01:13 -0600, Martin Schrvder wrote: 2010/12/23 Orestes Leal R. : I want to edit the crontab with nano but by default vi it's invoked when I do 'crontab -e' man crontab -eEdit the current crontab using the editor specified by the VISUAL or EDITOR environment variables. :-) No Thank you!, by far OpenBSD it's best suited for my tasks than the 'bloated linux' debian. openbsd it's very small in his base system, I like that, I have a system running 4.3 acting for mail, pop3 server with only 1.0GB of disk space. Are you sure you don't want to use debian instead? :-) Best Martin
Re: set nano as deafult when editing crontab
On 12/23/10 15:48, Orestes Leal R. wrote: I want to edit the crontab with nano but by default vi it's invoked when I do 'crontab -e' What is wrong with mg? -luis
Re: set nano as deafult when editing crontab
Orestes Leal R. skrev 2010-12-23 22:48: I want to edit the crontab with nano but by default vi it's invoked when I do 'crontab -e' export VISUAL="nano -w"
Re: set nano as deafult when editing crontab
2010/12/23 Orestes Leal R. : > I want to edit the crontab with nano but by default vi it's invoked > when I do 'crontab -e' man crontab -eEdit the current crontab using the editor specified by the VISUAL or EDITOR environment variables. Are you sure you don't want to use debian instead? :-) Best Martin
Re: set nano as deafult when editing crontab
On Thu, Dec 23, 2010 at 03:48:49PM -0600, Orestes Leal R. wrote: :I want to edit the crontab with nano but by default vi it's invoked :when I do 'crontab -e' : -eEdit the current crontab using the editor specified by the VISUAL or EDITOR environment variables. After you exit from the editor, the modified crontab(5) will be installed automatically. env EDITOR=nano crontab -e
set nano as deafult when editing crontab
I want to edit the crontab with nano but by default vi it's invoked when I do 'crontab -e'
Re: crontab "last day of the month"
Artur Grabowski wrote: > On Tue, Apr 6, 2010 at 12:29 PM, Alexander Hall wrote: >> frantisek holop wrote: >>> hmm, on Tue, Apr 06, 2010 at 11:26:28AM +0200, Jan Stary said that On Apr 06 11:15:26, frantisek holop wrote: > hi there, > > what happens if i specify a cronjob like this? > > 23 59 31 * * $HOME/bin/whatever Cron will just do what it's told: run whatever at "31.*. 23:59" >>> so i could basically do 12 lines with the correct >>> last day of the month rules :] >>> >> No, you're forgetting about leap years... :-) > > Don't forget leap seconds. Heh, I did not care about them since cron's granularity is limited to minutes... Hmmm... I wonder if they could potentially cause any grieve...
Re: crontab "last day of the month"
On Tue, Apr 6, 2010 at 12:29 PM, Alexander Hall wrote: > frantisek holop wrote: >> hmm, on Tue, Apr 06, 2010 at 11:26:28AM +0200, Jan Stary said that >>> On Apr 06 11:15:26, frantisek holop wrote: hi there, what happens if i specify a cronjob like this? 23 59 31 * * $HOME/bin/whatever >>> Cron will just do what it's told: run whatever at "31.*. 23:59" >> >> so i could basically do 12 lines with the correct >> last day of the month rules :] >> > > No, you're forgetting about leap years... :-) Don't forget leap seconds. //art
Re: crontab "last day of the month"
On Wed, 7 Apr 2010, Jan Stary wrote: I told I'm using visitors. Which apparently cannot do it (or what exactly is your problem?). Try webalizer, it doesn't depend on log files being particularly named and/or sorted, juts reads the individual records, remembers previous periods, what was already processed, etc. I don't want webalizer. Visitor parses the contents just fine but the naming of the resulted files is the problem. I stated in the initial mail that I want to generate stats based on the rotated files just *once*. When a month goes by the logfile with the same name doesn't contain the same contents that it did one month ago. It looks like nobody has an answer for this, so I'll leave it be. -- Antti Harri
Re: crontab "last day of the month"
On Tue, 6 Apr 2010, Antti Harri wrote: OK. How do I reliably get month and year out of the file? awk will work for that and for massaging archived logs. That's also the kind of task perl is best at. Another option is to reconfigure the log file format. The regular Apache format LogFormat "%h %l %u %t \"%r\" %>s %b" common can be replaced with something much, much easier to parse. For example: LogFormat "%h\t%l\t%u\t%t\t\"%r\"\t%>s\t%b" common Because connections or transactions take a while to complete, tidying up will be necessary regardless of when the logs get rotated. /Lars
Re: crontab "last day of the month"
On Apr 06 23:52:31, Antti Harri wrote: > On Tue, 6 Apr 2010, Jan Stary wrote: > >> No it's not. Unless you have some heavy traffic just around the midnight >> that is the border between months, the above newsyslog line makes >> the just-rotated access_log.0.gz contains the log of the >> month-that-just-ended. > > OK. How do I reliably get month and year out of the file? You already know that. If it's April 2010 now, then access_log.0.gz contains the logs of March 2010. (Beware the logs of March!) If you want to get the date _out_of_the_file_ (why would you, you already know that), it's in each and every line of the access_log: 158.108.213.20 - - [07/Apr/2010:08:01:48 +0200] "GET /hoeg/ HTTP/1.0" 200 3771 > Month I can get from the newsyslog output it puts in the logs, > getting year without doing some sort of nasty kludge is hard. > > m=$(zfgrep "logfile turned over" "$file" | tail -n 1 | cut -b 1-3) This is the month (which you already know anyway). The year is not even present in the "turned over" messages. But again, it is present in each and every of the log records. >>> I'm using www/visitors to produce something meaningful from those >>> logs, and I would like to generate stats just once for a certain >>> time period so I can later see stats further than one year that newsyslog >>> keeps. >> >> webalizer > > I told I'm using visitors. Which apparently cannot do it (or what exactly is your problem?). Try webalizer, it doesn't depend on log files being particularly named and/or sorted, juts reads the individual records, remembers previous periods, what was already processed, etc.
Re: crontab "last day of the month"
On 2010-04-06, frantisek holop wrote: > hmm, on Tue, Apr 06, 2010 at 03:01:17PM +0200, Bret S. Lambert said that >> I'm still not seeing what you're really getting, here; you're >> just pushing that spillover from one end to another, which >> are just as easily rationalized as "the casualties of log >> rotation." > > i get the correct name/number of the month... mv logfile logfile.$(date -r $(($(date +%s)-600)) +%Y-%m-%d)
Re: crontab "last day of the month"
hmm, on Tue, Apr 06, 2010 at 03:01:17PM +0200, Bret S. Lambert said that > I'm still not seeing what you're really getting, here; you're > just pushing that spillover from one end to another, which > are just as easily rationalized as "the casualties of log > rotation." i get the correct name/number of the month... > date +mm? $ date +mm mm $ date +mm? mm? -f -- incipit vita nova.
Re: crontab "last day of the month"
hmm, on Tue, Apr 06, 2010 at 09:51:29PM +0200, Paul de Weerd said that > So you think it's my problem ? I showed two possible options, both > very workable (and easily extensible to add something simple as a > year). Yet... > > ...you choose to complain about the options I provided. i am humbled by the fact that you took some time and tried to help me. i am not complaining, i merely dislike your solutions. i tapped into the mailing list's collective wisdom to see if someone has a solution my feeble mind would like. > or 3. use "recursive date(1) calls" (how, exactly, are those > recursive ? geometrically. > It isn't an issue - the solution has been presented to you. A few > lines up, I've spelled it out for you (one possible solution, that > is). You just choose to publicly dismiss it because you don't like it. > Why ? i dont like your solutions because they are hacks. it is nothing personal. i am off to self-reflect, sensei. -f -- one seventh of our lives is spent on mondays.
Re: crontab "last day of the month"
On Tue, 6 Apr 2010, Jan Stary wrote: No it's not. Unless you have some heavy traffic just around the midnight that is the border between months, the above newsyslog line makes the just-rotated access_log.0.gz contains the log of the month-that-just-ended. OK. How do I reliably get month and year out of the file? Month I can get from the newsyslog output it puts in the logs, getting year without doing some sort of nasty kludge is hard. m=$(zfgrep "logfile turned over" "$file" | tail -n 1 | cut -b 1-3) I'm using www/visitors to produce something meaningful from those logs, and I would like to generate stats just once for a certain time period so I can later see stats further than one year that newsyslog keeps. webalizer I told I'm using visitors. -- Antti Harri
Re: crontab "last day of the month"
Paul de Weerd wrote:
On Tue, Apr 06, 2010 at 04:18:22PM +0200, frantisek holop wrote:
| > Come on man .. 'can of worms' ?! It's not even a real challenge.
|
| you left off the year...
So you think it's my problem ? I showed two possible options, both
very workable (and easily extensible to add something simple as a
year). Yet...
| i'd rather not bloat my 3 line scripts with lookup tables
| and recursive date(1) calls, i prefer them easy and short.
...you choose to complain about the options I provided.
| here's the full picture of the current situation:
|
| on 1. april i get this file through monthly.local:
|
| logfile-2010-04.log.gz
|
| containing all _march_ entries (plus some april if it creeped in).
|
| i have 2 choices:
| 1. do the rename dance backwards one month
| 2. let the job actually run sometimes before midnight, last day of the month.
or 3. use "recursive date(1) calls" (how, exactly, are those
recursive ? you've got a weird definition of recursion)
gzip < ${LOG} > logfile-$(date -r $(($(date +%s) - 86400)) +%Y-%m).gz
There, I've put in the year for you, beacuse you couldn't think of
that yourself somehow. I don't really care much how you do it, but
that is not recursion nor very bloated, imo.
You come to this list to ask for something. It's not possible and you
are given alternative solutions. All you can do is complain about
them. Why ?
| regarding the "forward casualties" of log rotation, yes it's the same.
| while chronologically i still prefer the other way, i.e. have older
| entries in the newer log file (and not newer entries in older logfiles),
| but the main issue is, that i end up with the wrong file name.
It isn't an issue - the solution has been presented to you. A few
lines up, I've spelled it out for you (one possible solution, that
is). You just choose to publicly dismiss it because you don't like it.
Why ?
Paul 'WEiRD' de Weerd
PS: Don't bother replying to the 'whys' in this e-mail, they're meant
for self-reflection.
I think I can read his mind here.
He is clearly stating that the existing software is not adequate for his
needs. Let's face it, software written in perl, script, and C often
bloat things up unnecessarily. Sure, C compilers are getting better, but
small fast programs are often best produced by going to straight
assembly language.
Some of the correct tools, if i386 is being used - nasm or fasm or yasm,
ald plus a little study and Boom! small neat fast tools to do all of
this work. Screw that piece of junk cron! :)
--
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects.
-- Robert Heinlein
Re: crontab "last day of the month"
On Tue, Apr 06, 2010 at 04:18:22PM +0200, frantisek holop wrote:
| > Come on man .. 'can of worms' ?! It's not even a real challenge.
|
| you left off the year...
So you think it's my problem ? I showed two possible options, both
very workable (and easily extensible to add something simple as a
year). Yet...
| i'd rather not bloat my 3 line scripts with lookup tables
| and recursive date(1) calls, i prefer them easy and short.
...you choose to complain about the options I provided.
| here's the full picture of the current situation:
|
| on 1. april i get this file through monthly.local:
|
| logfile-2010-04.log.gz
|
| containing all _march_ entries (plus some april if it creeped in).
|
| i have 2 choices:
| 1. do the rename dance backwards one month
| 2. let the job actually run sometimes before midnight, last day of the month.
or 3. use "recursive date(1) calls" (how, exactly, are those
recursive ? you've got a weird definition of recursion)
gzip < ${LOG} > logfile-$(date -r $(($(date +%s) - 86400)) +%Y-%m).gz
There, I've put in the year for you, beacuse you couldn't think of
that yourself somehow. I don't really care much how you do it, but
that is not recursion nor very bloated, imo.
You come to this list to ask for something. It's not possible and you
are given alternative solutions. All you can do is complain about
them. Why ?
| regarding the "forward casualties" of log rotation, yes it's the same.
| while chronologically i still prefer the other way, i.e. have older
| entries in the newer log file (and not newer entries in older logfiles),
| but the main issue is, that i end up with the wrong file name.
It isn't an issue - the solution has been presented to you. A few
lines up, I've spelled it out for you (one possible solution, that
is). You just choose to publicly dismiss it because you don't like it.
Why ?
Paul 'WEiRD' de Weerd
PS: Don't bother replying to the 'whys' in this e-mail, they're meant
for self-reflection.
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
