From owner-svn-src-head@FreeBSD.ORG Wed Jul 16 08:32:37 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B5E797D; Wed, 16 Jul 2014 08:32:37 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D9BC2D6A; Wed, 16 Jul 2014 08:32:36 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so863375wiv.7 for ; Wed, 16 Jul 2014 01:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=N5HFBprS9ZCsQ+YliHItgwaRdZ39OaxYuXuX5JW9N0I=; b=f7nVmVEhsyyk0eGyOkcYcPWuIVeCjoo/xSQU+H5ynlk9dX671800zGSz0r9UHpDe/Z 9ewaUPeW6lUi738k2XoINZq/QmZ9wwztM7lEUZD940ZG8ltxOSuWiL19Tjaq5IGpqsKd qtvVbLrQ5/VU3QFc296ysrTgO4wbAP6Z4gjoYyzhDOL/chRKuxAfyZOSN3uWFn7YB+Fa chtVQF8hvl922cs1RWTc7nz7hcGMqhM1Jh5wBH73CDzho/At783Ex/iquGaaczGYnu0L 3KIubP2OqaqlR+HSg8g3Je1DVtP+D0Uor9z1TrgAhj9BOU3TeGpDyL7kC8Zh4epBR+0I olkA== X-Received: by 10.180.89.143 with SMTP id bo15mr11597886wib.78.1405499552201; Wed, 16 Jul 2014 01:32:32 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id sa4sm38206795wjb.45.2014.07.16.01.32.31 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 16 Jul 2014 01:32:31 -0700 (PDT) Date: Wed, 16 Jul 2014 10:32:29 +0200 From: Mateusz Guzik To: dteske@FreeBSD.org Subject: Re: svn commit: r268641 - head/usr.sbin/service Message-ID: <20140716083229.GA29849@dft-labs.eu> References: <201407150218.s6F2Itj8044531@svn.freebsd.org> <53C56BE9.9050304@FreeBSD.org> <20140715191553.GA31990@dft-labs.eu> <014901cfa0a0$773c3640$65b4a2c0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <014901cfa0a0$773c3640$65b4a2c0$@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, 'Bryan Drewery' X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 08:32:37 -0000 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