this post was submitted on 28 Aug 2023
24 points (100.0% liked)

Self Hosted - Self-hosting your services.

14706 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules

Important

Cross-posting

If you see a rule-breaker please DM the mods!

founded 4 years ago
MODERATORS
 

It is always a struggle configuring a cronjob to run certain scripts; there is always a mis configuration, a PATH, an environment variable that is different from when you use it in interactive mode, etc.. Do you have any tricks to avoid or minimize those issues?

cc @selfhost@lemmy.ml

all 7 comments
sorted by: hot top controversial new old
[–] skilltheamps@feddit.de 8 points 2 years ago

Use a systemd-service + systemd-timer. You can then run "systemctl start myjob.service" to check that it runs as you expect. If it works "systemctl enable --now myjob.timer" to kick it off as scheduled

[–] nitrolife@rekabu.ru 6 points 2 years ago

You can use crontab -e from user. That set user environment to usual state. Or you can use systems timers instead crontab.

Or you can set all environment variables inside cron file.

[–] johntash@eviltoast.org 2 points 2 years ago

Depending on what your setup is like, you could use something other than cron.

Kubernetes and Nomad both have cron-like schedulers. It's convenient to keep your cronjob definitions near the app code.

I've also been using windmill.dev lately for some simple cronjob-like tasks and it's working pretty great. It also has a UI if that helps.

[–] thisisawayoflife@lemmy.world 1 points 2 years ago

Wrap all the cron job tasks in a bash script and make sure it works. Call the script directly in the cron configuration. Dump the output of the cronjob to a logfile. Set it up to run every minute so you can ensure it works via the cron environment.

[–] lupec@lemm.ee 1 points 2 years ago* (last edited 2 years ago)

I basically combine a few mechanisms to mitigate that:

  • Having cron call scripts deployed to a fixed location I can manually test or use on demand as needed
  • Piping each script's output/exit code to healtchecks.io so I can get feedback notifications when/if they fail
  • Using Ansible to deploy everything so it's all repeatable and version controlled
[–] Coelacanthus@lemmy.kde.social 1 points 2 years ago

Always use absolute path. If you write some shell snippet which may be run in different environment, avoid use just command name for uncommon one.