svn commit: r268641 - head/usr.sbin/service

Mateusz Guzik mjguzik at gmail.com
Wed Jul 16 08:32:37 UTC 2014


On Tue, Jul 15, 2014 at 07:48:46PM -0700, dteske at FreeBSD.org wrote:
> > -----Original Message-----
> > From: owner-src-committers at freebsd.org [mailto:owner-src-
> > committers at 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 at 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 at scribe9.vicor.com ~ $ sr service foo start
> dteske at 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>


More information about the svn-src-head mailing list