Why use a 1 minute cron job to run the tasks, instead of a continuously-running queue worker (or several)?

▲ JdeBP 6 days ago | parent | next [-]

It's folk wisdom, generated by a long line of people who did not have proper dæmon management despite such tooling having been available since the 1990s. Any sort of service management, from running things once at bootstrap to having a long-running service, becomes hammered into the shape of a cron job.

There are loads of people over the years who have reached for cron instead of reaching for proper general-purpose dæmon management (SRC, SMF, daemontools, runit, daemontools-encore, perp, s6, ...). It is on Stack Exchange answers and in people's personal "How I did this" articles on WWW sites. (Although the idea goes back to the Usenet era.) It became one of those practices perpetuated because other people did it.

The next step is always discovering that cron's error handling and logging are aimed at an era when the system operator sat in the console room, and received "You have new mail" notifications at the console shell prompt.

And the step after that is (re-)discovering that the anacron approach does not fully cut the mustard. (-:

▲ slightwinder 5 days ago | parent | prev | next [-]

Single scripts are easier coded and can be more loosely, as you don't have to look out for sneaky memory-leaks and other problems which might emerge in long-running tasks. There is also no need to build and maintain a bespoke framework for managing your multiple jobs. This avoids mental debt for the devs. If you have many jobs, from multiple devs, it's the more pragmatic solution.

▲ o11c 6 days ago | parent | prev [-]

Back in the day, the reason I had 1-minute cron jobs (with flock of course) was because "what if the bespoke daemon gets killed somehow?" We also used screen/tmux a lot, but only for stuff that could afford to wait until somebody poked it (often, because if it repeatedly crashed the cause was likely novel and would need investigation).

Systemd has been a game-changer for small-scale deployments.

▲ pjmlp 6 days ago | parent | next [-]

Which is kind of ironic, given that systemd basically brings into Linux system services management from other UNIXes, Windows, mainframes and micros, but still gets plenty of hate.

▲ anitil 6 days ago | parent | prev | next [-]

> Systemd has been a game-changer for small-scale deployments.

Why is this? My only memory of systemd was slightly better configurations for sequencing the start of processes that depended on the completion of earlier processes so I'm a bit rusty.

	▲	SteveNuts 6 days ago \| parent [-]
		Systemd has timers now which have way better error handling.

▲ entropie 6 days ago | parent | prev [-]

> Systemd has been a game-changer for small-scale deployments.

The deep integration into nixos made me feel the same. You sound like you could enjoy a bit nix too.

▲ o11c 6 days ago | parent [-]

I dabbled a little with Nixos a while back (e.g. I think I reported the bug that broke the entire point of /etc/os-release for chroots, as well as commented on how to do a container install from scratch at a point when nobody documented it), but there were 3 things that really pushed me away:

  1. Nix has clear advantages for *deployment* (including end-user deployment) but really gets in the way for new *development*. Maybe flakes fix this? Maybe not though.
  2. The "Nix on other Linux" install scripts were hostile in attacking startup scripts, rather than allowing opt-in isolation.
  3. The Nix language (and library?) is not sane. Nobody actually understands it, only copy-pastes pieces of existing package scripts and hopes the changes work.

	▲	MadnessASAP 5 days ago \| parent [-]
		> 3. The Nix language (and library?) is not sane. Nobody actually understands it, only copy-pastes pieces of existing package scripts and hopes the changes work. Perhaps Nix is "Wonko the Sane" and it is in fact the rest of us who are in the asylum? Nix, the language, is a little strange at first but really does make sense. Nixpkgs, the "standard library", is a little stranger and sometimes makes an odd default choice. The nice thing though is that using Nix you can coerce Nixpkgs into just about any shape that suits you.