[bug#40950] [PATCH] mcron, create /var/cron/tabs on activation

[bug#40950] [PATCH] mcron, create /var/cron/tabs on activation

[Marcin Karpezo]

---
Hi!
With big rekado help I'm sending you a patch with at least partially
fixes the issue of crontab -e reporting missing /var/cron/tabs
directory.

 gnu/services/mcron.scm | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/gnu/services/mcron.scm b/gnu/services/mcron.scm
index d9627c6bd0..ca9a54a041 100644
--- a/gnu/services/mcron.scm
+++ b/gnu/services/mcron.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2020 Marcin Karpezo <sirmacik@wioo.waw.pl>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -128,6 +129,12 @@ files."
               (actions
                (list (shepherd-schedule-action mcron files)))))))))

+(define (mcron-service-activation config)
+  (with-imported-modules '((guix build utils))
+    #~(begin
+        (use-modules (guix build utils))
+        (mkdir-p "/var/cron/tabs"))))
+
 (define mcron-service-type
   (service-type (name 'mcron)
                 (description
@@ -137,7 +144,10 @@ files."
                                           mcron-shepherd-services)
                        (service-extension profile-service-type
                                           (compose list
-                                                   mcron-configuration-mcron))))
+                                                   mcron-configuration-mcron))
+                       (service-extension activation-service-type
+                                          mcron-service-activation)))
+
                 (compose concatenate)
                 (extend (lambda (config jobs)
                           (mcron-configuration
--
2.26.2

[bug#40950] [PATCH] mcron, create /var/cron/tabs on activation

[Ludovic Courtès]

Hi Marcin,

Marcin Karpezo <sirmacik@wioo.waw.pl> skribis:

> With big rekado help I'm sending you a patch with at least partially
> fixes the issue of crontab -e reporting missing /var/cron/tabs
> directory.

Unless I’m mistaken, creating /var/cron/tabs will silence “crontab -e”,
but those entries will still be ignored because mcron’s crond is not
running (IIRC the cron functionality of mcron is separate and requires
you to run crond, which we don’t do.)

One option would be to write a different service altogether running that
daemon and creates /var/cron/tabs like you did.

Another option would be to remote the ‘crontab’ program from our ‘mcron’
package to at least avoid disappointments.

Thoughts?

Thanks,
Ludo’.

[bug#40950] [PATCH] mcron, create /var/cron/tabs on activation

[Marcin Karpezo]

2 maj 2020 00:06:16 Ludovic Courtès <ludo@gnu.org>:

> Hi Marcin,
>
> Marcin Karpezo <sirmacik@wioo.waw.pl> skribis:
>
>
> > With big rekado help I'm sending you a patch with at least partially
> > fixes the issue of crontab -e reporting missing /var/cron/tabs
> > directory.
> >
>
> Unless I’m mistaken, creating /var/cron/tabs will silence “crontab -e”,
> but those entries will still be ignored because mcron’s crond is not
> running (IIRC the cron functionality of mcron is separate and requires
> you to run crond, which we don’t do.)
>
> One option would be to write a different service altogether running that
> daemon and creates /var/cron/tabs like you did.
>
> Another option would be to remote the ‘crontab’ program from our ‘mcron’
> package to at least avoid disappointments.
>
> Thoughts?

Why won't start supporting and running mcron's crond daemon? That way guix will finally have normal fully functional cron which will ease administration not only on personal machines but also on server side. It's nice to have everything defined in one config file but it isn't as handy for multiuser setup.

I think instead of avoiding disappointment it would be better to positively surprise the users. I know that guix thrives in what sets it apart from other distros, but it's better to keep things standard whenever its possible and follow the rule of least surprise. Especially if it won't be damaging for the goals of the project.

Cheers
Marcin

[bug#40950] [PATCH] mcron, create /var/cron/tabs on activation

[Ludovic Courtès]

Hi Marcin,

Marcin Karpezo <sirmacik@wioo.waw.pl> skribis:

> 2 maj 2020 00:06:16 Ludovic Courtès <ludo@gnu.org>:
>
>> Hi Marcin,
>> Marcin Karpezo <sirmacik@wioo.waw.pl> skribis:
>>
>>
>> > With big rekado help I'm sending you a patch with at least
>> > partially fixes the issue of crontab -e reporting missing
>> > /var/cron/tabs directory.
>> >
>> Unless I’m mistaken, creating /var/cron/tabs will silence “crontab
>> -e”, but those entries will still be ignored because mcron’s crond
>> is not running (IIRC the cron functionality of mcron is separate and
>> requires you to run crond, which we don’t do.)
>> One option would be to write a different service altogether running
>> that daemon and creates /var/cron/tabs like you did.
>> Another option would be to remote the ‘crontab’ program from our
>> ‘mcron’ package to at least avoid disappointments.
>> Thoughts?
>
> Why won't start supporting and running mcron's crond daemon? That way
> guix will finally have normal fully functional cron which will ease
> administration not only on personal machines but also on server
> side. It's nice to have everything defined in one config file but it
> isn't as handy for multiuser setup.

Yeah I agree.  (I personally run a user shepherd, itself starting a user
mcron, but I admit that’s a config not everyone may be willing to
replicate.)

> I think instead of avoiding disappointment it would be better to
> positively surprise the users. I know that guix thrives in what sets
> it apart from other distros, but it's better to keep things standard
> whenever its possible and follow the rule of least
> surprise. Especially if it won't be damaging for the goals of the
> project.

Agreed!

That brings us to my first proposal above: writing a crond service that
runs mcron’s crond.  Would you like to give it a try?

(There’s also scron available.  I think someone had proposed a service
for it, but I can’t find it.)

Thanks,
Ludo’.

[bug#40950] [PATCH] mcron, create /var/cron/tabs on activation

[sirmacik]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Marcin,
>
> Marcin Karpezo <sirmacik@wioo.waw.pl> skribis:
>
>> 2 maj 2020 00:06:16 Ludovic Courtès <ludo@gnu.org>:
>>
>>> Hi Marcin,
>>> Marcin Karpezo <sirmacik@wioo.waw.pl> skribis:
>>>
>>>
>>> > With big rekado help I'm sending you a patch with at least
>>> > partially fixes the issue of crontab -e reporting missing
>>> > /var/cron/tabs directory.
>>> >
>>> Unless I’m mistaken, creating /var/cron/tabs will silence “crontab
>>> -e”, but those entries will still be ignored because mcron’s crond
>>> is not running (IIRC the cron functionality of mcron is separate and
>>> requires you to run crond, which we don’t do.)
>>> One option would be to write a different service altogether running
>>> that daemon and creates /var/cron/tabs like you did.
>>> Another option would be to remote the ‘crontab’ program from our
>>> ‘mcron’ package to at least avoid disappointments.
>>> Thoughts?
>>
>> Why won't start supporting and running mcron's crond daemon? That way
>> guix will finally have normal fully functional cron which will ease
>> administration not only on personal machines but also on server
>> side. It's nice to have everything defined in one config file but it
>> isn't as handy for multiuser setup.
>
> Yeah I agree.  (I personally run a user shepherd, itself starting a user
> mcron, but I admit that’s a config not everyone may be willing to
> replicate.)
>
>> I think instead of avoiding disappointment it would be better to
>> positively surprise the users. I know that guix thrives in what sets
>> it apart from other distros, but it's better to keep things standard
>> whenever its possible and follow the rule of least
>> surprise. Especially if it won't be damaging for the goals of the
>> project.
>
> Agreed!
>
> That brings us to my first proposal above: writing a crond service that
> runs mcron’s crond.  Would you like to give it a try?
>
> (There’s also scron available.  I think someone had proposed a service
> for it, but I can’t find it.)

Dear Ludo’,

I haven't forgot about this issue. Writing simple service isn't a
problem, but I've found out that despite running cron daemon, crontab
doesn't notice it. I've reported that behaviour on mcron mailing
list[1].

Second issue that I haven't figured out yet is creating crontab file for
each user of the system upon cron service activation. It needs
/var/cron/tabs to be owned by root: and crontab for each user to be
owned by him, ideally by (for example) user1:user1. 

[1] https://lists.gnu.org/archive/html/bug-mcron/2020-05/msg00012.html

--
Cheers,
sirmacik
PGP: 0xE0DC81D523891771

[bug#40950] Mcron originator: My opinion

[Dale Mellor]

Hello,

   for information I don't agree with having a central crond process
running on the system.  I put it in mcron only for compatibility with
legacy crons, but think that it is *much* better for each service which
needs one, and each user, to run their own private daemon and manage their
own configuration.  The reasons include:

  * reliability: one faulty client or scheme configuration clause is less
likely to make the system unavailable to others;
  * security: UNIX users can only mess with their own configurations, and
there is no need for any SUID programs;
  * safety: I think the mcron personality gets much more use in practice,
hence is tested by many more people;
  * efficiency: using the legacy crontab directories means that the daemon
has to wake up and scan all these files once per minute, even if the
actions are only performed once per day or even once per month;
  * convenience: I think it is actually simpler all round to have separate
configurations for each utility that needs cron service, rather than
splicing and editing existing central system-wide files.

   Basically, all these things are the reasons I developed mcron in the
first place.

   As an aside, I would love to be able to pull out all of the legacy
compatibility stuff from the mcron code, as it would massively simplify my
life!  (Don't worry, it probably won't happen).

Kind regards,
Dale Mellor

[bug#40950] Mcron originator: My opinion

[Dale Mellor]

As a postscript to the last message, note that the last bullet point is
especially pertinent in the context of Guix, where each package is
installed, with its particular configuration files, under its own root in
the system store.

[bug#40950] [PATCH] mcron, create /var/cron/tabs on activation

[Maxim Cournoyer]

Hello,

Dale Mellor <guix-devel-0brg6b@rdmp.org> writes:

> Hello,
>
>    for information I don't agree with having a central crond process
> running on the system.  I put it in mcron only for compatibility with
> legacy crons, but think that it is *much* better for each service which
> needs one, and each user, to run their own private daemon and manage their
> own configuration.  The reasons include:
>
>   * reliability: one faulty client or scheme configuration clause is less
> likely to make the system unavailable to others;
>   * security: UNIX users can only mess with their own configurations, and
> there is no need for any SUID programs;
>   * safety: I think the mcron personality gets much more use in practice,
> hence is tested by many more people;
>   * efficiency: using the legacy crontab directories means that the daemon
> has to wake up and scan all these files once per minute, even if the
> actions are only performed once per day or even once per month;
>   * convenience: I think it is actually simpler all round to have separate
> configurations for each utility that needs cron service, rather than
> splicing and editing existing central system-wide files.
>
>    Basically, all these things are the reasons I developed mcron in the
> first place.
>
>    As an aside, I would love to be able to pull out all of the legacy
> compatibility stuff from the mcron code, as it would massively simplify my
> life!  (Don't worry, it probably won't happen).

Thanks for tipping in!

In light of this, it seems it'd be a better option to add crond support
at the level of Guix Home, which would allow easily configuring mcrond
as a user service rather than at the system level.

Thanks,

Maxim