3 ms·

They didn't get rid of env vars, they got rid of env vars inherited from the shell you started services with. There were various solutions to this on SysVinit,

They didn't get rid of env vars, they got rid of env vars inherited from the shell you started services with. There were various solutions to this on SysVinit, stuff like https://cr.yp.to/daemontools/envdir.html https://cr.yp.to/daemontools/envdir.html

hulitu 5y ago
unset ? Inheriting env variables from the shell is a good idea ( or else you need all your dot files).
- GauntletWizard 5y ago
  Not when you're running system daemons, and those daemons respond differently when you invoke them with commonly different env vars, like LANG.
  - hulitu 5y ago
    Normally, system daemons are run by root. There is no reason to change the LANG env variable for system daemons.
    - db48x 5y ago
      You’ve missed the point. Back in the SysV days, you would log in to the system with SSH. You were logged in as hulitu, with all of your personalized environment variables, most of which were actually copied by ssh from your personal computer. This includes LANG and TERM and almost everything else (ssh has a blacklist, so it won’t copy SSH_AUTH_SOCK and PATH over). Then you would use `su` or `sudo` to become root so that you could do admin stuff on the machine. When you started a service by running `/etc/rc.d/init.d/foo`, it would inherit those things from your shell. Today that service is running with LANG=en_US, but then next week someone from the EU does an upgrade and suddenly it is running with LANG=fr_FR. Oops! The error messages are still in English because you never localized this daemon program, but now when it converts numbers into strings it uses the wrong thousands and decimal separators. I hope that isn’t breaking anything, or silently corrupting any data. This is a problem that systemd explicitly solves. All daemons launched by systemd are started in a fresh environment that inherits nothing from either the user who asked for it to be launched or from systemd itself.

hulitu 5y ago

unset ? Inheriting env variables from the shell is a good idea ( or else you need all your dot files).

GauntletWizard 5y ago
Not when you're running system daemons, and those daemons respond differently when you invoke them with commonly different env vars, like LANG.
- hulitu 5y ago
  Normally, system daemons are run by root. There is no reason to change the LANG env variable for system daemons.
  - db48x 5y ago
    You’ve missed the point. Back in the SysV days, you would log in to the system with SSH. You were logged in as hulitu, with all of your personalized environment variables, most of which were actually copied by ssh from your personal computer. This includes LANG and TERM and almost everything else (ssh has a blacklist, so it won’t copy SSH_AUTH_SOCK and PATH over). Then you would use `su` or `sudo` to become root so that you could do admin stuff on the machine. When you started a service by running `/etc/rc.d/init.d/foo`, it would inherit those things from your shell. Today that service is running with LANG=en_US, but then next week someone from the EU does an upgrade and suddenly it is running with LANG=fr_FR. Oops! The error messages are still in English because you never localized this daemon program, but now when it converts numbers into strings it uses the wrong thousands and decimal separators. I hope that isn’t breaking anything, or silently corrupting any data. This is a problem that systemd explicitly solves. All daemons launched by systemd are started in a fresh environment that inherits nothing from either the user who asked for it to be launched or from systemd itself.