Re: svn commit: r200743 - in head/usr.sbin: . service

[Doug Barton]

I've reattached your original patch and included the freebsd-rc list.

Hajimu UMEMOTO wrote:
> Hi,
>
>>>>>> On Sat, 19 Dec 2009 21:51:13 -0800
>>>>>> Doug Barton <do...@FreeBSD.org> said:
>
> dougb> Other than the removal of "exit $?" I'm not necessarily opposed to
> dougb> that idea, but I'm wondering what value this change would have in the
> dougb> "system is already up and running" case (when it will be executed) vs.
> dougb> at boot time (such as in /etc/rc where the code is copied from).
>
> I don't just remove "exit $?". Since the script is kicked by "exec",
> the return value from the script is returned to the process which
> kicked service(8), directly.

Good point, I did not read your patch carefully enough, sorry.

> About the value this change, I think it should be same as the values
> at boot time. I cannot imagine that someone want to restart the
> system daemons under the user environment.

I can actually, especially for ports.

> Even if someone want to do
> so, he still can kick /etc/rc.d/foo, directly.

The point of adding a service(8) is to avoid needing to do that. :)

> Further, it seems service(8) does similar thing on CentOS.

I've already made one too-hasty comment on your suggestion, so I will
take a step back and let other's chime in.

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

[Hajimu UMEMOTO]

Hi,

>>>>> On Sat, 19 Dec 2009 23:30:41 -0800
>>>>> Doug Barton <do...@FreeBSD.org> said:

> About the value this change, I think it should be same as the values
> at boot time. I cannot imagine that someone want to restart the
> system daemons under the user environment.

dougb> I can actually, especially for ports.

Yup, I often do restart the services installed from ports, too.
I meant that I don't want that the values of user environment are
inherited to the services which is started from the user environment.

> Even if someone want to do
> so, he still can kick /etc/rc.d/foo, directly.

dougb> The point of adding a service(8) is to avoid needing to do that. :)

Yes, I hope so.:)
The merit of using service(8) should be that there are more additional
thing than just kicking /etc/rc.d/foo; don't inherit the values of
user environment, IMO.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

[Norikatsu Shigemura]

On Sun, 20 Dec 2009 18:31:56 +0900
Hajimu UMEMOTO <u...@freebsd.org> wrote:
> > About the value this change, I think it should be same as the values
> > at boot time. I cannot imagine that someone want to restart the
> > system daemons under the user environment.
> dougb> I can actually, especially for ports.
> Yup, I often do restart the services installed from ports, too.
> I meant that I don't want that the values of user environment are
> inherited to the services which is started from the user environment.

Yes, me too. I hope to restart daemons (installed from ports and/or
system) like 'on boot'.

> > Even if someone want to do
> > so, he still can kick /etc/rc.d/foo, directly.
> dougb> The point of adding a service(8) is to avoid needing to do that. :)
> Yes, I hope so.:)
> The merit of using service(8) should be that there are more additional
> thing than just kicking /etc/rc.d/foo; don't inherit the values of
> user environment, IMO.

I always kick like 'cd /; env - HOME=/ PATH=$PATH /etc/rc.d/foo'.
So I want service(8) like 'cd /; env - ...'.

Thank you.

[Kostik Belousov]

On Sun, Dec 20, 2009 at 06:31:56PM +0900, Hajimu UMEMOTO wrote:
> Hi,
>
> >>>>> On Sat, 19 Dec 2009 23:30:41 -0800
> >>>>> Doug Barton <do...@FreeBSD.org> said:
>
> > About the value this change, I think it should be same as the values
> > at boot time. I cannot imagine that someone want to restart the
> > system daemons under the user environment.
>
> dougb> I can actually, especially for ports.
>
> Yup, I often do restart the services installed from ports, too.
> I meant that I don't want that the values of user environment are
> inherited to the services which is started from the user environment.
>
> > Even if someone want to do
> > so, he still can kick /etc/rc.d/foo, directly.
>
> dougb> The point of adding a service(8) is to avoid needing to do that. :)
>
> Yes, I hope so.:)
> The merit of using service(8) should be that there are more additional
> thing than just kicking /etc/rc.d/foo; don't inherit the values of
> user environment, IMO.

I fully support this. I always have to do the env -u games with several
variables, LANG in particular.

[Jilles Tjoelker]

On Sat, Dec 19, 2009 at 11:30:41PM -0800, Doug Barton wrote:
> Index: usr.sbin/service/service.sh
> diff -u usr.sbin/service/service.sh.orig usr.sbin/service/service.sh
> --- usr.sbin/service/service.sh.orig 2009-12-20 13:14:14.000000000 +0900
> +++ usr.sbin/service/service.sh 2009-12-20 13:17:44.420246627 +0900
> @@ -106,11 +106,15 @@
> exit 1
> fi
>
> +HOME=/
> +PATH=/sbin:/bin:/usr/sbin:/usr/bin
> +export HOME PATH
> +cd $HOME
> +
> for dir in /etc/rc.d $local_startup; do
> if [ -x "$dir/$script" ]; then
> [ -n "$VERBOSE" ] && echo "$script is located in $dir"
> - $dir/$script $*
> - exit $?
> + exec env -i HOME=$HOME PATH=$PATH $dir/$script $*
> fi
> done

The $* should be changed to "$@" here, to avoid inappropriate IFS
splitting. (Even though rc.subr is broken in this way as well.)

By the way, I agree with adding this utility.

--
Jilles Tjoelker

[Brooks Davis]

On Sun, Dec 20, 2009 at 06:31:56PM +0900, Hajimu UMEMOTO wrote:

> Hi,
>
> >>>>> On Sat, 19 Dec 2009 23:30:41 -0800
> >>>>> Doug Barton <do...@FreeBSD.org> said:
>
> > About the value this change, I think it should be same as the values
> > at boot time. I cannot imagine that someone want to restart the
> > system daemons under the user environment.
>
> dougb> I can actually, especially for ports.
>
> Yup, I often do restart the services installed from ports, too.
> I meant that I don't want that the values of user environment are
> inherited to the services which is started from the user environment.

This is where the value of service(8) would lie for me. The ability
to not have things work by accident due to my environment and then break
at reboot would be be very helful.

-- Brooks

[Robert Watson]

On Sun, 20 Dec 2009, Brooks Davis wrote:

>>> About the value this change, I think it should be same as the values at
>>> boot time. I cannot imagine that someone want to restart the system
>>> daemons under the user environment.
>>
>> dougb> I can actually, especially for ports.
>>
>> Yup, I often do restart the services installed from ports, too. I meant
>> that I don't want that the values of user environment are inherited to the
>> services which is started from the user environment.
>
> This is where the value of service(8) would lie for me. The ability to not
> have things work by accident due to my environment and then break at reboot
> would be be very helful.

There are several other types of context we've historically not properly
set/restored when managing service state, such as:

- Full user credential context (user IDs, group IDs, etc)
- Additional login class state, such as resource limits and MAC labels
- User audit state

With Apple's launchd, service descriptions can include user credentials that
will be set before the service is started. Being able to do that here as well
would be great, especially in a future where part of our supplemental user
credential will be additional system privileges.

Robert N M Watson
Computer Laboratory
University of Cambridge

[Doug Barton]

Jilles Tjoelker wrote:
>> + exec env -i HOME=$HOME PATH=$PATH $dir/$script $*
>> fi
>> done
>
> The $* should be changed to "$@" here, to avoid inappropriate IFS
> splitting. (Even though rc.subr is broken in this way as well.)

In concept I agree with you, however I want to remain bug-compatible
with rc.subr, particularly in the light of the overwhelming response
to make service(8) work just like things do at boot time.

> By the way, I agree with adding this utility.

Thank you. :)

[Doug Barton]

Hajimu UMEMOTO wrote:
> Yup, I often do restart the services installed from ports, too.
> I meant that I don't want that the values of user environment are
> inherited to the services which is started from the user environment.

And I meant that I see the ability to start services AND inherit the
user environment as a feature, however the people have spoken! :)

I agree to making the change you suggested, but I would like to
quibble over the format. Isn't the attached patch equivalent, and
simpler? What is the value of setting HOME and PATH in the environment
if we're just going to use 'env -i HOME PATH' anyway?

[Doug Barton]

Robert Watson wrote:
> With Apple's launchd, service descriptions can include user credentials
> that will be set before the service is started. Being able to do that
> here as well would be great, especially in a future where part of our
> supplemental user credential will be additional system privileges.

I look forward to reviewing your patches to accomplish this. :)

[Hajimu UMEMOTO]

Hi,

>>>>> On Sun, 20 Dec 2009 12:10:55 -0800
>>>>> Doug Barton <do...@FreeBSD.org> said:

dougb> I agree to making the change you suggested, but I would like to
dougb> quibble over the format. Isn't the attached patch equivalent, and
dougb> simpler? What is the value of setting HOME and PATH in the environment
dougb> if we're just going to use 'env -i HOME PATH' anyway?

Yup, your attached patch is equivalent. However, I prefer the
previous one. In anyway, I don't have a strong opinion around here.

[Doug Barton]

Hajimu UMEMOTO wrote:
>>>>>> On Sun, 20 Dec 2009 12:10:55 -0800
>>>>>> Doug Barton <do...@FreeBSD.org> said:
>
> dougb> I agree to making the change you suggested, but I would like to
> dougb> quibble over the format. Isn't the attached patch equivalent, and
> dougb> simpler? What is the value of setting HOME and PATH in the environment
> dougb> if we're just going to use 'env -i HOME PATH' anyway?
>
> Yup, your attached patch is equivalent. However, I prefer the
> previous one. In anyway, I don't have a strong opinion around here.

Thanks for confirming. My preference generally is for things to be
simple and clear which makes them less confusing down the road.

I've committed the patch I posted. Thanks again to everyone who
offered their feedback. I'll wait a little longer before MFC'ing this,
but I do want to get it in ASAP.

[M. Warner Losh]

In message: <20091220183...@lor.one-eyed-alien.net>
Brooks Davis <bro...@FreeBSD.org> writes:

I'd love to have some way to say 'If the daemon dies, please restart
it. But don't be so eager about it that your attempts to keep it
running interfere with things like service'

Warner

[David Schultz]

The service management stuff introduced in Solaris 10 has this
capability, as well as some other nice bits of sophistication.
For instance, when a service is restarted, it will automatically
restart any services whose operation depends on that service.
Anyone working on services might want to peruse their svcs(1)
and smf(5) for ideas.

[Cyrille Lefevre]

Cyrille Lefevre a �crit :
> Doug Barton a �crit :

>> I agree to making the change you suggested, but I would like to
>> quibble over the format. Isn't the attached patch equivalent, and
>> simpler? What is the value of setting HOME and PATH in the environment
>> if we're just going to use 'env -i HOME PATH' anyway?
>

> how about to replace $* by "$@" in service.sh and to quote $dir/$script
> as well ?
>
> before :
> exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $*
>
> after :
> exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin "$dir/$script" "$@"

forgive me for the noise, don't see the message from "Jilles Tjoelker"...

Regards,

Cyrille Lefevre
--
mailto:Cyrille.Le...@laposte.net

[Cyrille Lefevre]

Doug Barton a �crit :

> I agree to making the change you suggested, but I would like to
> quibble over the format. Isn't the attached patch equivalent, and
> simpler? What is the value of setting HOME and PATH in the environment
> if we're just going to use 'env -i HOME PATH' anyway?

how about to replace $* by "$@" in service.sh and to quote $dir/$script
as well ?

before :
exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $*

after :
exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin "$dir/$script" "$@"

Regards,