> That does require you to still know what the default environment is, but it is a mostly complet...

simoncion • yesterday at 4:24 PM • 1 reply • view on HN

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

Replies

jchw • today at 12:49 AM

Regardless of exactly how clean the environment is, my favorite part of systemd is the fact that there is only one regardless of how something was triggered. Whether a unit is triggered via a mount unit, timer unit, udev rule, it's the same units at the end, so it's the same environment.

The same problems that could be caused by a polluted environment in cron can be caused in reverse by a polluted environment elsewhere, when you unwittingly copy a command that depends on some environment being set. If you are using systemd as the service manager, this necessarily doesn't happen because it's all units. (Well, you could still copy something from outside of systemd and run into a similar problem, but at least there's essentially only one set of caveats you have to learn for whatever thing you want executed in the background.)

So I guess this isn't so much cron vs systemd timers, but more cron + other init and service supervisors vs systemd init in general.

➕ show 1 reply

alt Hacker News

Replies