[gentoo-user] FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[gentoo-user] FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Remy Blank]

To save others some time investigating why their daily / weekly /
monthly cron jobs (those located in /etc/cron.{daily,weekly,monthly})
run twice when transitioning from DST to non-DST, it's a bug in
/usr/sbin/run-crons <https://bugs.gentoo.org/69777> (yes, you've read
the bug number correctly). The script is too eager to clean up stale
"lastrun" files.

I attached a patch to the bug, but considering how old the bug is, and
from the tone of the discussion there, I have little hope that it gets
applied. If you would like to see this fixed, it may be worth chiming in
on the bug. Or if you're a kind Gentoo developer listening to affected
users, to take action.

-- Remy

Re: [gentoo-user] FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Michael Orlitzky]

On 10/29/2017 07:46 AM, Remy Blank wrote:
> 
> I attached a patch to the bug, but considering how old the bug is, and
> from the tone of the discussion there, I have little hope that it gets
> applied. If you would like to see this fixed, it may be worth chiming in
> on the bug. Or if you're a kind Gentoo developer listening to affected
> users, to take action.
> 

If only it were that easy. First: vapier is the only member of the cron
project, and he's happy with the way cronbase works.

And then the real issue: no one knows what our cronbase is doing, and it
does whatever it does all wrong -- but some people are probably relying
on it. My proposal was to make cronbase stupider, with something like

  9  5  * * *   root   find /etc/cron.daily -execdir '{}' \;

That says: run everthing in cron.daily[0], every day, at 05:09. It does
exactly that: it has DST issues, if your machine is off the jobs won't
run, etc. But it's predictably stupid and works as advertised, unlike
the run-crons shell script we have now.

Do you need something smarter? Install anacron, fcron, cronie, or
whatever. But the worst thing we can do is try to mimic those
intelligent crons and have it fail to do so randomly. That's still your
best option, by the way: rewrite your crontab to avoid run-crons, and
install a smart cron implementation that does what you want.



[0] In practice, you would want to pass "-type f", "-executable", and
"-maxdepth 1" to the "find" command as well.

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Remy Blank]

Michael Orlitzky wrote on 2017-10-29 14:16:
> And then the real issue: no one knows what our cronbase is doing, and it
> does whatever it does all wrong -- but some people are probably relying
> on it. My proposal was to make cronbase stupider, with something like
> 
>   9  5  * * *   root   find /etc/cron.daily -execdir '{}' \;
> 
> That says: run everthing in cron.daily[0], every day, at 05:09. It does
> exactly that: it has DST issues, if your machine is off the jobs won't
> run, etc. But it's predictably stupid and works as advertised, unlike
> the run-crons shell script we have now.

This may solve my problem, but it also changes other behavior that
people rely on, as you note, so I understand that there is some
resistance to change. My patch only solves the precise issue of
double-running jobs on DST to non-DST transition, without changing
behavior that people rely on (unless they do rely on the double-running,
of course <https://xkcd.com/1172/>).

> Do you need something smarter? Install anacron, fcron, cronie, or
> whatever. But the worst thing we can do is try to mimic those
> intelligent crons and have it fail to do so randomly. That's still your
> best option, by the way: rewrite your crontab to avoid run-crons, and
> install a smart cron implementation that does what you want.

No, my best option is to apply my patch locally and run with that, which
is what I've done, but it's always nice to reduce the number of patches
to keep track of. My own cron jobs are configured in /etc/cron.d anyway,
so they aren't affected. But at least I won't get the email from
logwatch twice anymore.

-- Remy

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-10-29 09:16, Michael Orlitzky wrote:

> Do you need something smarter? Install anacron, fcron, cronie, or
> whatever. But the worst thing we can do is try to mimic those
> intelligent crons and have it fail to do so randomly. That's still
> your best option, by the way: rewrite your crontab to avoid run-crons,
> and install a smart cron implementation that does what you want.

I was glad to find run-crons on gentoo when I migrated from debian,
which does (and always has done, AFAIR) what you suggest.  The main
reason was that anacron is also _stupid_: it thinks all months are 30
days.  If you schedule a monthly job with anacron, it will run on
January 1st, then on January 31st, then on March 2nd (in most years!)
etc.  Which may not be too bad when you consider one host by itself,
but the schedule will get all out of sync with other hosts if they run
real (non-anacron) monthly cronjobs.

So, for hosts that are not up 24h per day, anacron is _not_ a full
solution.  Something like run-crons is needed.  If the gentoo
implementation is too opaque or buggy, it should be rewritten, not
discarded.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

Am Sonntag, 29. Oktober 2017, 18:59:31 CET schrieb Ian Zimmerman:
> On 2017-10-29 09:16, Michael Orlitzky wrote:
> > Do you need something smarter? Install anacron, fcron, cronie, or
> > whatever. But the worst thing we can do is try to mimic those
> > intelligent crons and have it fail to do so randomly. That's still
> > your best option, by the way: rewrite your crontab to avoid run-crons,
> > and install a smart cron implementation that does what you want.
> 
> I was glad to find run-crons on gentoo when I migrated from debian,
> which does (and always has done, AFAIR) what you suggest.  The main
> reason was that anacron is also _stupid_: it thinks all months are 30
> days.  If you schedule a monthly job with anacron, it will run on
> January 1st, then on January 31st, then on March 2nd (in most years!)
> etc.  Which may not be too bad when you consider one host by itself,
> but the schedule will get all out of sync with other hosts if they run
> real (non-anacron) monthly cronjobs.
> 
> So, for hosts that are not up 24h per day, anacron is _not_ a full
> solution.  Something like run-crons is needed.  If the gentoo
> implementation is too opaque or buggy, it should be rewritten, not
> discarded.

It's nice that anacron apparently sucks, but what about fcron and cronie?  
I've always wondered why people who need these features don't just one of 
those.  Is there any reason not to?

(FTR: I used fcron for several years before migrating to systemd timers 
specifically because of its support for running missed jobs.)

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-01 10:25, Marc Joliet wrote:

> It's nice that anacron apparently sucks, but what about fcron and
> cronie?  I've always wondered why people who need these features don't
> just one of those.  Is there any reason not to?
> 
> (FTR: I used fcron for several years before migrating to systemd
> timers specifically because of its support for running missed jobs.)

I actually run cronie, and AFAICT it has no built-in anacron-like
offline schedule support, claims in the Handbook/wiki notwithstanding.
The writer of those claims may have been misled by run-crons :-)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Michael Orlitzky]

On 11/01/2017 12:55 PM, Ian Zimmerman wrote:
> 
> I actually run cronie, and AFAICT it has no built-in anacron-like
> offline schedule support

If you build cronie with USE=anacron, I think it also comes with an
"anacron" executable:

  https://github.com/cronie-crond/cronie/blob/master/README.anacron

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-01 13:42, Michael Orlitzky wrote:

> If you build cronie with USE=anacron, I think it also comes with an
> "anacron" executable:
> 
> https://github.com/cronie-crond/cronie/blob/master/README.anacron

I see, you're quite right.  The flag is off here, probably because I
built it when I was bootstrapping gentoo as a total newbie and never
updated it.

I'll investigate if it is smarter than the standalone anacron.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

 
On 2017-10-29 14:16, Michael Orlitzky wrote:

> On 10/29/2017 07:46 AM, Remy Blank wrote:

>> 

>> I attached a patch to the bug, but considering how old the bug is, and

>> from the tone of the discussion there, I have little hope that it gets

>> applied. If you would like to see this fixed, it may be worth chiming 

>> in

>> on the bug. Or if you're a kind Gentoo developer listening to affected

>> users, to take action.

>> 

> 

> If only it were that easy. First: vapier is the only member of the cron

> project, and he's happy with the way cronbase works.



This shows the lack of maintainers only. Don't wanna start a discussion 

about the reasons. IMHO the cronbase ebuild is faulty by design - sorry.

> 

> And then the real issue: no one knows what our cronbase is doing, and 

> it

> does whatever it does all wrong -- but some people are probably relying

> on it. My proposal was to make cronbase stupider, with something like

> 

>   9  5  * * *   root   find /etc/cron.daily -execdir '{}' \;

> 

> That says: run everthing in cron.daily[0], every day, at 05:09. It does

> exactly that: it has DST issues, if your machine is off the jobs won't

> run, etc. But it's predictably stupid and works as advertised, unlike

> the run-crons shell script we have now.



Looks a bit like a concept. As I have to work with different OS's I 

defined for me:



1. a crontab entry have to call a shell script always, at least a 

(minimal) wrapper

2. the shell script have to do some checks, e.g. the last run - I did 

wrote a small 'include' script for that



Thus it's portable. The job have to be done once.



> 

> Do you need something smarter? Install anacron, fcron, cronie, or

> whatever. But the worst thing we can do is try to mimic those

> intelligent crons and have it fail to do so randomly. That's still your

> best option, by the way: rewrite your crontab to avoid run-crons, and

> install a smart cron implementation that does what you want.



*I* recommend fcron, it is a bit under estimated. Beside its progressive 

design and w/o consulting the man page now again - AFAIR it can handle 

DST issues like above through options in fcrontab. But with my concept I 

don't need/use it. Be aware that some options could show an unexpected 

behavior too - nothing is perfect. Anyhow, by using fcron it is possible 

to eliminate the whole cronbase ebuild - it is part of the 20 percent 

(round about) which are faulty in Gentoo.



Just an opinion.

> 

> 

> 

> [0] In practice, you would want to pass "-type f", "-executable", and

> "-maxdepth 1" to the "find" command as well.



-- 

Sent with eQmail-1.10

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-03 02:53, Kai Peter wrote:

> 2. the shell script have to do some checks, e.g. the last run - I did
> wrote a small 'include' script for that

Isn't your 'small include script' just another implementation of run-crons?

If not: how does it handle _missed_ jobs, if at all?

If you want to run a monthly job on a host that is not always on, do you
have to pretend it's an hourly job and check in the script itself?

> Thus it's portable. The job have to be done once.

If you want your _entire_ configuration to be portable, and my above point
about monthly schedule sticks, then you have to ignore the monthly
feature of all the crons on all your systems, because you cannot rely on
it in any one system.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Thu, Nov 2, 2017 at 6:53 PM, Kai Peter <kp@lists.openqmail.org> wrote:
>
> *I* recommend fcron, it is a bit under estimated. Beside its progressive
> design and w/o consulting the man page now again - AFAIR it can handle
> DST issues like above through options in fcrontab. But with my concept I
> don't need/use it. Be aware that some options could show an unexpected
> behavior too - nothing is perfect. Anyhow, by using fcron it is possible
> to eliminate the whole cronbase ebuild - it is part of the 20 percent
> (round about) which are faulty in Gentoo.
>

If some people want to maintain Gentoo-specific solutions I certainly
won't tell them that they can't, but 99% of the time when there is an
upstream tool that does something out of the box, and a
Gentoo-specific stack of shell scripts, the upstream tool is going to
do a better job.

That doesn't mean that the simpler tool isn't sometimes the better
solution.  I have hosts that use the systemd-timesyncd implementation,
and I have hosts that run ntpd.  There is a reason for each to exist.
The nice thing about Gentoo is that you can use whatever you prefer,
but if you care that much about what happens on the DST change or on
the 31st day of the month, you're probably better off starting from a
more full-featured cron implementation than trying to re-create one.

-- 
Rich

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

On 2017-11-03 18:21, Ian Zimmerman wrote:

> On 2017-11-03 02:53, Kai Peter wrote:

> 

>> 2. the shell script have to do some checks, e.g. the last run - I did

>> wrote a small 'include' script for that

> 

> Isn't your 'small include script' just another implementation of 

> run-crons?

No.

> 

> If not: how does it handle _missed_ jobs, if at all?

Whatever _missed_ means - at least it's 
a question of error handling.

> 

> If you want to run a monthly job on a host that is not always on, do 

> you

> have to pretend it's an hourly job and check in the script itself?

This is a special case to me. IMHO special cases have to be handled 

special or much better: avoid it.

> 

>> Thus it's portable. The job have to be done once.

> 

> If you want your _entire_ configuration to be portable, and my above 

> point

> about monthly schedule sticks, then you have to ignore the monthly

> feature of all the crons on all your systems, because you cannot rely 

> on

> it in any one system.

My _entire_ config isn't portable, but some
 (important) parts of it.



-- 

Sent with eQmail-1.10

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-04 01:39, Kai Peter wrote:

> > If you want to run a monthly job on a host that is not always on, do
> > you have to pretend it's an hourly job and check in the script
> > itself?
> 
> This is a special case to me. IMHO special cases have to be handled
> special or much better: avoid it.

Sorry, I don't get this.  How do you avoid this situation?  By not
having any monthly jobs?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

 
On 2017-11-04 18:42, Ian Zimmerman wrote:

> On 2017-11-04 01:39, Kai Peter wrote:

> 

>> > If you want to run a monthly job on a host that is not always on, do

>> > you have to pretend it's an hourly job and check in the script

>> > itself?

>> 

>> This is a special case to me. IMHO special cases have to be handled

>> special or much better: avoid it.

> 

> Sorry, I don't get this.  How do you avoid this situation?  By not

> having any monthly jobs?

No, monthly jobs are fine, but you mentioned a special case as the host 

is may be off at that time. Perhaps you can do: run all jobs which 

didn't run because the host was off at next startup once. fcron has such 

an option. Depending on the exact situation it could require additional 

configuration/checks.



The decision what have to be done MUST be made by the user/sysadmin 

first. Than you can do the config to reach your goal. But that does go 

to far now.



-- 

Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Alan McKinnon]

On 05/11/2017 16:28, Kai Peter wrote:
> 
> 
> On 2017-11-04 18:42, Ian Zimmerman wrote:
> 
>> On 2017-11-04 01:39, Kai Peter wrote:
> 
>>
> 
>>> > If you want to run a monthly job on a host that is not always on, do
> 
>>> > you have to pretend it's an hourly job and check in the script
> 
>>> > itself?
> 
>>>
> 
>>> This is a special case to me. IMHO special cases have to be handled
> 
>>> special or much better: avoid it.
> 
>>
> 
>> Sorry, I don't get this.  How do you avoid this situation?  By not
> 
>> having any monthly jobs?
> 
> No, monthly jobs are fine, but you mentioned a special case as the host
> is may be off at that time. Perhaps you can do: run all jobs which
> didn't run because the host was off at next startup once. fcron has such
> an option. Depending on the exact situation it could require additional
> configuration/checks.


It is not really cron's job to figure out what it thinks the user might
want if the machine was off when the job should have run. That is
expecting far too much intelligence from cron.

Cron is wall-clock time and time based:

When the time is *this*, then do *that*

anacron has some logic for this case of jobs not run but to do it, it
had to give up it's strictly wall-clock time based approach

There are other schedulers out there that succeed where cron fails (eg
Control-M, chronos, quartz), but those are all large, bulky, designed
for big complex installs/requirements and probably not suited for simple
things you'd deploy out of a base in portage

cron is stupid and deliberately so. We really ought to let it remain stupid

> The decision what have to be done MUST be made by the user/sysadmin
> first. Than you can do the config to reach your goal. But that does go
> to far now.

+1 agreed.

I've always maintained that cron cannot possibly know what the scripts
it launches deem to be correct. It's a countdown time and launcher, not
an orchestrator. It can figure out what to do if 2am happens twice (just
don't do it the second time), but not what should happen if 2am was
missed for any reason, including DST or poweroff or overeager ntpdate

The simplest approach to fixing missed jobs is to have the script itself
track what is correct. If it's lock and records files indicate something
didn't happen when it should, the script can do it's own repair or do
it's work twice. Or whatever else is appropriate.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Sun, Nov 5, 2017 at 6:43 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> There are other schedulers out there that succeed where cron fails (eg
> Control-M, chronos, quartz), but those are all large, bulky, designed
> for big complex installs/requirements and probably not suited for simple
> things you'd deploy out of a base in portage
>

Amusing that you classify 99.999% of all desktop installs as "big
complex installs."

But, I agree that it makes far more sense to just have desktop users
use an appropriate cron implementation designed to handle the machine
being off most of the time vs trying to use shell scripting to make
vixie cron into such an implementation.

FWIW this is probably the reasoning behind including cron-like
functionality in systemd, and having it support optionally running
jobs if the system was down during a calendar-based event.  It was
considered bare-bones functionality that any desktop or generic server
would need.  It is, of course, optional, and just about any kind of
rule is supported.  I personally use systemd-cron which basically is a
wrapper+generator around /etc/crontab and the various /etc/cron.*/
scripts.


-- 
Rich

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-05 07:11, Rich Freeman wrote:

> But, I agree that it makes far more sense to just have desktop users
> use an appropriate cron implementation designed to handle the machine
> being off most of the time vs trying to use shell scripting to make
> vixie cron into such an implementation.
> 
> FWIW this is probably the reasoning behind including cron-like
> functionality in systemd, and having it support optionally running
> jobs if the system was down during a calendar-based event.  It was
> considered bare-bones functionality that any desktop or generic server
> would need.

If Kai is right that fcron handles it, the reason is probably systemd
people thought that had to match the functionality to be considered a
full replacement.  Especially since fcron is the normal system cron on
Fedora/RH, right?

> I personally use systemd-cron which basically is a wrapper+generator
> around /etc/crontab and the various /etc/cron.*/ scripts.

If your dislike for having this in cron itself comes down to shell
script vs. C code, and it appears so from the above, I'm not at all sure
I agree.  This to me seems one of the few tasks where shell script is in
fact a good fit: mainly looking at files, timestamps, and running other
programs. 

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

 


> 

> There are other schedulers out there that succeed where cron fails (eg

> Control-M, chronos, quartz), but those are all large, bulky, designed

> for big complex installs/requirements and probably not suited for 

> simple

> things you'd deploy out of a base in portage

> 

Long time ago I decided to use fcron only. The reasons doesn't matter, 

but thus I can talk about fcron only. But you are right, there are a lot 

of others. At least I tried to answer Ian's question as exact as 

possible. I realized the inaccuracy in it too. Wasn't it to me? Than 

sorry for the noise.



> cron is stupid and deliberately so. We really ought to let it remain 

> stupid

> 

>> The decision what have to be done MUST be made by the user/sysadmin

>> first. Than you can do the config to reach your goal. But that does go

>> to far now.

> 

> +1 agreed.

> 

> I've always maintained that cron cannot possibly know what the scripts

> it launches deem to be correct. It's a countdown time and launcher, not

> an orchestrator. It can figure out what to do if 2am happens twice 

> (just

> don't do it the second time), but not what should happen if 2am was

> missed for any reason, including DST or poweroff or overeager ntpdate

> 

> The simplest approach to fixing missed jobs is to have the script 

> itself

> track what is correct. If it's lock and records files indicate 

> something

> didn't happen when it should, the script can do it's own repair or do

> it's work twice. Or whatever else is appropriate.



@Alan, I like your writings. Unfortunately I'm not able to do so, thus 

my (very seldom) answers are sometimes to short. ;-)



OT: Seems that since the last update of my MUA the formatting of my 

mails is broken - at least at reply's. There are extra line breaks. 

Grrrr - if you not do everything by yourself ...   ;-)



-- 

Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Sun, 05 Nov 2017 17:56:56 +0100, Kai Peter wrote:

> OT: Seems that since the last update of my MUA the formatting of my 
> 
> mails is broken - at least at reply's. There are extra line breaks. 
> 
> Grrrr - if you not do everything by yourself ...   ;-)

... at least you have someone else to blame.


-- 
Neil Bothwick

WinErr 678: This will end your Windows session. Do you want to play
another game?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

 
On 2017-11-05 18:12, Neil Bothwick wrote:

> On Sun, 05 Nov 2017 17:56:56 +0100, Kai Peter wrote:

> 

>> OT: Seems that since the last update of my MUA the formatting of my

>> 

>> mails is broken - at least at reply's. There are extra line breaks.

>> 

>> Grrrr - if you not do everything by yourself ...   ;-)

> 

> ... at least you have someone else to blame.



Nobody to blame, it's more to excuse me.

-- 

Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Sun, Nov 5, 2017 at 8:10 AM, Ian Zimmerman <itz@very.loosely.org> wrote:
> On 2017-11-05 07:11, Rich Freeman wrote:
>
>> But, I agree that it makes far more sense to just have desktop users
>> use an appropriate cron implementation designed to handle the machine
>> being off most of the time vs trying to use shell scripting to make
>> vixie cron into such an implementation.
>>
>> FWIW this is probably the reasoning behind including cron-like
>> functionality in systemd, and having it support optionally running
>> jobs if the system was down during a calendar-based event.  It was
>> considered bare-bones functionality that any desktop or generic server
>> would need.
>
> If Kai is right that fcron handles it, the reason is probably systemd
> people thought that had to match the functionality to be considered a
> full replacement.  Especially since fcron is the normal system cron on
> Fedora/RH, right?

Honestly, I think it is more because it is almost impossible to cover
both desktops and servers without these features, so there is little
point in adding timers if you don't support both.  The reason they're
there at all is because it falls into "core functionality" which is a
goal of systemd - it is a bit like busybox in that regard (and, indeed
busybox also implements a crond).

However, while systemd aims to go further than busybox it doesn't
actually aim to replace all the other tools that it overlaps with.
For example, resolved isn't a full substitute for bind, and timesyncd
isn't a full substitute for ntp (the latter of which is relatively
popular on random systems and not just dedicated servers).  In general
they try to focus on the client-side stuff only, with a moderate but
not minimal scope.

>
>> I personally use systemd-cron which basically is a wrapper+generator
>> around /etc/crontab and the various /etc/cron.*/ scripts.
>
> If your dislike for having this in cron itself comes down to shell
> script vs. C code, and it appears so from the above, I'm not at all sure
> I agree.  This to me seems one of the few tasks where shell script is in
> fact a good fit: mainly looking at files, timestamps, and running other
> programs.

So, two things here:

First, I'm honestly not sure I buy that shell scripts are the best
tool here.  Yes, they can look at files and timestamps, but I tend to
be of the school that shell scripts are poor environments to write
actual software in.  At best they work reasonably well for glue.  I'm
not advocating for C, but if I were implementing a cron I wouldn't be
doing it in bash.

Second, my actual objection is more to sticking wrappers around an
upstream program just to extend its capabilities, when other software
is maintained upstream that already does what you're re-inventing.
When you already have 47 different cron implementations out there, I'm
not sure it adds a lot to have a distro-specific solution.  The distro
should certainly be providing stuff like /etc/cron.*/ and the scripts
inside when upstream isn't providing them.  By all means include a
stock wrapper /etc/crontab that runs that stuff at set times for those
running 24x7 with vixie cron.  If run-scripts was implemented in
python instead of shell this objection wouldn't go away.

Sure, back in the early days of Gentoo maybe it made a little more
sense to have our own tools just like everybody else did, and I'm not
sure I'd advocate to go removing them either.  However, I can
certainly sympathize with WONTFIX when people want to continue to add
features to them.  They're just a minimal starting point that is
implementation-agnostic - use the right tool if your requirements
exceed these.


-- 
Rich

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Alan McKinnon]

On 05/11/2017 17:11, Rich Freeman wrote:
> On Sun, Nov 5, 2017 at 6:43 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>> There are other schedulers out there that succeed where cron fails (eg
>> Control-M, chronos, quartz), but those are all large, bulky, designed
>> for big complex installs/requirements and probably not suited for simple
>> things you'd deploy out of a base in portage
>>
> 
> Amusing that you classify 99.999% of all desktop installs as "big
> complex installs."

Heh :-)

Well, to a first approximation all Linux installs are servers or phones
so whatever is going on in desktop space can be disregarded

>
> But, I agree that it makes far more sense to just have desktop users
> use an appropriate cron implementation designed to handle the machine
> being off most of the time vs trying to use shell scripting to make
> vixie cron into such an implementation.

Vixie cron and it's clones needs to die, really. The number of places
where it makes sense is falling by the day; showing no sign of slowing
down. I think I have 3 cronjobs left across my fleet that actually make
sense and all of them are just-in-case-I-screwed-up-elsewhere safety
nets. The very idea of cron itself comes from the '80s and to be honest,
we don't work anymore like we did in the 80s
> 
> FWIW this is probably the reasoning behind including cron-like
> functionality in systemd, and having it support optionally running
> jobs if the system was down during a calendar-based event.  It was
> considered bare-bones functionality that any desktop or generic server
> would need.  It is, of course, optional, and just about any kind of
> rule is supported.  I personally use systemd-cron which basically is a
> wrapper+generator around /etc/crontab and the various /etc/cron.*/
> scripts.

Agreed again. My desktop cronjobs are all empty and when I had some they
were of the "do this once a week or once a day" variety. I didn't care
when they ran, just that they did every so often


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-05 14:22, Rich Freeman wrote:

> Second, my actual objection is more to sticking wrappers around an
> upstream program just to extend its capabilities, when other software
> is maintained upstream that already does what you're re-inventing.
> When you already have 47 different cron implementations out there, I'm
> not sure it adds a lot to have a distro-specific solution.  The distro
> should certainly be providing stuff like /etc/cron.*/ and the scripts
> inside when upstream isn't providing them.  By all means include a
> stock wrapper /etc/crontab that runs that stuff at set times for those
> running 24x7 with vixie cron.  If run-scripts was implemented in
> python instead of shell this objection wouldn't go away.

I really want to stop prologing the agony of this thread, but I just
have to point out that when you install cronie with the anacron flag (as
I just did, if only to know what I'm talking about), you _still_ get a
wrapper: it's called /etc/cron.hourly/0anacron.  Simpler than run-crons
for sure, but the principle is the same.

After all distros exist for a reason (over and above building packages).
If upstreams always did the glue job right, a bot could handle all the
package builds and you gentoo devs could go home ;-)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-05 21:40, Alan McKinnon wrote:

> Agreed again. My desktop cronjobs are all empty and when I had some
> they were of the "do this once a week or once a day" variety. I didn't
> care when they ran, just that they did every so often

What about the synchronization and predictability aspect, which I
mentioned in my 1st entry in this thread?

I want _all_ my machines to do a full fsck when I turn them on the 1st
of a month.  (if a month seems too long, substitute "Sunday").  Anything
else is madness.

And yeah, desktops matter to me.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Sun, Nov 5, 2017 at 4:40 PM, Ian Zimmerman <itz@very.loosely.org> wrote:
> On 2017-11-05 14:22, Rich Freeman wrote:
>
>> Second, my actual objection is more to sticking wrappers around an
>> upstream program just to extend its capabilities, when other software
>> is maintained upstream that already does what you're re-inventing.
>> When you already have 47 different cron implementations out there, I'm
>> not sure it adds a lot to have a distro-specific solution.  The distro
>> should certainly be providing stuff like /etc/cron.*/ and the scripts
>> inside when upstream isn't providing them.  By all means include a
>> stock wrapper /etc/crontab that runs that stuff at set times for those
>> running 24x7 with vixie cron.  If run-scripts was implemented in
>> python instead of shell this objection wouldn't go away.
>
> I really want to stop prologing the agony of this thread, but I just
> have to point out that when you install cronie with the anacron flag (as
> I just did, if only to know what I'm talking about), you _still_ get a
> wrapper: it's called /etc/cron.hourly/0anacron.  Simpler than run-crons
> for sure, but the principle is the same.

Sure, but that is upstream-maintained, and that is my point.  It comes
out of the upstream contrib directory:
https://github.com/cronie-crond/cronie/blob/master/contrib/0anacron

> After all distros exist for a reason (over and above building packages).
> If upstreams always did the glue job right, a bot could handle all the
> package builds and you gentoo devs could go home ;-)

In your example upstream DID do the glue job right.  Even so, the glue
isn't the part I object to.  Running cron jobs after a system comes
back online isn't glue - that is core functionality, even if not every
implementation has it.

Distros will always have to do integration work, and that is fine.
That is the role of a distro.  And sometimes distros have to roll
their own tools when they just aren't available.  Once upon a time
service managers fell into that category.  Now this is less the case.

There is of course nothing wrong if people want to implement things.
I just tend to prefer to stick with stuff that has an upstream that is
bigger than one distro.

-- 
Rich

[gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Ian Zimmerman]

On 2017-11-05 17:17, Rich Freeman wrote:

> Distros will always have to do integration work, and that is fine.
> That is the role of a distro.  And sometimes distros have to roll
> their own tools when they just aren't available.  Once upon a time
> service managers fell into that category.  Now this is less the case.

What's a service manager?  Is making cron care about missed jobs service
management, but running daily/weekly/monthly jobs isn't?  I'd find such
a distinction quite tenuous.

> There is of course nothing wrong if people want to implement things.
> I just tend to prefer to stick with stuff that has an upstream that is
> bigger than one distro.

Well that's another thing.  I will tend to agree when upstream is an
independent project.  But here the development seems to be driven 99% by
RedHat.  Look at the ChangeLog.

I know of another project that's bigger than a distro ... now that it
forced its way into all the others.

And now I really shut up!

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Mon, Nov 6, 2017 at 10:45 AM, Ian Zimmerman <itz@very.loosely.org> wrote:
> On 2017-11-05 17:17, Rich Freeman wrote:
>
>> Distros will always have to do integration work, and that is fine.
>> That is the role of a distro.  And sometimes distros have to roll
>> their own tools when they just aren't available.  Once upon a time
>> service managers fell into that category.  Now this is less the case.
>
> What's a service manager?

Easiest way to explain it is to give examples.  Openrc, systemd,
runit, and upstart are all service managers.  I'd argue that sysvinit
is also a service manager but nobody really uses it as one unless you
count getty as a service.

A service manager is a program used to manage the daemons running on a system.

> Is making cron care about missed jobs service
> management, but running daily/weekly/monthly jobs isn't?

Cron is generally not considered a service manager though there is
some overlap since it does manage jobs.  I wouldn't make any
distinction in this regard to how it handles missed jobs.  Those are
just features that a cron implementation can have or lack.

It is like arguing about whether sh, dash, or bash are shells on the
basis of the features they provide.  They're all shells, but at the
same time we can acknowledge that they have different feature sets.

-- 
Rich

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

On Monday, 6 November 2017 23:11:44 GMT Rich Freeman wrote:
> On Mon, Nov 6, 2017 at 10:45 AM, Ian Zimmerman <itz@very.loosely.org> wrote:
> > On 2017-11-05 17:17, Rich Freeman wrote:
> >> Distros will always have to do integration work, and that is fine.
> >> That is the role of a distro.  And sometimes distros have to roll
> >> their own tools when they just aren't available.  Once upon a time
> >> service managers fell into that category.  Now this is less the case.
> > 
> > What's a service manager?
> 
> Easiest way to explain it is to give examples.  Openrc, systemd,
> runit, and upstart are all service managers.  I'd argue that sysvinit
> is also a service manager but nobody really uses it as one unless you
> count getty as a service.
> 
> A service manager is a program used to manage the daemons running on a
> system.
> > Is making cron care about missed jobs service
> > management, but running daily/weekly/monthly jobs isn't?
> 
> Cron is generally not considered a service manager though there is
> some overlap since it does manage jobs.  I wouldn't make any
> distinction in this regard to how it handles missed jobs.  Those are
> just features that a cron implementation can have or lack.
> 
> It is like arguing about whether sh, dash, or bash are shells on the
> basis of the features they provide.  They're all shells, but at the
> same time we can acknowledge that they have different feature sets.

Apologies for prolonging this exhaustive and exhausting thread, but what is 
the Gentoo suggested cron application for a non-24-7 desktop these days?  I'm 
still using sys-process/vixie-cron because I guess that's what was de rigueur 
at the time I installed this system, although on other desktop PCs I run sys-
process/cronie.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Tue, 07 Nov 2017 08:48:22 +0000, Mick wrote:

> Apologies for prolonging this exhaustive and exhausting thread, but
> what is the Gentoo suggested cron application for a non-24-7 desktop
> these days?  I'm still using sys-process/vixie-cron because I guess
> that's what was de rigueur at the time I installed this system,
> although on other desktop PCs I run sys- process/cronie.

According to virtual/cron, cronie

RDEPEND="|| ( sys-process/cronie
                sys-process/vixie-cron
                sys-process/bcron
                sys-process/dcron
                sys-process/fcron
                sys-process/systemd-cron )"


-- 
Neil Bothwick

EASY TO INSTALL = Difficult to install, but instruction manual has
pictures.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Update of glibc-2.23 to 2.25

[Kai Peter]

 From the "cron" thread:

On 2017-11-05 18:12, Neil Bothwick wrote:
> On Sun, 05 Nov 2017 17:56:56 +0100, Kai Peter wrote:
> 
>> OT: Seems that since the last update of my MUA the formatting of my
>> 
>> mails is broken - at least at reply's. There are extra line breaks.
>> 
>> Grrrr - if you not do everything by yourself ...   ;-)
> 
> ... at least you have someone else to blame.

Unfortunately it would be possible. The issue did appear after the 
update of glibc. Under some circumstances the shell text processing 
could be broken. In this case it was DKIM signing, but I recognized 
another issue too. It was not hard to fix it and it's not worth the time 
to investigate further to me. It looks to me they reversed a change in 
glibc which was made a long time ago.

PS: I bet that the formatting is correct now ...  :-)
-- 
Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[John Campbell]

I don't know if this has been suggested yet, but I run cron on UTC,
which doesn't do daylight saving time. It's an option in cronie to set
the TZ for crontab.  I just have to transcode times from local to UTC
when setting up the job.