I'd like to go with fcron because it seems to work very well for most people, has a lot of features while having a small dependency tree.

I think fcron is kind of heavy for most users. I'd rather we switch to cronie, which is the descendent of vixie-cron. It's developed by RedHat, well maintained, supports PAM and SELinux and can be built with anacron features. Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

On Sun, 7 Nov 2010 21:09:12 +0100 Heiko Baums <lists@baums-on-web.de> wrote:

Am Sun, 7 Nov 2010 13:57:50 -0500 schrieb Kaiting Chen <kaitocracy@gmail.com>:

...

I think fcron is kind of heavy for most users. I'd rather we switch to cronie, which is the descendent of vixie-cron. It's developed by RedHat, well maintained, supports PAM and SELinux and can be built with anacron features.

I disagree with Kaiting, because cronie doesn't have anacron features.

If it's compiled with --enable-anacron there is no anacron feature compiled into cronie. Instead there is a separate anacron daemon compiled and that makes it unnecessarily complicated in using and configuring it. And people who need anacron features have to run two daemons and configure two daemons.

With fcron you have all in one and need to run and configure only one daemon. And fcron is by far not bloated and complicated to configure. Instead there are several ways to configure fcron like crontab, scripts in /etc/cron.{daily,weekly,monthly} and in /etc/cron.d. And to use anacron features you only need to prefix a crontab entry with an @.

So I think fcron is much more flexible, much easier to configure and to use than cronie, and has features for rather every use case.

And, please, don't make such a regression again.

Btw., cronie is in AUR since May and still has only 1 vote while fcron is proven to run very well since years.

Heiko

I agree with Heiko and Florian, I myself am using fcron since spring and moved at my machines(including VMs that run more often) one after another to fcron and I'm happy with it. It's easy to configure, comes with the default jobs (=runs /etc/cron.{daily,weekly,monthly}/*) and thus if for a user who doesn't do much with cron nothing to worry about, everyone else gets next to the default possibilities several features that are really helpful. Furthermore it is well documented, so even people who begin to play with cronjobs have a spot where they can look for information and get an answer almost for sure. Thorsten -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

On Sun, 7 Nov 2010 22:09:35 +0100, Thorsten Töpper <atsutane@freethoughts.de> wrote:

On Sun, 7 Nov 2010 21:09:12 +0100 Heiko Baums <lists@baums-on-web.de> wrote:

...

Am Sun, 7 Nov 2010 13:57:50 -0500 schrieb Kaiting Chen <kaitocracy@gmail.com>:

...

I think fcron is kind of heavy for most users. I'd rather we switch to cronie, which is the descendent of vixie-cron. It's developed by RedHat, well maintained, supports PAM and SELinux and can be built with anacron features.

I disagree with Kaiting, because cronie doesn't have anacron features.

If it's compiled with --enable-anacron there is no anacron feature compiled into cronie. Instead there is a separate anacron daemon compiled and that makes it unnecessarily complicated in using and configuring it. And people who need anacron features have to run two daemons and configure two daemons.

With fcron you have all in one and need to run and configure only one daemon. And fcron is by far not bloated and complicated to configure. Instead there are several ways to configure fcron like crontab, scripts in /etc/cron.{daily,weekly,monthly} and in /etc/cron.d. And to use anacron features you only need to prefix a crontab entry with an @.

So I think fcron is much more flexible, much easier to configure and to use than cronie, and has features for rather every use case.

And, please, don't make such a regression again.

Btw., cronie is in AUR since May and still has only 1 vote while fcron is proven to run very well since years.

Heiko

I agree with Heiko and Florian, I myself am using fcron since spring and moved at my machines(including VMs that run more often) one after another to fcron and I'm happy with it. It's easy to configure, comes with the default jobs (=runs /etc/cron.{daily,weekly,monthly}/*) and thus if for a user who doesn't do much with cron nothing to worry about, everyone else gets next to the default possibilities several features that are really helpful. Furthermore it is well documented, so even people who begin to play with cronjobs have a spot where they can look for information and get an answer almost for sure.

Thorsten

Let's not rush things: * Make sure that dcron is really a dead project and there is no chance for an update. Dropping a core package just because of one bug (which might get fixed) does not sound sane. * The crontab from dcron and fcron are not compatible. So fcron cannot be a simple drop-in repalcement * Some users might prefer dcron; simply replacing it is just not how we roll. People are free to install fcron if they like. -- Pierre Schmitz, https://users.archlinux.de/~pierre

The day was 07/11/10 23:58 when Heiko Baums had this to say......:

...

* The crontab from dcron and fcron are not compatible. So fcron cannot be a simple drop-in repalcement

What are the differences? I didn't need to change anything when I switched from fcron to the new dcron. If I had to change a bit it was so easy, that I can't remember anymore. The only thing which has changed was the command to edit the crontab. It's crontab for dcron and fcrontab for fcron. But for such changes an announcement can be written in the News section of the website, in the mailing list and in the package's post_install(). See the latest xorg upgrade.

And Florian's suggestion was not about removing dcron from the repos, but only to change the default cron daemon, which is installed without the user's interaction during installation, from dcron to fcron. So only new installations would be affected by this change anyway.

...

* Some users might prefer dcron; simply replacing it is just not how we roll. People are free to install fcron if they like.

I personally haven't seen big differences between fcron and dcron from the administrator's point of view.

Heiko

I've just switched to fcron, it's not a straight drop in AFAICT but not exactly hard. * crond needs changing to fcron in rc.conf DAEMONS * You'd need to backup/copy over your crontab from dcron over to fcron as it either overwrites the old on or uses one from a different location. (dcron syntax is working fine in fcron though) * crontab cmd is a little different (as the install msg tells you) If (big if i know) the default cron is going to be swapped out, the only thing i would suggest is warning in advance so people can backup crontab. +1 from me though for swapping, fcron looks a lot better/more versatile to me a humble user! Simon

On 09.11.2010 11:47, Dieter Plaetinck wrote:

FWIW: I've gone through the archives and found multiple threads about our cron discussions. http://mailman.archlinux.org/pipermail/arch-dev-public/2009-September/ http://mailman.archlinux.org/pipermail/arch-dev-public/2010-January (esp. http://mailman.archlinux.org/pipermail/arch-dev-public/2010-January/014781.h...)

Seems like the last time we were on the verge of switching to fcron, but didn't because Jim took over dcron upstream (and added his "yacron" features.)

The only negative thing i could find in the archives about fcron is that it doesn't support /etc/cron.d natively (but we can write scripts to work around that). Although Heiko seemed to suggest this is no longer true anymore. (?)

Other then that, it seems a solid featureful-but-simple-enough cron daemon.

Dieter

Sooooo, not a mail since a while. Can we replace dcron now? :)

On 11.11.2010 21:15, Attila wrote:

At Donnerstag, 11. November 2010 20:16 Sven-Hendrik Haase wrote:

...

Sooooo, not a mail since a while. Can we replace dcron now? :) What i don't understand is this "replace" here because fcron (or incron) is only one "pacman -S" away. And i say this as an fcron user. :)

See you, Attila

The way I see it we at least shouldn't give/advise users to dcron as a default.

On Thu, 2010-11-11 at 16:31 -0500, Leonid Isaev wrote:

Not only this, but also the fact that now there are 2 crons being maintained: fcron in community and dcron in core. Removing dcron to, say, AUR, will be a wiser use of devs' time...

Bottom-posting please. And I don't see a problem with the current situation, one is in [core] the other in [community] (devs vs TUs). It could be reverse, if that's what's meant by 'replacing'. As a result of this thread I've switched to fcron as well. No big deal.

From my naive point of view, it seems like dcron is more in line with

Thanks to this thread I decided to look at both dcron and fcron. First google result for dcron led me to this: 1 Why use dcron when there's fcron? ----------------------------------- - dcron is SIMPLE: dcron just gives you two binaries, crond and crontab, and consists only of a few source files. - dcron is SMALL: binaries (i386-elf) are only about 25k - dcron is MATURE: it is many distributions' default cron and in use since ~1994. - dcron is SECURE: that's the consequence of being simple and mature. - dcron WORKS: fcron only worked for root on my box, no matter how hard I tried. This is from a Linux From Scratch readme here: http://www.linuxfromscratch.org/hints/downloads/files/dcron.txt the Arch Way. In response to the initial concern about a bug in dcron, don't we have anyone in our userbase that could take a look at the dcron code? As far as updates, I wouldn't expect a basic mature package to be updated more than once or twice a year. Update frequency alone says nothing about the quality of the code. My vote would be to focus efforts on fixing the bug and to keep Arch as small and lightweight as possible at its base. One of the best parts of Arch for me is that it starts out minimalistic and you can extend it to make it fit your needs. Trying to make our favorite packages defaults instead of minimal, stable, small packages, is a mistake imho. Cheers, Alex

On Fri, Nov 12, 2010 at 11:57, Loui Chang <louipc.ist@gmail.com> wrote:

The only problem is finding someone who can do the work to maintain dcron. It's pretty damning to have a scheduler that can't schedule properly installed by default - that's what people seem to be concerned about mostly. I'd like to keep the simpler package too, but if it ain't working chuck it.

I agree, however, it sounds a bit odd to say that we should replace a simple package with a more complicated one in the hope the more complicated one will screw us over less going forward. We're just as bound to the idiosyncrasies and bugs of fcron as dcron, but with the added complexity of fcron. For such a crucial system package it would seem wise to deal with the devil that's easier to understand (in theory, I don't claim to understand the internals of e. Also, looking over the comments in the bugtracker (https://bugs.archlinux.org/task/18681), it seems this may not even be a dcron issue. I would urge further consideration before making a switch. Cheers, Alex

Am Fri, 12 Nov 2010 13:10:12 +0900 schrieb Alex Matviychuk <alexmat@gmail.com>:

I agree, however, it sounds a bit odd to say that we should replace a simple package with a more complicated one in the hope the more complicated one will screw us over less going forward. We're just as bound to the idiosyncrasies and bugs of fcron as dcron, but with the added complexity of fcron.

I'm not really a cron expert, but fcron is not more complicated than dcron, it's just more feature-rich, more flexible, has more ways to configure, can be configured more precisely in my estimation. But fcron is as easy or hard to configure as dcron. It's fact that the fcron package is bigger than dcron but it has some more configuration files with which e.g. access privileges can be granted and a comprehensive documentation in plain text, HTML and several manpages. But this documentation can be very helpful for people who are not that familiar with cron daemons in general and fcron in particular. There's probably one thing that could be changed in the fcron package to reduce the size. The complete documentation is in English as well as in French. Nothing against France, but the French documentation could probably be removed from the package. All in all fcron looks a bit more mature in my view. Heiko

Surely someone can run a git bisect on this issue. It is a reasonably new occurrence. Or are we just going to switch software every time a bug is found... Allan

On Fri, 12 Nov 2010 20:19:18 +1000 Allan McRae <allan@archlinux.org> wrote:

Surely someone can run a git bisect on this issue. It is a reasonably new occurrence.

Or are we just going to switch software every time a bug is found...

I guess the issue is, that most people wanted fcron all along. Th last time this discussion came up, already many spoke out in favor of fcron. Then Jim put dcron on "life support" with an infusion from his own yacron software. This already means "our" dcron cannot be compared to other distributions' dcron anymore and the feature set is actually closer to fcron now than to the original dcron. (Gentoo still uses dcron 3.2 in stable for example.) I already used fcron on Gentoo years ago (Gentoo doesn't really have a default cron except if you count vixie-cron which is the only option for networkless installs) since I preferred the syntax and the way it separates root's crontab and the system crontab, but stayed with dcron on most of my arch boxes for convenience and lack of need for actually touching any crontab on them. FWIW I haven't seen the bug which started this discussion but that might be because i don't pay that much attention to most cron jobs. The ones I expect a daily mail from have correctly run once each day until now. -- Jinks

I wrote:

Except that the @daily bug only trigger every 24 hours or so. A little too time consuming for git bisect, i would say.

Or then, maybe not. Does the bug happen on a clean run (that is, when there is no timestamp)? in which case 'rm ${stampsdir}/*' before running crond and it should trigger instantly (or in the very first minutes of execution). Or does it only appear after several iterations? in which case the libfaketime trick can help. (also if it is a libc bug; libfaketime will hide it. but i don't think it's a libc bug anyway; it's unlikely that a libc bug in those areas would affect dcron *only*). -- Vincent Cappe

On 11/11/10 20:26, Alex Matviychuk wrote:

Thanks to this thread I decided to look at both dcron and fcron. First google result for dcron led me to this:

(As Loui noted, many of those points are changed by the passage of seven years. Distros probably use different crons now; and fcron has improved in the meantime; and dcron might have changed, I'm not sure.)

In response to the initial concern about a bug in dcron, don't we have anyone in our userbase that could take a look at the dcron code? As far as updates, I wouldn't expect a basic mature package to be updated more than once or twice a year. Update frequency alone says nothing about the quality of the code.

I dispute that something that doesn't always schedule jobs at the frequency the user requests (this user often being root) -- and that we as a community don't even understand when/why -- is secure. (It leaves me somewhat wondering about mature too, if no one's noticed (or fixed anyhow) this bug before. I wouldn't assume it's the only bug (although it might be).) -Isaac

I guess, the discussion is about including fcron into /core and on installation media. From this perspective, having two daemons might be a deal breaker. Leonid. On (11/07/10 21:09), Heiko Baums wrote: --> Am Sun, 7 Nov 2010 13:57:50 -0500 --> schrieb Kaiting Chen <kaitocracy@gmail.com>: --> --> > I think fcron is kind of heavy for most users. I'd rather we switch to --> > cronie, which is the descendent of vixie-cron. It's developed by --> > RedHat, well maintained, supports PAM and SELinux and can be built --> > with anacron features. --> --> I disagree with Kaiting, because cronie doesn't have anacron features. --> --> If it's compiled with --enable-anacron there is no anacron feature --> compiled into cronie. Instead there is a separate anacron daemon --> compiled and that makes it unnecessarily complicated in using and --> configuring it. And people who need anacron features have to run two --> daemons and configure two daemons. --> --> With fcron you have all in one and need to run and configure only one --> daemon. And fcron is by far not bloated and complicated to configure. --> Instead there are several ways to configure fcron like crontab, scripts --> in /etc/cron.{daily,weekly,monthly} and in /etc/cron.d. And to use --> anacron features you only need to prefix a crontab entry with an @. --> --> So I think fcron is much more flexible, much easier to configure and to --> use than cronie, and has features for rather every use case. --> --> And, please, don't make such a regression again. --> --> Btw., cronie is in AUR since May and still has only 1 vote while fcron --> is proven to run very well since years. --> --> Heiko -- lisaev@svibor