Re: rcrun(8), service(8) and future directions

2014-11-18 6:58 GMT+01:00 Matthew Dillon <[email protected]>:
> We have an experimental 'svc' program that utilizes the new procctl() system
> call to control and keep track of services.  start, stop, restart, etc.  It
> still needs significant work such as a configuration file or directory (say,
> /etc/services, with individual files) where services can be specified, and
> an ability to run different scripts as part of a stop or restart sequence.
>
> Ultimately the goal is to be able to configure jails with significant path
> and file writing restrictions, so the services can only read and write files
> that they actually need to read and write no matter what uid they are
> running as.  That will need some major kernel components and probably also a
> UI requester component.
>
> -Matt

Hi Matt,

It sounds really great. IMHO an interesting test case for such a tool
is haproxy because transparent reloading sequence  replaces the old
process(es) by new one(s) (see options -st/-sf in man page). It is
typically a situation that other tools like systemd or SMF cannot
handle properly without a  wrapper that acts as a _master process_
(spawn, wait, signal ...).


Cheers,
Joris

>
> On Mon, Nov 17, 2014 at 9:31 PM, Robin Hahling
> <[email protected]> wrote:
>>
>> I usually am present in the IRC channel (as Rolinh) but people sometimes
>> miss
>> things that are discussed there. I thought that discussing things on the
>> ML was
>> a good idea in this regard.
>>
>> In this case, I missed the parts you are mentioning. If the consensus is
>> that
>> the service(8) command could go, then I am in favor of removing it from
>> 4.0
>> release. I believe it was discreetly added in 3.8.2 release and has not
>> been
>> advertised a lot. Then, the sooner we remove it, the less we have chances
>> of
>> disrupting users habits.
>>
>> As for the missing features from rcrun(8) with regard to service(8),
>> having a
>> quick look at it I see:
>>
>>  * -e switch to list services that are enabled. rcrun(8) do have the
>> 'list'
>>    argument but it lists all services, whether they are enabled or not
>> only the
>>    ones that are enabled. This could be added easily.
>>  * -r switch, which is similar to 'rcrun list' but the output looks a bit
>>    different.
>>  * -R switch to restart all enabled local services.
>>
>> Is there something I am missing?
>>
>>
>> On Mon, 17 Nov 2014 16:15:25 -0700
>> "Samuel J. Greear" <[email protected]> wrote:
>>
>> > A discussion along these lines occurred recently on the DragonFly BSD
>> > developer IRC channel on EFNet, #dragonflybsd. The consensus was that
>> > the
>> > service command could go, and that rcrun could use some improvements,
>> > the
>> > service interface need not necessarily be maintained if rcrun can do all
>> > of
>> > the same things.
>> >
>> > You should pop into the IRC channel and continue this discussion, as
>> > well
>> > as taking into account any other input on this email list.
>> >
>> > Sam
>> >
>> > On Mon, Nov 17, 2014 at 3:11 PM, Robin Hahling <
>> > [email protected]> wrote:
>> >
>> > > service(8) was brought in past summer, from FreeBSD, as a way to
>> > > control
>> > > system
>> > > services, as an interface to rc.d system. Since version 1.0 (December
>> > > 2003
>> > > to
>> > > be exact), DragonFly has had rcrun(8) while service(8) was added to
>> > > FreeBSD in
>> > > December 2009.
>> > >
>> > > Having service(8) in DragonFly allow users or sysadmins to find their
>> > > way
>> > > around the system a but more quickly since service and its syntax is
>> > > used
>> > > in
>> > > popular systems such as FreeBSD or even Red Hat and other
>> > > distributions in
>> > > the
>> > > linux world. However, it would make sense to have service(8)
>> > > implemented
>> > > as a
>> > > wrapper around rcrun(8) and not a program in itself for obvious
>> > > reasons. I
>> > > volunteer for the task if people agree with this idea but really, it
>> > > should be
>> > > a no brainer.
>> > >
>> > > While on the subject, rcrun(8) syntax needs to evolve in order to be
>> > > able
>> > > to
>> > > pass arguments to rc scripts. Future bluetooth rc scripts will need it
>> > > for
>> > > instance. The current rcrun(8) syntax is the following:
>> > >
>> > >     rcrun command script [script2] [script3] ...
>> > >
>> > > where 'command' is one of 'disable', 'start', etc. This syntax allows
>> > > to
>> > > apply
>> > > the same operation to multiple rc scripts at once which is very handy
>> > > (at
>> > > least
>> > > to me). Also, this kind of syntax is similar to the one used in
>> > > systemd
>> > > with
>> > > the sysctl tool for instance. In this matter, service(8) syntax is
>> > > different:
>> > >
>> > >     service script command
>> > >
>> > > This syntax means that you cannot restart or do whatever command at
>> > > once
>> > > for
>> > > multiple scripts. On the other hand, if we had to add the possibility
>> > > to
>> > > add
>> > > arguments to the script this could be easily done this way:
>> > >
>> > >     service script command arg1 arg2 ...
>> > >
>> > > So I tried to think about a syntax for rcrun(8) that would allow it to
>> > > pass
>> > > arguments while still being able to apply a command to multiple
>> > > scripts at
>> > > once.  This is the idea that came to my mind: add a prefix to
>> > > arguments so
>> > > as
>> > > to differentiate arguments from scripts names. For instance:
>> > >
>> > >     rcrun command script1 :arg1 :arg2 script2 script3 :arg1 :arg2
>> > >
>> > > In this example, ":" is used as the arguments prefix.  I see several
>> > > advantages
>> > > to this syntax:
>> > >
>> > > * It is retro-compatible to current rcrun(8) syntax meaning that it
>> > > won't
>> > > break
>> > >   users's own scripts or workflow.
>> > > * It allies best of both worlds (service(8) and rcrun(8) current
>> > > syntax).
>> > > * It is easy to implement.
>> > >
>> > > If someone has an other/better idea, I would like to hear about it.
>> > > If, on
>> > > the
>> > > other hand it reaches a consensus, then I volunteer for this task too.
>> > > However, there are more things I would need to know about before
>> > > processing.
>> > > procctl(2) and some other features were added recently and I would
>> > > need to
>> > > know
>> > > where this is going and what changes it'll bring to rcrun(8) and all
>> > > of
>> > > what it
>> > > implies (parallel starting of services, and so on).
>> > >
>> > > Robin Hahling (Rolinh)
>> > >
>>
>>
>> --
>> Robin Hahling <[email protected]>
>
>