Date: Wed, 16 Jul 2014 10:32:29 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: dteske@FreeBSD.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, 'Bryan Drewery' <bdrewery@FreeBSD.org> Subject: Re: svn commit: r268641 - head/usr.sbin/service Message-ID: <20140716083229.GA29849@dft-labs.eu> In-Reply-To: <014901cfa0a0$773c3640$65b4a2c0$@FreeBSD.org> References: <201407150218.s6F2Itj8044531@svn.freebsd.org> <53C56BE9.9050304@FreeBSD.org> <20140715191553.GA31990@dft-labs.eu> <014901cfa0a0$773c3640$65b4a2c0$@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 15, 2014 at 07:48:46PM -0700, dteske@FreeBSD.org wrote: > > -----Original Message----- > > From: owner-src-committers@freebsd.org [mailto:owner-src- > > committers@freebsd.org] On Behalf Of Mateusz Guzik > > Sent: Tuesday, July 15, 2014 12:16 PM > > > > Indeed, the whole point is to NOT inherit anything from calling process. > > > > If that were the point, then we have an issue. Because as it stands, > service(8) does _not_ accurately provide the same environment as boot. > > Take the following boot script: > > dteske@scribe9.vicor.com ~ $ cat /etc/rc.d/foo > #!/bin/sh > # PROVIDE: foo > set > /tmp/termtest > . /etc/rc.subr > name=foo > rcvar=foo_enable > command="/usr/local/bin/tmux" > foo_flags="new -s foo ls" > load_rc_config $name > run_rc_command "$1" > > Now reboot to find the following in /tmp/termtest: > [snip] > Compare that with the following: > > dteske@scribe9.vicor.com ~ $ sr service foo start > dteske@scribe9.vicor.com ~ $ cat /tmp/termtest > HOME=/ > IFS=' > ' > OPTIND=1 > PATH=/sbin:/bin:/usr/sbin:/usr/bin > PPID=1285 > PS1='# ' > PS2='> ' > PS4='+ ' > PWD=/ > > Looks to me like some things are being inherited. > Notably, it would appear that the rc.d scripts are > run within the parent namespace which has had > source_rc_confs() called (I'm leaving alone for the > moment that this indicates that each rc-script is > being less than efficient by re-sourcing rc.subr). > Well, let me be more specific: the point is to not inherit random stuff which happens to be in the environment so that it does not end up in an environment of the new process. With than in mind here is an environment from something which was executed, not rc.d script itself: HOME=/ IFS=' ' OPTIND=1 PATH=/sbin:/bin:/usr/sbin:/usr/bin PPID=802 PS1='# ' PS2='> ' PS4='+ ' PWD=/ RC_PID=18 Which pretty much matches 'service foo start' invocation by hand. Although RC_PID seems spurious. > Given the above (that we are farther from a "clean > environment" than one might expect), is it really > that big of a deal to expose $TERM? If so, what are > the serious issues that could arise? > > I personally cannot think of any shortcomings or > fallout from adding $TERM to be exposed. It does not make things work on boot, so you can expect people to complain about it. As was noted elsewhere, this is a change to the runtime which is not needed for most. In best case it is a noop, in worst it breaks things. It is best to not introduce differences when they are not needed It seems the easiest thing would be to have this whole business restricted to custom scripts dealing with tmux. Error message could be improved to note TERM was not set. Maybe a tmux-specific wrapper to run stuff detached should be added to the port? It would take care of settng TERM based on some config. Putting TERM for everyone just because the service happened to be start by hand does not look justifiable. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140716083229.GA29849>