mcron would benefit from a better way to test jobs

  • Open
  • quality assurance status badge
Details
3 participants
  • Jesse Gibbons
  • Ludovic Courtès
  • Robert Vollmert
Owner
unassigned
Submitted by
Robert Vollmert
Severity
normal
R
R
Robert Vollmert wrote on 29 Jun 2019 08:37
(address . bug-guix@gnu.org)
B0BF7C44-23B2-42D7-8ACD-86E55DBDCE7D@vllmrt.net
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?
J
J
Jesse Gibbons wrote on 29 Jun 2019 22:45
(address . rob@vllmrt.net)(address . 36430@debbugs.gnu.org)
20190629144536.590b1b7f@gmail.com
Toggle quote (5 lines)
> 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.

Toggle quote (13 lines)
> 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.
L
L
Ludovic Courtès wrote on 7 Jul 2019 16:24
Re: bug#36430: mcron would benefit from a better way to test jobs
(name . Robert Vollmert)(address . rob@vllmrt.net)(address . 36430@debbugs.gnu.org)
87h87xapnp.fsf@gnu.org
Hi Robert,

Robert Vollmert <rob@vllmrt.net> skribis:

Toggle quote (7 lines)
> 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.

Toggle quote (8 lines)
> 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’.
L
L
Ludovic Courtès wrote on 7 Jul 2019 16:26
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)
877e8tapjv.fsf@gnu.org
Hi Jesse,

Jesse Gibbons <jgibbons2357@gmail.com> skribis:

Toggle quote (5 lines)
> 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’.
R
R
Robert Vollmert wrote on 8 Jul 2019 09:18
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 36430@debbugs.gnu.org)
325C9E85-468F-4EE3-93CC-C9F88D10E9CE@vllmrt.net
Toggle quote (18 lines)
> 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?


Toggle quote (13 lines)
>> 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.

Toggle quote (5 lines)
> 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
L
L
Ludovic Courtès wrote on 8 Jul 2019 11:54
(name . Robert Vollmert)(address . rob@vllmrt.net)(address . 36430@debbugs.gnu.org)
87wogsg8bo.fsf@gnu.org
Hi,

Robert Vollmert <rob@vllmrt.net> skribis:

Toggle quote (22 lines)
>> 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:

Toggle snippet (5 lines)
scheme@(guile-user)> ,use(system vm program)
scheme@(guile-user)> (program-source derivation (program-code derivation))
$6 = (2780 "guix/derivations.scm" 877 . 17)

Toggle quote (7 lines)
> 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.

Toggle quote (4 lines)
> 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’.
R
R
Robert Vollmert wrote on 8 Jul 2019 13:58
(address . 36430@debbugs.gnu.org)
2CB5CE05-5900-4E02-B56B-8D9F0700C32C@vllmrt.net
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.
L
L
Ludovic Courtès wrote on 11 Jul 2019 17:36
(name . Robert Vollmert)(address . rob@vllmrt.net)(address . 36430@debbugs.gnu.org)
87wogotwfe.fsf@gnu.org
Robert Vollmert <rob@vllmrt.net> skribis:

Toggle quote (6 lines)
> 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’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 36430@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 36430
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch