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

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

[Robert Vollmert]

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?

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

[Jesse Gibbons]

> 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.

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

[Ludovic Courtès]

Hi Robert,

Robert Vollmert <rob@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’.

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

[Ludovic Courtès]

Hi Jesse,

Jesse Gibbons <jgibbons2357@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@gnu.org.
Overall, I agree that we should work to make it more pleasant to work
with!

Thanks,
Ludo’.

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

[Robert Vollmert]

> On 7. Jul 2019, at 16:24, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> Hi Robert,
> 
> Robert Vollmert <rob@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

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

[Ludovic Courtès]

Hi,

Robert Vollmert <rob@vllmrt.net> skribis:

>> On 7. Jul 2019, at 16:24, Ludovic Courtès <ludo@gnu.org> wrote:
>> 
>> Hi Robert,
>> 
>> Robert Vollmert <rob@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’.

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

[Robert Vollmert]

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.

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

[Ludovic Courtès]

Robert Vollmert <rob@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’.