GNU bug report logs - #36430
mcron would benefit from a better way to test jobs

Previous Next

To reply to this bug, email your comments to 36430 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Robert Vollmert <rob <at> vllmrt.net>
To: bug-guix <at> gnu.org
Subject: mcron would benefit from a better way to test jobs
Date: Sat, 29 Jun 2019 08:37:29 +0200

My issue:

Defined a mcron job in config.scm scheduled to run once a day,
with a scheme expression. How do I test this?

herd schedule mcron lists the job as merely a “Lambda expression”.
I learned how to give it a descriptive name, but still there’s
no script linked that I can run by hand.

One major improvement would be to have:

1. `herd schedule mcron` lists jobs with some kind of id
2. `herd execute mcron <id>` runs the specific mcron job

Or perhaps, any mcron job could be turned into a simple argument-less
guile or shell script that’s shown in the schedule listing?

Thoughts?

Message #8 received at 36430 <at> debbugs.gnu.org (full text, mbox):

From: Jesse Gibbons <jgibbons2357 <at> gmail.com>
To: <rob <at> vllmrt.net>
Cc: 36430 <at> debbugs.gnu.org
Subject: re: bug#36430: mcron would benefit from a better way to test jobs
Date: Sat, 29 Jun 2019 14:45:54 -0600

> My issue:

> Defined a mcron job in config.scm scheduled to run once a day,
> with a scheme expression. How do I test this?

Write the mcron job for a local installation of mcron first for
testing purposes, then move it into config.scm. That's how I do it.

> herd schedule mcron lists the job as merely a “Lambda expression”.
> I learned how to give it a descriptive name, but still there’s
> no script linked that I can run by hand.
>
> One major improvement would be to have:
>
> 1. `herd schedule mcron` lists jobs with some kind of id
> 2. `herd execute mcron <id>` runs the specific mcron job
>
> Or perhaps, any mcron job could be turned into a simple argument-less
> guile or shell script that’s shown in the schedule listing?
>
> Thoughts?
mcron --schedule=count gives you a listing of each scheduled job and
when it will next be run. I would expect "herd schedule mcron" runs
that command. I don't know about scheduling a function, but
if the scheduled job is a string it can be copied/pasted into a
terminal.

mcron is super buggy in my experience. If I power my laptop off
overnight it will skip all jobs scheduled for the day of the month,
even if they are scheduled for after I power it back on. And it doesn't
have a way to easily schedule for a given day of the week.

Message #11 received at 36430 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36430 <at> debbugs.gnu.org
Subject: Re: bug#36430: mcron would benefit from a better way to test jobs
Date: Sun, 07 Jul 2019 16:24:26 +0200

Hi Robert,

Robert Vollmert <rob <at> vllmrt.net> skribis:

> Defined a mcron job in config.scm scheduled to run once a day,
> with a scheme expression. How do I test this?
>
> herd schedule mcron lists the job as merely a “Lambda expression”.
> I learned how to give it a descriptive name, but still there’s
> no script linked that I can run by hand.

Commit 89fdd9ee0cc8817283449b33a8c1a2604c575c7e changes the rottlog job
in a simple way so we see an actual command rather than “Lambda
expression”.  I would recommend using this style to improve
transparency.

> One major improvement would be to have:
>
> 1. `herd schedule mcron` lists jobs with some kind of id
> 2. `herd execute mcron <id>` runs the specific mcron job
>
> Or perhaps, any mcron job could be turned into a simple argument-less
> guile or shell script that’s shown in the schedule listing?

The commit I’m referring to above does exactly that.

Perhaps as a first step we could recommend this style more prominently
in the manual?

Further improvements should probably go into mcron itself.  It’s a
rather small and simple code base, so if you were looking for a
rewarding hacking session for the week-end, it’s probably a good
candidate.  ;-)

Thanks,
Ludo’.

Message #14 received at 36430 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jesse Gibbons <jgibbons2357 <at> gmail.com>
Cc: 36430 <at> debbugs.gnu.org, rob <at> vllmrt.net
Subject: Re: bug#36430: mcron would benefit from a better way to test jobs
Date: Sun, 07 Jul 2019 16:26:44 +0200

Hi Jesse,

Jesse Gibbons <jgibbons2357 <at> gmail.com> skribis:

> mcron is super buggy in my experience. If I power my laptop off
> overnight it will skip all jobs scheduled for the day of the month,
> even if they are scheduled for after I power it back on. And it doesn't
> have a way to easily schedule for a given day of the week.

Buggy in what sense?  It’s definitely lacking useful features, as Robert
reported, but apart from that it seems to work well for me.

I’d encourage you to report any issues you have to bug-mcron <at> gnu.org.
Overall, I agree that we should work to make it more pleasant to work
with!

Thanks,
Ludo’.

Message #17 received at 36430 <at> debbugs.gnu.org (full text, mbox):

From: Robert Vollmert <rob <at> vllmrt.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36430 <at> debbugs.gnu.org
Subject: Re: bug#36430: mcron would benefit from a better way to test jobs
Date: Mon, 8 Jul 2019 09:18:32 +0200

> On 7. Jul 2019, at 16:24, Ludovic Courtès <ludo <at> gnu.org> wrote:
> 
> Hi Robert,
> 
> Robert Vollmert <rob <at> vllmrt.net> skribis:
> 
>> Defined a mcron job in config.scm scheduled to run once a day,
>> with a scheme expression. How do I test this?
>> 
>> herd schedule mcron lists the job as merely a “Lambda expression”.
>> I learned how to give it a descriptive name, but still there’s
>> no script linked that I can run by hand.
> 
> Commit 89fdd9ee0cc8817283449b33a8c1a2604c575c7e changes the rottlog job
> in a simple way so we see an actual command rather than “Lambda
> expression”.  I would recommend using this style to improve
> transparency.

I understand that passing an executable works better. But that also
loses the feature of allowing to write a script in place advertised by
the lambda variant.

I find that kind of “feature that doesn’t actually work” to be quite
painful.

A way to get the best of both worlds (within guix) would be to use
program-file / gexp, so maybe that’s what should be advertised in the
guix manual?


>> One major improvement would be to have:
>> 
>> 1. `herd schedule mcron` lists jobs with some kind of id
>> 2. `herd execute mcron <id>` runs the specific mcron job
>> 
>> Or perhaps, any mcron job could be turned into a simple argument-less
>> guile or shell script that’s shown in the schedule listing?
> 
> The commit I’m referring to above does exactly that.
> 
> Perhaps as a first step we could recommend this style more prominently
> in the manual?

I’ll see if I can get the gexp variant to work, and would provide
a manual patch if successful.

> Further improvements should probably go into mcron itself.  It’s a
> rather small and simple code base, so if you were looking for a
> rewarding hacking session for the week-end, it’s probably a good
> candidate.  ;-)

At this stage, there’s just too many small hacking sessions required
all over the place :). I’ll stick with filing bug reports for the
clear pain points if that’s ok?

Robert

Message #20 received at 36430 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36430 <at> debbugs.gnu.org
Subject: Re: bug#36430: mcron would benefit from a better way to test jobs
Date: Mon, 08 Jul 2019 11:54:35 +0200

Hi,

Robert Vollmert <rob <at> vllmrt.net> skribis:

>> On 7. Jul 2019, at 16:24, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> 
>> Hi Robert,
>> 
>> Robert Vollmert <rob <at> vllmrt.net> skribis:
>> 
>>> Defined a mcron job in config.scm scheduled to run once a day,
>>> with a scheme expression. How do I test this?
>>> 
>>> herd schedule mcron lists the job as merely a “Lambda expression”.
>>> I learned how to give it a descriptive name, but still there’s
>>> no script linked that I can run by hand.
>> 
>> Commit 89fdd9ee0cc8817283449b33a8c1a2604c575c7e changes the rottlog job
>> in a simple way so we see an actual command rather than “Lambda
>> expression”.  I would recommend using this style to improve
>> transparency.
>
> I understand that passing an executable works better. But that also
> loses the feature of allowing to write a script in place advertised by
> the lambda variant.

In Guix, if you write:

  #~(job … #$(program-file "do-something" #~(begin …)))

instead of:

  #~(job … (lambda () …))

you’re still writing Scheme code, and the result is pretty much the
same.

Now, from a pure mcron viewpoint (if you were to use it outside Guix), I
agree that procedures are handled in a suboptimal way.  Mcron should
simply display the procedure object, which includes its source location
info.

Aternately it could display its source location info as obtained with
‘program-source’ if that helps readability:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(system vm program)
scheme@(guile-user)> (program-source derivation (program-code derivation))
$6 = (2780 "guix/derivations.scm" 877 . 17)
--8<---------------cut here---------------end--------------->8---

> I find that kind of “feature that doesn’t actually work” to be quite
> painful.
>
> A way to get the best of both worlds (within guix) would be to use
> program-file / gexp, so maybe that’s what should be advertised in the
> guix manual?

Yes, definitely.

> At this stage, there’s just too many small hacking sessions required
> all over the place :). I’ll stick with filing bug reports for the
> clear pain points if that’s ok?

Sure, definitely!  It’s good to have all these pain points filed, and I
think many can be addressed quite easily, so that’ll help us improve
things gradually.

Thanks,
Ludo’.

Message #23 received at 36430 <at> debbugs.gnu.org (full text, mbox):

From: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36430 <at> debbugs.gnu.org
Subject: Re: bug#36430: mcron would benefit from a better way to test jobs
Date: Mon, 8 Jul 2019 13:58:25 +0200

One related issue that I just ran into, while trying out the gexp approach:

mcron jobs take an optional third naming argument, which are again better
not used because they replace the store filename in the “schedule”
output.

Message #26 received at 36430 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36430 <at> debbugs.gnu.org
Subject: Re: bug#36430: mcron would benefit from a better way to test jobs
Date: Thu, 11 Jul 2019 17:36:53 +0200

Robert Vollmert <rob <at> vllmrt.net> skribis:

> One related issue that I just ran into, while trying out the gexp approach:
>
> mcron jobs take an optional third naming argument, which are again better
> not used because they replace the store filename in the “schedule”
> output.

I see; that feature was not designed at all with Guix in mind, and
presumably on FHS systems the name is enough if you can mentally map it
to something in /usr.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.