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

Hi,

On Tuesday 18 November 2014 20.51:33 Franco Fichtner wrote:
> Hi,
> 
> On 18 Nov 2014, at 17:55, Freddie Cash <[email protected]> wrote:
> > On Mon, Nov 17, 2014 at 10:46 PM, Francois Tigeot <[email protected]>
> > wrote:> 
> > On Tue, Nov 18, 2014 at 06:31:35AM +0100, Robin Hahling wrote:
> > > 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.
> > 
> > service(8) is a standard command present on many recent Linux
> > distributions
> > as well as FreeBSD.
> > Sysadmins expect it to be there and it should stay IMNSHO.
> > 
> > ​Seems overly redundant to have two separate utilities that do the same
> > thing in just slightly different ways.  Perhaps writing a stub service(8)
> > command that simply outputs a message about rcrun(8) would be a better
> > use of limited developer resources?
> I did the import.  Here are some simple facts.
> 
> 1. It took a minute to import.
> 2. It works.

About this, I'd say that it only partially works in its current state. For 
instance, service.sh requires "find_local_scripts_new" which is defined in 
etc/rc.subr in FreeBSD but is not defined in DragonFly. Hence, 'service -R' 
(to restart all enabled local services) does not work. Other example: 'service 
-e' shall list all enabled services. It seems to work but some things shall 
have been cleaned up. Like the sysctl call security.jail.jailed which does not 
exist on DragonFly (and thus service shows an error message).  service also 
outputs error messages on '-eq' comparison, which is used throughout the 
script. service foo start|restart|... works but that is about the only thing 
that does not fail, warn or partially work in my experience.

> 3. FreeBSD maintains it, if it needs maintenance at all.

Yes but some things need to be adjusted on DragonFly as well. See my point 
above. It probably is no big deal but it has to be dealt with at least once.

> 4. It provides a known interface to novice DF users.

... coming from FreeBSD or linux distributions that still use service (which 
is not many Today and this number is decreasing drastically).
But fair enough, if no maintenance is required once the current problems have 
been addressed, why not?

> 5. Revert takes 10 seconds.
> 
> My questions are:
> 
> 1. Is it worth arguing about different choice of tools?

I started this thread not to argue about different choice of tools but rather 
to get opinion on a proposed syntax update for rcrun as to allow passing 
arguments to script, which is something that is required now (for the future 
bluetooth module at least). But then, this means that if either rcrun or 
service can by used to control system services, service has to be able to 
allow passing arguments to rc scripts as well and hence has to be adapted.

> 2.1. Is it worth making DF migration harder for interested parties?

IMHO, it does not take long to learn how rcrun(8) works as it is not /that/ 
different from service(8) in the end. I do not think that not having 
service(8) makes migration harder for people coming from other OSs. It does 
not take long to read rcrun(8) man page and understand how it works since the 
tool is pretty simple. It does break people's habits if they are used to using 
service(8), I grant you that.

> 2.2. Can we even afford to be harder to migrate to?
> 2.3. Are we even interested in a wider recognition of DF?

These points are not very constructive so I would rather not answer to them.

> 3. Is it worth to have a complicated discussion for a tiny tool?

As I stated above, the whole point of the discussion was about a proposition 
for a new syntax to allow passing arguments to rc scripts. But as we do have 
two tools to manage them now, both have to be considered.

Robin

> 
> Feel free to discuss this further.  ;)
> 
> 
> Cheers,
> Franco