| Message ID | 20200428212852.19552-1-sirmacik@wioo.waw.pl |
|---|---|
| State | Under Review |
| Headers | show |
| Series | [bug#40950] mcron, create /var/cron/tabs on activation | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
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’.
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
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’.
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
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
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.
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
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