← Back to context

Comment by jchw

2 hours 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.

> 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.

Odd. This script

  #!/bin/bash
  
  set > /tmp/set.txt

when scheduled like so

  * * * * * $HOME/bin/testCronScript.sh

Produces this file in /tmp/set.txt which has had a handful of values (HOME, UID, etc) lightly redacted prior to posting here, to remove PII or for length but its keys are entirely untouched:

  BASH=/bin/bash
  BASHOPTS=<redacted because long>
  BASH_ALIASES=()
  BASH_ARGC=()
  BASH_ARGV=()
  BASH_CMDS=()
  BASH_LINENO=([0]="0")
  BASH_LOADABLES_PATH=/usr/local/lib64/bash:/usr/lib64/bash
  BASH_SOURCE=([0]="/home/user/bin/testCronScript.sh")
  BASH_VERSINFO=<redacted bash 5.3.x>
  BASH_VERSION=<redacted bash 5.3.x>
  DIRSTACK=()
  EUID=13370
  GROUPS=()
  HOME=/home/user
  HOSTNAME=hostname
  HOSTTYPE=x86_64
  IFS=$' \t\n'
  LANG=en_US.utf8
  LOGNAME=user
  MACHTYPE=x86_64-pc-linux-gnu
  OPTERR=1
  OPTIND=1
  OSTYPE=linux-gnu
  PATH=/usr/bin:/bin:/usr/sbin:/sbin
  PPID=1337
  PS4='+ '
  PWD=/home/user
  SHELL=/bin/sh
  SHELLOPTS=braceexpand:hashall:interactive-comments
  SHLVL=1
  TERM=dumb
  UID=13370
  USER=user
  _=/home/user/bin/testCronScript.sh

Seems pretty clean to me. Even when I run this via /etc/crontab, rather than as a user cron job:

  * * * * * root /home/user/bin/testCronScript.sh

I get effectively the same results.

Maybe your distro's default cron environment was bad, and you never bothered to check and unset the badness? I'd be surprised if they were unable to make the default environment for Timer Units to be bad.