Comment by thomashabets2

2 hours ago

I haven't used systemd timers enough to disagree, but

> Ambiguous $PATH settings make cron script execution difficult to predict.

What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else?

> You might feel cool knowing the scheduling grammar by heart

I've used Linux since 1994 and I don't know it by heart. But luckily it's pre-printed in the crontab as comments:

    # For more information see the manual pages of crontab(5) and cron(8)
    # 
    # m h  dom mon dow   command

You just put numbers aligned with the titles.

The rest of the complaints, sure. Next time I need a cronjob, I'll try it out.

8 comments

thomashabets2

Reply
jerf  1 hour ago

"You just put numbers aligned with the titles."

That is not a fair summarization of their point because that is not the grammar. There's commas, slashes, asterisks, combinations, and then if you want randomization you need to put it in the command itself because cron can't do it. (Some crons can, but it's not a general capability of cron.) Writing a non-trivial cron spec is not easy.

  • eqvinox  25 minutes ago

    How do you express those things in a systemd timer? E.g. run something 4x per day, */6 in cron.

egorfine  14 minutes ago

> I've used Linux since 1994

Same here.

We are now considered old and therefore irrelevant. The new generation uses timers and couldn't care less about cron that has served us just fine for decades.

I use cron and my general attitude towards LP and systemd is very similar to the attitude of LP and systemd to us.

jeroenhd  41 minutes ago

Having had to work on an application supposedly supporting cron expressions: the numbers are just the basic parts of the language.

When someone inputs something ridiculous like "5,3/4 4-8,11 1 4,5,6,9-11 */2" you get to enjoy the fun of reverse engineering what they meant (it's never what they actually wrote).

And that's before you get to all the extensions supported in some cron environments (but not all).

I find systemd timers a lot more manageable. Things like having control over whether or not long-running jobs are allowed to overlap and the ability to run tasks between start-finish rather than a fixed time window are major improvements for me. At some point my VPS went down because the backup job ran into some kind of symlink loop and cron just kept spawning more and more backup tasks even though none of them finished.

Having to re-write commands and scripts because CRON had its own special PATH was also a pain point, but the same can be true for some types of systemd timers. But: you can execute those timers manually if you want instead of updating the crontab to trigger in 30 seconds and simply waiting.

  • networked  21 minutes ago

    Complex expressions are one of the things I don't like about cron. In my personal job scheduler, intended more for my machine than for anyone or anything else, I have adopted Starlark functions instead. For example:

      # Run if at least a day has passed since the last run
  # and it isn't the weekend.
  def should_run(finished, timestamp, dow, **_):
      return dow not in [0, 6] and timestamp - finished >= one_day

    This was inspired by GNU mcron. In mcron, jobs can calculate the next time they should run using Guile (https://www.gnu.org/software/mcron/manual/mcron.html#Guile-S...):

      (job
     '(next-minute-from
        (next-hour (range 0 24 2))
        '(15))
     "my-program")

    I found mcron underdocumented and its scheduling counterintuitive, though, and decided I wanted a function that returned a boolean.

  • ink_13  32 minutes ago

    > 5,3/4 4-8,11 1 4,5,6,9-11 */2

    What's so hard about "At 5 minutes past the hour and every 4 minutes, starting at 3 minutes past the hour, at 04:00 AM through 08:59 AM and 11:00 AM, on day 1 of the month, every 2 days of the week, only in April, May, June, and September through November"?

    (I used https://crontab.cronhub.io/ to decode it, to be fair)

jchw  1 hour ago

The main nice thing about the environment in systemd is that it is standard and mostly a blank slate, whereas at least for me I was always getting bit by the fact that the environment in Crontab was completely different from say, the environment inherited by supervisord or sysvinit scripts. In systemd the actual unit that gets executed is the same regardless of what triggers it, so there is no gap.

That does require you to still know what the default environment is, but it is a mostly completely clean environment, without any influence from any shell.

I'd have to concur that I agree this is an advantage of systemd.