Re: Cron Jobs and Time Zones Has Anything Changed?
On Du, 06 dec 20, 12:23:43, Martin McCormick wrote: > > An on-going problem about self-education is that it's > easy to limit the scope so much that we miss connections. > Systemd timers doesn't even sound like a replacement for cron but > think of it as cron on steroids. It is also a replacement for at, not just cron. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Cron Jobs and Time Zones Has Anything Changed?
Andrei POPESCU writes: > On Jo, 03 dec 20, 07:39:14, Martin McCormick wrote: > > > > So, I need to read more general information about the > > differences between systemd and what we've been using up to > > recently. > > The Wikipedia page and/or https://systemd.io might be a good place to > start. > > Kind regards, > Andrei I've had a chance to investigate this more and the first thing I did was to go to wikipedia which told me about systemd, the on-going argument about it VS older ways to build unix-like systems and a time line when systemd began to take hold which was around 2015 when I retired from work so it kind of sneaked up on me and I didn't realize that I've been using it for 5 years, well, at least I didn't think much about systemd having different resources. I've used udev rules in making sound cards come up in the right order and that's totally a systemd thing. While searching for ways to use cron with different time zones, I found out about something called systemd timers just mentioned in this thread and it appears they definitely will do the job but one must magically have made the connection between this concept and the concept that cron, the usual go to resource for making lighting come on at a certain time, purging stale files or backing up the system now has a new kid on the block called systemd timers. One can even list all the active systemd timers https://www.maketecheasier.com/use-systemd-timers-as-cron-replacement/ $ systemctl list-timers And, sure enough, I had a number of them ticking away. An on-going problem about self-education is that it's easy to limit the scope so much that we miss connections. Systemd timers doesn't even sound like a replacement for cron but think of it as cron on steroids. One of the things in the wikipedia article about systemd was a complaint by someone that it's just too complicated. All I can say is that maybe or not that is true but that's just life. Start simple. Make more and more complexity as problems with simple show up. One day, try to make things simple again. Lot's of luck with that. I'm not so sure that being blind makes nearly as much difference these days as it once did, but making connections that relate one knowledge base to another in a meaningful way will always be a problem for us. Martin
Re: Cron Jobs and Time Zones Has Anything Changed?
On Jo, 03 dec 20, 07:39:14, Martin McCormick wrote: > > So, I need to read more general information about the > differences between systemd and what we've been using up to > recently. The Wikipedia page and/or https://systemd.io might be a good place to start. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Cron Jobs and Time Zones Has Anything Changed?
Hi David, On Fri, Dec 04, 2020 at 01:32:35PM +1100, David wrote: > On Fri, 4 Dec 2020 at 13:10, Andy Smith wrote: > > So much text written without clear statement of problem! > > I understand why you wrote that, but you might be unaware that > Martin has previously mentioned on this list that he is blind. Does that stop him writing exactly what he wants to achieve, what he's tried and where that failed? He can clearly write a lot, just not the things that move the situation forward, it seems. Let's get a problem, and help Martin fix it - what this list is for. Otherwise, personal blogs are a thing. Cheers, Andy
Re: Cron Jobs and Time Zones Has Anything Changed?
On Fri, 4 Dec 2020 at 13:10, Andy Smith wrote: [...] > I am surprised that just looking up documentation > on systemd timers doesn't answer that question for you. [...] > So much text written without clear statement of problem! I understand why you wrote that, but you might be unaware that Martin has previously mentioned on this list that he is blind. So if he doesn't find it as easy as I do to discover information, or if he feels like writing a long message, then I'm cool with that, because I'm in awe of what he can do.
Re: Cron Jobs and Time Zones Has Anything Changed?
Hello, On Thu, Dec 03, 2020 at 07:39:14AM -0600, Martin McCormick wrote: > I am guilty as charged but haven't yet found the relevant information > as to how systemd helps solve this issue. You can put a time zone in a systemd timer. I can't see how it can be stated any simpler than that. If you want to ask the question, "How do I make a systemd timer that runs a command at a given time in a given time zone?" just ask that question! Though I am surprised that just looking up documentation on systemd timers doesn't answer that question for you. If that is not your question, well, what is your question? So much text written without clear statement of problem! Sort of ironic that this started with asking why there are 3.5MiB of files in /usr/share/zoneinfo/ - has more than 3.5N of data been created yet between these couple of threads? Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Cron Jobs and Time Zones Has Anything Changed?
Martin McCormick writes: > I record a news broadcast from one of the BBC services > every week day at 17:45 British time. When Europe and North > America stop or start shifting daylight in Autumn or Spring, > there's a really good chance of missing some of the broadcasts if > one doesn't think about it since these shifts don't all happen on > the same time. Maybe you could create ~/.config/cron/bcast.vixie: 45 17 * * mon-fri echo hello or whatever command you want And install mcron, then run: TZ=Europe/London mcron --daemon -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Re: Cron Jobs and Time Zones Has Anything Changed?
> On Wed, Dec 02, 2020 at 01:58:45PM +, James B wrote: > > This might be wrong, but as far as I understand doesn't systemd > > now have the ability to manage cron jobs (as well as mount points, > > home folders and other things)?. Is there anything in this newer > > functionality that might make such a thing (re the request at the > > beginning of this thread) possible? > > Yes, I pointed this out to OP last time OP asked this exact question just a few days ago, so I don't know why they are asking again. I am guilty as charged but haven't yet found the relevant information as to how systemd helps solve this issue. Systemd is praised to the rooftops by some and cursed just as vehemently by others and it is what we are now using but it feels mostly like unix has always felt. I am obviously suffering from the worst sort of ignorance syndrome which can really bite in that sometimes, we have an idea what we don't know and other times, we don't even know that we don't know and that's really frightening. So, I need to read more general information about the differences between systemd and what we've been using up to recently. Martin McCormick
Re: Cron Jobs and Time Zones Has Anything Changed?
On Wed, Dec 02, 2020 at 01:17:02PM -0500, Dan Ritter wrote:
> As a name for the utility, I suggest "do-if-time-in" and require
> three parameters:
>
> do-if-time-in timezone time "command"
>
> As an interim fix, though: (and I know Greg's going to fix this)
>
> ---
> #!/bin/bash
> TZ=$1
> NOW=$(date +%H%M)
> echo $NOW
> if [ "$2" = "$NOW" ] ;
> then echo $("$3")
> fi
> ---
There are two natural designs for a utility like this. The first would
take three inputs (time zone, start time, end time), and return an exit
status that says whether the current time is within the interval.
The second design would take those same inputs, plus a command to execute
if and only if the current time is within the interval. For that design,
you'd use chain-loading (exec).
In either case, you don't need to pass the time zone as a parameter. You
can just use the TZ environment variable.
The real problem is how you specify the start and end times. In your
sample code, the result of the date command is HHMM format, so your
parameters would have to be given that way as well. HHMM may not be
the more useful format, especially since it doesn't give you a way to
specify a date.
For the purposes of this email, as an exercise, let's say we decide
to specify the start and end times in HH:MM format, and skip the whole
notion of specifying a date. That makes it reasonably easy to
implement.
---
#!/bin/bash
usage() {
echo "usage: $0 starttime endtime command [args]"
echo "starttime and endtime must be in HH:MM format"
}
if (($# < 3)); then
usage >&2
exit 1
fi
start=$1 end=$2
shift 2
if [[ $start != [0-9][0-9]:[0-9][0-9] || $end != [0-9][0-9]:[0-9][0-9] ]]; then
usage >&2
exit 1
fi
printf -v now '%(%H:%M)T' -1
if [[ $now >= $start && $now <= $end ]]; then
exec "$@"
fi
---
I didn't do anything with TZ because it's not *necessary*. If it's
given as an environment variable, it'll take hold automatically. If
it's not given, then the system's default time zone will be used.
Re: Cron Jobs and Time Zones Has Anything Changed?
Martin McCormick wrote:
> Greg Wooledge writes:
> > I was vaguely thinking of a similar approach. Set up a job that runs
> > every hour, or across a set of hours that will cover all the possible
> > cases that you care about, in your crontab. Within the job itself,
> > set a TZ variable and determine the time in that time zone by whatever
> > means necessary, and then either abort or continue based on that time.
This approach:
- does not replace crond, and so does not screw up upgrades to
the next version of Debian
- is a small, useful utility which could be adopted rapidly and
later packaged for Debian
- can be ignored by people who don't need it.
> Crontab would have a new field at the beginning of each
> line which could normally be left at "default" which would be the
> normal behavior that we are used to.
This approach requires one of:
- convince the upstream maintainer of cron to adopt it
- convince the Debian maintainer of cron to adopt it as a patch
that gets applied and potentially broken/fixed on each release
- creates a new cron package in competition with the existing
one
- creates a local cron package that has to be maintained along
with upstream changes
The third approach would be to build cronie for Debian, which is
probably do-able but is nevertheless a competitor for cron and
faces similar issues.
> I haven't looked at the C code for cron, but I have
> written a few perl scripts that do things with time and dates and
> the current epoch-based number of seconds since utc Midnight January
> 1, 1970 is based on the C modules such that one's current
> wall-clock time is time(localtime). Just a thought
Perl is definitely an appropriate language for a utility
like this.
libdatetime-timezone-perl
libtime-parsedate-perl
libdatetimex-easy-perl
are all extremely common installs.
As a name for the utility, I suggest "do-if-time-in" and require
three parameters:
do-if-time-in timezone time "command"
As an interim fix, though: (and I know Greg's going to fix this)
---
#!/bin/bash
TZ=$1
NOW=$(date +%H%M)
echo $NOW
if [ "$2" = "$NOW" ] ;
then echo $("$3")
fi
---
-dsr-
Re: Cron Jobs and Time Zones Has Anything Changed?
Greg Wooledge writes: > I was vaguely thinking of a similar approach. Set up a job that runs > every hour, or across a set of hours that will cover all the possible > cases that you care about, in your crontab. Within the job itself, > set a TZ variable and determine the time in that time zone by whatever > means necessary, and then either abort or continue based on that time. > > This is also similar to how one approaches a complex date-based task > such as "run on the second-to-last day of each month". For that one, > you can set up the job to run on the 27th through the 30th every > month. Then within the job itself, determine whether it's the > correct day, and abort if it's not. What I was thinking of is a modification to cron which should integrate nicely with what cron already does. Crontab would have a new field at the beginning of each line which could normally be left at "default" which would be the normal behavior that we are used to. If someone wanted to run a job at 15:00 each day in let's say Japanese time, the first field of the line would read Asia/Tokyo instead of default. The line might look like Asia/Tokyo 28 15 * * 1-5 sh -c ". $HOME/.master.env;beep -f700 -l500" Since all unix-like systems start out with UTC and use those /usr/share/zoneinfo data base files to calculate what local time is, that information is handy in the time() function. localtime(time) gets you the adjusted number of seconds for your locale arranged in a structure containing fields for the current year, day of month, day of the week plus the hours, minutes and seconds with the adjustment for Summer or Winter for that zone. The sample line above would cause cron to grab the current epoch in seconds (UTC), feed that to localtimebased on rules for /usr/share/zoneinfo/Asia/Tokyo and then all those values to match the fields on the rest of the line. The time of 15:28 or 3:28 PM in Tokyo occurs around 01:28 in the Central US time zone and that's when your computer would have beeped. This would happen Monday through Friday Japanese time which still would be Monday through Friday in the US but early in the morning. If the time referenced in Tokyo had been 7:00 in the morning , it would happen the previous evening in the US. As long as one designated the time zone correctly and doesn't forget that 07:00 on Monday morning in Japan equals 5 or 6 o/clock on the evening of the previous day, it should just work. I haven't looked at the C code for cron, but I have written a few perl scripts that do things with time and dates and the current epoch-based number of seconds since utc Midnight January 1, 1970 is based on the C modules such that one's current wall-clock time is time(localtime). Just a thought Martin
Re: Cron Jobs and Time Zones Has Anything Changed?
Apols..I hadn't read the original post, just saw this one from today! -- James B portoteache...@fastmail.com Em Qua, 2 Dez ʼ20, às 16:26, Andy Smith escreveu: > Hello, > > On Wed, Dec 02, 2020 at 01:58:45PM +, James B wrote: > > This might be wrong, but as far as I understand doesn't systemd > > now have the ability to manage cron jobs (as well as mount points, > > home folders and other things)?. Is there anything in this newer > > functionality that might make such a thing (re the request at the > > beginning of this thread) possible? > > Yes, I pointed this out to OP last time OP asked this exact question > just a few days ago, so I don't know why they are asking again. > Nothing has changed in the last couple of days to give crond TZ > support! > > Cheers, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > >
Re: Cron Jobs and Time Zones Has Anything Changed?
Hello, On Wed, Dec 02, 2020 at 01:58:45PM +, James B wrote: > This might be wrong, but as far as I understand doesn't systemd > now have the ability to manage cron jobs (as well as mount points, > home folders and other things)?. Is there anything in this newer > functionality that might make such a thing (re the request at the > beginning of this thread) possible? Yes, I pointed this out to OP last time OP asked this exact question just a few days ago, so I don't know why they are asking again. Nothing has changed in the last couple of days to give crond TZ support! Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Cron Jobs and Time Zones Has Anything Changed?
On Wed, Dec 02, 2020 at 08:53:28AM -0500, Dan Ritter wrote: > It would not be ridiculous to run a wrapper program out of, e.g. > cron.hourly, which used an explicitly set TZ as a cue to run > another job. I was vaguely thinking of a similar approach. Set up a job that runs every hour, or across a set of hours that will cover all the possible cases that you care about, in your crontab. Within the job itself, set a TZ variable and determine the time in that time zone by whatever means necessary, and then either abort or continue based on that time. This is also similar to how one approaches a complex date-based task such as "run on the second-to-last day of each month". For that one, you can set up the job to run on the 27th through the 30th every month. Then within the job itself, determine whether it's the correct day, and abort if it's not.
Re: Cron Jobs and Time Zones Has Anything Changed?
On 02/12/2020 10:30, Martin McCormick wrote: > In a recent discussion, someone indicated that there might be a > way to set individual parts such as accounts on a unix system so > that cron could use another time zone if needed to kickoff jobs > on that system based on the time in another country. > > As far as I understand cron, one can set the system's > time zone to only one value which is usually one's local clock > time and that works very well since system logs and cron jobs all > agree with what is appropriate for one's location. > > I record a news broadcast from one of the BBC services > every week day at 17:45 British time. When Europe and North > America stop or start shifting daylight in Autumn or Spring, > there's a really good chance of missing some of the broadcasts if > one doesn't think about it since these shifts don't all happen on > the same time. > > One can certainly get the time anywhere as recently > discussed by setting the TZ environment variable but, if you tell > cron to trigger a job at 17:45, it only knows when that is based > on the entire system's local time. > > Has anything changed recently to make this logic > obsolete? > > In my case, I just have an old Linux box for which I set > it's system time zone to Europe/London and call it good but this > could get out of hand if one had more than 2 or 3 such schedules. > > One could also setup VM's if you have the memory to spare > but this adds a lot of resource usage and complexity to the job > at hand so my question is basically, has anything fundamentally > changed in the way cron is used? > > This is not a complaint at all. I was first introduced to > unix-like systems in 1989 and immediately knew that this was the > sort of OS I wanted to stick with in amateur radio and technical > tinkering in general. > > Martin McCormick WB5AGZ > systemd timers seem to allow specification of activation time including a time zone. However, I'm not sure if DST changes are considered - it might just convert the specified time to the local time zone when the timer definition is read so that you can specify '17:45 GMT' and it runs at, say, your 10:45, but it won't automatically pick up that 17:45 GMT is not 11:45 local. I might be wrong, though. -- To do nothing is to be nothing. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: Cron Jobs and Time Zones Has Anything Changed?
This might be wrong, but as far as I understand doesn't systemd now have the ability to manage cron jobs (as well as mount points, home folders and other things)?. Is there anything in this newer functionality that might make such a thing (re the request at the beginning of this thread) possible? I'm currently learning how to manage these things with systemd rather than crontab and mount but still not quite up to speed with it, so may be overestimating the possiblities available. -- James B portoteache...@fastmail.com Em Qua, 2 Dez ʼ20, às 13:53, Dan Ritter escreveu: > Greg Wooledge wrote: > > On Wed, Dec 02, 2020 at 07:30:22AM -0600, Martin McCormick wrote: > > > In a recent discussion, someone indicated that there might be a > > > way to set individual parts such as accounts on a unix system so > > > that cron could use another time zone if needed to kickoff jobs > > > on that system based on the time in another country. > > > > It would not be ridiculous to run a wrapper program out of, e.g. > cron.hourly, which used an explicitly set TZ as a cue to run > another job. > > Interestingly, Red Hat and Ubuntu use cronie instead of Vixie's > cron, and cronie supports a per-crontab CRON_TZ variable. cronie > is not in Debian, but it could very likely be packaged easily. > > -dsr- > >
Re: Cron Jobs and Time Zones Has Anything Changed?
Greg Wooledge wrote: > On Wed, Dec 02, 2020 at 07:30:22AM -0600, Martin McCormick wrote: > > In a recent discussion, someone indicated that there might be a > > way to set individual parts such as accounts on a unix system so > > that cron could use another time zone if needed to kickoff jobs > > on that system based on the time in another country. > It would not be ridiculous to run a wrapper program out of, e.g. cron.hourly, which used an explicitly set TZ as a cue to run another job. Interestingly, Red Hat and Ubuntu use cronie instead of Vixie's cron, and cronie supports a per-crontab CRON_TZ variable. cronie is not in Debian, but it could very likely be packaged easily. -dsr-
Re: Cron Jobs and Time Zones Has Anything Changed?
On Wed, Dec 02, 2020 at 07:30:22AM -0600, Martin McCormick wrote: > In a recent discussion, someone indicated that there might be a > way to set individual parts such as accounts on a unix system so > that cron could use another time zone if needed to kickoff jobs > on that system based on the time in another country. crontab(5) LIMITATIONS The cron daemon runs with a defined timezone. It currently does not support per-user timezones. All the tasks: system's and user's will be run based on the configured timezone. Even if a user specifies the TZ environment variable in his crontab this will affect only the commands executed in the crontab, not the execution of the crontab tasks them‐ selves.
