On Wed, Jan 30, 2019 at 08:48:34PM +0000, Dmitry Bogatov wrote:
> > > What is so bad about cluttering environment of daemon?
> >
> > Normally you'd want to avoid passing unnecessary environment variables to
> > daemons. Maybe they'll affect its operation in some way; maybe they'll
> > affect a child process of the daemon that inherits them. It's relying on
> > undefined behaviour.
>
> I do not buy this argument. For ages we started daemons with
> /etc/init.d/{foo} scripts from root shell (and even with sudo), with all
> kind of environment variables, including rather nasty ones, like GREP or
> LESS, and we are still fine.
No we're not. :) Leaking shell envvars (stuff like LC_* and LD_* especially)
into daemon environments is one of the reasons initscripts are a bad idea.
Daemons should be called with a minimal required set of environment
variables.
> But probably executing services with `env -0' is good idea, thank you.
'env -0' will just modify the regular output of env(1), and will have no
effect if you use env to call a program; are you sure that's what you meant?
> > > > (But then /etc/default/foo would have to take precedence over
> > > > sv/foo/conf,
> > > > because the /etc/default/foo variables would be lost during the exec
> > > > since
> > > > we want to avoid exporting them.)
> > >
> > > This too. I want daemontools-style take precedence over sysvinit style.
> >
> > FWIW, I think the whole thing is creeping featurism,
>
> One extra source of variables, implemented with 3 lines of shell? Well,
> your definition of 'featurism' is much stricter then mine.
I meant the entire shebang of having a funky shellscript as an interpreter
for 'run' scripts just so we can avoid 3 lines of shell code in each to set
environment variables is creeping featurism. The idea is original and
certainly has hack value; but I think the benefits don't warrant the added
complexity/abstraction.
However, since using it is entirely optional, it's probably not worth
arguing over; I write most of my run scripts in zsh anyway, so I won't even
be tempted to use the new interpreter.
> > > And what if there were no tty on installation time, and after that they
> > > appeared? (No idea, why, never dealt with devices without tty.)
> >
> > That's a pathological hypothetical case; I'd say we wait until it happens,
> > and then deal with it. (You might also ask: what about hypothetical systems
> > where /dev/tty* devices keep disappearing and reappearing in a rhythm that
> > always prevents getty from starting?)
>
> Okay. I buy it. I will unconditionally include this code:
>
> if ! test -c /dev/@TTY@ ; then
> rm /etc/service/getty-@TTY@
> exit 0
> fi
>
> and upload to experimental. Should there be no report of that
> pathological case, I will merge these changes into unstable after
> Buster. Will it do for you?
Most of the time, yes, thank you. (It won't work when the service directory
isn't /etc/service, but that's rare.)
András
--
"Meow" ...splat... "Aarf" ...splat... (raining cats and dogs)
