A nice story about Unix processes “infecting” each other | Hacker News Reader

A nice story about Unix processes “infecting” each other

rachelbythebay.com

39 pointspicture13 comments

Another great example of this is environment variables... The program which relied on user-specific TERM or LANG variable would work fine if started interactively, but would fail on machine reboot or if started over ssh non-interactively.

Those kinds of things bit me enough time I eagerly welcomed upstart and then systemd when they became the default.

How does upstart or systemd get rid of envvars? Seems to me they just added a bunch of new ones with awkward names. Try setting up wayland from scratch...

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

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

Not when you're running system daemons, and those daemons respond differently when you invoke them with commonly different env vars, like LANG.

Normally, system daemons are run by root. There is no reason to change the LANG env variable for system daemons.

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.

This is the first time I've seen positive comment about systemd. I have not messed with Linux init for a long time now, but is there someone who can concisely explain why systemd is hated by many?

I don't know if this is everyone's reasons but for me it is:

- it does too much. doesn't follow the Unix norms of doing one thing and doing it well. things like DNS resolution, time sync, etc all exist as systemd components.

- complexity - similar to doing too much but also just that it is no longer easily inspected and understood imo.

- participates in the Linux cycle of reinventing the wheel, excessively. Linux distros felt like they were changing their service management commands every other release for a while.

- breaks compatibility with BSDs.

I'm sure it solves real problems for real people.. but I don't like it.

All of these complaints correspond to deliberate tradeoffs, and while they are correct, the negatives are entirely kffset by the positives.

Doing too much? Well it does a lot, but it does it in one place instead of having each daemon or script do it in their own peculiar, non standard way.

Complexity? The configuration files are deterministic, regular, well documented. Contrast with init scripts.

Reinventing the wheel? Well the old wheel was not quite fit for purpose any more. Gradual evolution only gets you so far, sometimes you do need a clean break even though most clean breaks end up being a failure.

Compatibility with BSD? You may care, I just don't. Not saying it's wrong to care about it, but it's irrelevant for most users.

Also it's a big ball of coupled complexity, that quite possibly has subtle backdoors given the providence of how it was created.

That's one piece of code to audit, compared to 1000 of init scripts and daemons.

If you have the time for it, this might interest you then:

https://youtu.be/o_AIw9bGogo

Reply on news.ycombinator.com