Subject: Re: bug#36430: mcron would benefit from a better way to test jobs

From: Robert Vollmert <[email-masked]>
Date: Mon, 8 Jul 2019 09:18:32 +0200

> On 7. Jul 2019, at 16:24, Ludovic Courtès <[email-masked]> wrote:
> 
> Hi Robert,
> 
> Robert Vollmert <[email-masked]> 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