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

[Robin Hahling]

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)