Providing a `service` scripts that speaks OpenRC and systemd

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Providing a `service` scripts that speaks OpenRC and systemd

Austin English-2
(Note: serious discussion, please take systemd trolling elsewhere).

While having the pleasure of working with some proprietary software
recently, I was asked to run `service foo restart`, and was surprised to
see:
foobar ~ # service foo restart
 * service: service `foo' does not exist

Since `systemctl restart foo` works, I had a workaround anyway.

Talking with Whubbs about it, I found that our service script only
supports OpenRC, via rc-service. I looked around, and from what I can
tell, most distros ship a service tool for all supported init systems. I.e.,
Debian/Ubuntu: supports sysvinit and systemd via init-system-helpers
CentOS/Fedora: provides support for systemd via initscripts
OpenSUSE: has a working service binary for systemd (according to #suse)

I'd like to propose moving `service` out of OpenRC and into a separate
package that OpenRC and systemd can both use. It's very possible that we
could simply package/use another distro's scripts (I haven't evaluated
that though).

--
-Austin

Austin English
Gentoo Developer
GPG: 00B3 2957 B94B F3E1


signature.asc (883 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Duncan-42
Austin English posted on Thu, 28 Sep 2017 16:27:31 -0500 as excerpted:

> (Note: serious discussion, please take systemd trolling elsewhere).
>
> While having the pleasure of working with some proprietary software
> recently, I was asked to run `service foo restart`, and was surprised to
> see:
> foobar ~ # service foo restart
>  * service: service `foo' does not exist
>
> Since `systemctl restart foo` works, I had a workaround anyway.
>
> Talking with Whubbs about it, I found that our service script only
> supports OpenRC, via rc-service. I looked around, and from what I can
> tell, most distros ship a service tool for all supported init systems.
> I.e.,
> Debian/Ubuntu: supports sysvinit and systemd via init-system-helpers
> CentOS/Fedora: provides support for systemd via initscripts
> OpenSUSE: has a working service binary for systemd (according to #suse)
>
> I'd like to propose moving `service` out of OpenRC and into a separate
> package that OpenRC and systemd can both use. It's very possible that we
> could simply package/use another distro's scripts (I haven't evaluated
> that though).

While I wouldn't oppose moving "service" into a separate package, I don't
see the need.

It's rather like instructions assuming you're running MS something or
other.  You simply translate them in your head to whatever's appropriate
for your system-administrative environment and go on.  If you're bothered
enough about it, when you're done, you open a support ticket with whoever
wrote the instructions and suggest that they don't assume what cannot be
taken as a safe assumption.  Otherwise, you just go on with your day.

While I can see users of some distros needing hand-holding in that
regard, Gentoo has always been about giving people the tools, documenting
how to use them, and getting out of the way -- if they can't read the
docs or choose to use the tools to bash their hand, or /accidentally/
bash their hand because they couldn't be bothered to read the docs and
either ran the tool without asking for confirmation (emerge without --ask
or --pretend, we don't make --ask the default and have a --justdoit
option, do you suggest we switch that around too?), or answered the
tool's prompt for confirmation with a go ahead, well, that's their
problem, and gentoo doesn't normally stand in the way of them bashing
their hand... or head or whatever else, if they wish to do so.

So I don't see the problem.  As a systemd user I know that services are
handled via systemctl, and would automatically translate an instruction
to run "service" accordingly, just as when I was an openrc user I was
aware that openrc didn't always function quite like other initsystems,
and would consider what I was doing before I blindly ran "service
<anything>".

Or are we going to replace rm, and fdisk, and gdisk, and cfdisk, and
cgdisk, and who knows how many other binaries, with "safe" alternatives,
because some gentooer couldn't be bothered to think for a moment whether
a command in some instructions they're following is actually appropriate
to the situation and the environment they're working in?

Meanwhile:

$ equery b service
 * Searching for service ...

$

But that's no problem, because as I said I'd automatically translate the
instructions into something appropriate to my environment.  (Indeed, were
there a separate package providing "service" that was for some reason a
dep, I'd strongly consider creating for myself an empty virtual to
provide it, just as I've done for a number of other packages that aren't
actually required to build or run the commands I /do/ want to run.)

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Harald Alfred Weiner
Duncan posted on 09/29/17 2:08 AM as excerpted:

> Or are we going to replace rm, and fdisk, and gdisk, and cfdisk, and
> cgdisk, and who knows how many other binaries, with "safe" alternatives,
> because some gentooer couldn't be bothered to think for a moment whether
> a command in some instructions they're following is actually appropriate
> to the situation and the environment they're working in?

Well, I think I understand what you want to say but actually your argument sounds a little bit strange.
Gentoo is about choice, right? So a Gentoo user has the ability to choose between
OpenRC or SystemD init systems (by the way, many thanks to the Gentoo developers
for making this possible). But some developer(s) might provide a package with a wrapper tool
so that instead of manual "translation" to your init system, you can just use type $ service <whatever> start
And some users might want to use this package. So I do not see the problem, as long as
nobody forces you to use the service tool. Actually, it adds a new choice for users: Either they use
the service-tool or they invoke their init system commands as they have always done.

Wouldn't a service-package be a little bit like sys-kernel/genkernel?
You may know from the docs that you can call make bzImage, make modules and so on.
Or you can (optionally) install sys-kernel/genkernel, configure it once and just call genkernel instead.
Nobody forces you to use genkernel and the linux kernel build is always transparent for anybody who
wants to use/look into it.


Best wishes,


Harald Weiner

Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Dale-46
In reply to this post by Austin English-2
Austin English wrote:
(Note: serious discussion, please take systemd trolling elsewhere).

While having the pleasure of working with some proprietary software
recently, I was asked to run `service foo restart`, and was surprised to
see:
foobar ~ # service foo restart
 * service: service `foo' does not exist

Since `systemctl restart foo` works, I had a workaround anyway.

Talking with Whubbs about it, I found that our service script only
supports OpenRC, via rc-service. I looked around, and from what I can
tell, most distros ship a service tool for all supported init systems. I.e.,
Debian/Ubuntu: supports sysvinit and systemd via init-system-helpers
CentOS/Fedora: provides support for systemd via initscripts
OpenSUSE: has a working service binary for systemd (according to #suse)

I'd like to propose moving `service` out of OpenRC and into a separate
package that OpenRC and systemd can both use. It's very possible that we
could simply package/use another distro's scripts (I haven't evaluated
that though).


I thought this was familiar.  This was discussed not long ago and as far as I can tell, nothing came of it. 

https://archives.gentoo.org/gentoo-dev/message/9bd54475fc23b9c265984c5a91129710 

Hope that link works, if not, this is the subject of the discussion. 

"[openrc] [systemd] make `service` common for both OpenRC and SystemD (like Debian/Ubuntu/whatever did)"

It has a few replies.

Dale

:-)  :-) 
Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Ulrich Mueller-2
In reply to this post by Austin English-2
>>>>> On Thu, 28 Sep 2017, Austin English wrote:

> Talking with Whubbs about it, I found that our service script only
> supports OpenRC, via rc-service. I looked around, and from what I
> can tell, most distros ship a service tool for all supported init
> systems. I.e., Debian/Ubuntu: supports sysvinit and systemd via
> init-system-helpers CentOS/Fedora: provides support for systemd via
> initscripts OpenSUSE: has a working service binary for systemd
> (according to #suse)

There is "eselect rc" which could be easily extended to support
systemd. Patches are welcome. :)

> I'd like to propose moving `service` out of OpenRC and into a
> separate package that OpenRC and systemd can both use. It's very
> possible that we could simply package/use another distro's scripts
> (I haven't evaluated that though).

Creating yet another tool for this makes absolutely no sense, IMHO.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Duncan-42
In reply to this post by Harald Alfred Weiner
Harald Weiner posted on Fri, 29 Sep 2017 04:47:35 +0200 as excerpted:

> Duncan posted on 09/29/17 2:08 AM  as excerpted:
>
>> Or are we going to replace rm, and fdisk, and gdisk, and cfdisk, and
>> cgdisk, and who knows how many other binaries, with "safe"
>> alternatives,
>> because some gentooer couldn't be bothered to think for a moment
>> whether a command in some instructions they're following is actually
>> appropriate to the situation and the environment they're working in?
>
> Well, I think I understand what you want to say but actually your
> argument sounds a little bit strange.
> Gentoo is about choice, right? So a Gentoo user has the ability to
> choose between OpenRC or SystemD init systems (by the way, many thanks
> to the Gentoo developers for making this possible). But some
> developer(s) might provide a package with a wrapper tool so that instead
> of manual "translation" to your init system, you can just use type $
> service <whatever> start And some users might want to use this package.
> So I do not see the problem, as long as nobody forces you to use the
> service tool. Actually, it adds a new choice for users: Either they use
> the service-tool or they invoke their init system commands as they have
> always done.

That's not far from what I said, I don't oppose a separate "service"
package, I simply don't see the need.

But a want isn't a need, which is where your "choice" argument comes in.
=:^)

As long as it doesn't get added to @system or become a hard dep (direct
or indirect) of something in @system, and preferably doesn't become a
hard dep of anything, tho a USE-controlled dep is fine.  Because that
would turn the choice argument on its head, which is what I'm afraid of.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Rich Freeman
In reply to this post by Ulrich Mueller-2
On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller <[hidden email]> wrote:

>>>>>> On Thu, 28 Sep 2017, Austin English wrote:
>
>> Talking with Whubbs about it, I found that our service script only
>> supports OpenRC, via rc-service. I looked around, and from what I
>> can tell, most distros ship a service tool for all supported init
>> systems. I.e., Debian/Ubuntu: supports sysvinit and systemd via
>> init-system-helpers CentOS/Fedora: provides support for systemd via
>> initscripts OpenSUSE: has a working service binary for systemd
>> (according to #suse)
>
> There is "eselect rc" which could be easily extended to support
> systemd. Patches are welcome. :)
>

++

Honestly, I could see the argument for having a generic "service"
command because that is what everybody else does, but there is little
point in arguing about the name of the file when nobody has bothered
to write it yet.

If somebody writes such a tool and it proves useful, we can always
have the discussion about refactoring.

To minimize list replies I'll tackle one of Duncan's points - he was
debating whether you really need this vs just using systemctl.  The
obvious use case is scripts that are intended to support multiple init
systems - it makes far more sense to put the logic to figure out which
one to run in one place than many.  If the runit users want to add
their own logic they could.  IMO it would be potentially useful, even
if you and I don't personally have much use for it.

That said, the sorts of people most likely to benefit probably don't
use Gentoo in the first place.

In any case, arguing over whether it is useful is putting the cart
before the horse.  It doesn't matter if it is useful if nobody bothers
to build it.  If nobody has that much of an itch to scratch then how
useful could it be?

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Daniel Campbell (zlg)
On 09/29/2017 04:53 AM, Rich Freeman wrote:

> On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller <[hidden email]> wrote:
>>>>>>> On Thu, 28 Sep 2017, Austin English wrote:
>>
>>> Talking with Whubbs about it, I found that our service script only
>>> supports OpenRC, via rc-service. I looked around, and from what I
>>> can tell, most distros ship a service tool for all supported init
>>> systems. I.e., Debian/Ubuntu: supports sysvinit and systemd via
>>> init-system-helpers CentOS/Fedora: provides support for systemd via
>>> initscripts OpenSUSE: has a working service binary for systemd
>>> (according to #suse)
>>
>> There is "eselect rc" which could be easily extended to support
>> systemd. Patches are welcome. :)
>>
>
> ++
>
> Honestly, I could see the argument for having a generic "service"
> command because that is what everybody else does, but there is little
> point in arguing about the name of the file when nobody has bothered
> to write it yet.
>
> If somebody writes such a tool and it proves useful, we can always
> have the discussion about refactoring.
>
> To minimize list replies I'll tackle one of Duncan's points - he was
> debating whether you really need this vs just using systemctl.  The
> obvious use case is scripts that are intended to support multiple init
> systems - it makes far more sense to put the logic to figure out which
> one to run in one place than many.  If the runit users want to add
> their own logic they could.  IMO it would be potentially useful, even
> if you and I don't personally have much use for it.
>
> That said, the sorts of people most likely to benefit probably don't
> use Gentoo in the first place.
>
> In any case, arguing over whether it is useful is putting the cart
> before the horse.  It doesn't matter if it is useful if nobody bothers
> to build it.  If nobody has that much of an itch to scratch then how
> useful could it be?
>
Great points. It'll be much easier to decide on something when/if there
is something concrete to work with. There isn't much stopping a package
from making it into Gentoo. If there is demand, it'll be written.

--
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Walter Dnes
In reply to this post by Austin English-2
On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote
> (Note: serious discussion, please take systemd trolling elsewhere).
>
> While having the pleasure of working with some proprietary software
> recently, I was asked to run `service foo restart`, and was surprised to
> see:
> foobar ~ # service foo restart
>  * service: service `foo' does not exist

  Ridiculous!  We need to develop one universal standard that covers
everyone's use cases.  https://xkcd.com/927/

  But if you insist, why not just set up a short bash script called
"service" rather than monkeying with every init system's internals?


#!/bin/bash
if [[ <condition_running_systemd> ]] ; then
   systemctl ${2} ${1}
elif [[ <condition_running_initrc> ]] ; then
   /etc/init.d/${1} ${2}
elif [[ <condition_running_some_other_init> ]] ; then
  <do whatever that init system requires>
else
   echo "ERROR: Unsupported init system; 'service' call failed"
fi


  This can handle a large number of different inits, with as many "elif"
lines as you care to add.  But, how do we reliably detect the currently
running init system?  Are there running processes, or entries in /sys/
or /proc/ or /dev that are unique to to each init system?

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Michał Górny-5
W dniu sob, 30.09.2017 o godzinie 00∶20 -0400, użytkownik Walter Dnes
napisał:

> On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote
> > (Note: serious discussion, please take systemd trolling elsewhere).
> >
> > While having the pleasure of working with some proprietary software
> > recently, I was asked to run `service foo restart`, and was surprised to
> > see:
> > foobar ~ # service foo restart
> >  * service: service `foo' does not exist
>
>   Ridiculous!  We need to develop one universal standard that covers
> everyone's use cases.  https://xkcd.com/927/
>
>   But if you insist, why not just set up a short bash script called
> "service" rather than monkeying with every init system's internals?
>
>
> #!/bin/bash
> if [[ <condition_running_systemd> ]] ; then
>    systemctl ${2} ${1}
> elif [[ <condition_running_initrc> ]] ; then
>    /etc/init.d/${1} ${2}
> elif [[ <condition_running_some_other_init> ]] ; then
>   <do whatever that init system requires>
> else
>    echo "ERROR: Unsupported init system; 'service' call failed"
> fi
>
>
>   This can handle a large number of different inits, with as many "elif"
> lines as you care to add.  But, how do we reliably detect the currently
> running init system?  Are there running processes, or entries in /sys/
> or /proc/ or /dev that are unique to to each init system?
>

You forgot the huge mapping between different service names. Then
complex mapping from services that are split/merged. Next we need a tool
that will update conf.d for OpenRC services which are split in systemd,
to allow people controlling them independently.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

James Le Cuirot
On 30 September 2017 08:19:36 BST, "Michał Górny" <[hidden email]> wrote:

>W dniu sob, 30.09.2017 o godzinie 00∶20 -0400, użytkownik Walter Dnes
>napisał:
>> On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote
>> > (Note: serious discussion, please take systemd trolling elsewhere).
>> >
>> > While having the pleasure of working with some proprietary software
>> > recently, I was asked to run `service foo restart`, and was
>surprised to
>> > see:
>> > foobar ~ # service foo restart
>> >  * service: service `foo' does not exist
>>
>>   Ridiculous!  We need to develop one universal standard that covers
>> everyone's use cases.  https://xkcd.com/927/
>>
>>   But if you insist, why not just set up a short bash script called
>> "service" rather than monkeying with every init system's internals?
>>
>>
>> #!/bin/bash
>> if [[ <condition_running_systemd> ]] ; then
>>    systemctl ${2} ${1}
>> elif [[ <condition_running_initrc> ]] ; then
>>    /etc/init.d/${1} ${2}
>> elif [[ <condition_running_some_other_init> ]] ; then
>>   <do whatever that init system requires>
>> else
>>    echo "ERROR: Unsupported init system; 'service' call failed"
>> fi
>>
>>
>>   This can handle a large number of different inits, with as many
>"elif"
>> lines as you care to add.  But, how do we reliably detect the
>currently
>> running init system?  Are there running processes, or entries in
>/sys/
>> or /proc/ or /dev that are unique to to each init system?
>>
>
>You forgot the huge mapping between different service names. Then
>complex mapping from services that are split/merged. Next we need a
>tool
>that will update conf.d for OpenRC services which are split in systemd,
>to allow people controlling them independently.

Names aren't consistent between Debian and Red Hat either so that isn't really an issue.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Duncan-42
In reply to this post by Walter Dnes
Walter Dnes posted on Sat, 30 Sep 2017 00:20:31 -0400 as excerpted:

> But, how do we reliably detect the currently running init system?  Are
> there running processes, or entries in /sys/ or /proc/ or /dev that are
> unique to to each init system?

In theory at least, that's easy enough, just check the kernel
commandline's (/proc/cmdline) init= if present, and fall back to matching
against the path (canonical, to take care of symlink-based init-
switching) of PID 1 if init= isn't present or points to the default
/sbin/init.

In practice I suspect one would need to arrange for each supported init
system to drop its own detection executable in place, making the script
something like this:

#!/bin/bash
initdetectpath=/lib/initdetect
if ${initdetectpath}/issystemd ; then
...
elif ${initdetectpath}/isopenrc ; then
...


But, once you're having the initsystems package their own detection
files, you might as well simply make them their own service scripts
designed to do the detection as well, returning a specified error code if
it's not that initsystem, making it as simple as:

#!/bin/bash
notme=<magicreturncode>

for $servicefile in /lib/initservicedir/* ; do
        $servicefile "$@"
        code=$?
        [[ $code = $notme ]] || break
done

[[ $code = $notme ]] && /
        echo "No supported initsystem claimed to be running" > /dev/stderr
exit $code


Then it's up to the initsys packagers whether they want to support the
scheme or not, what sort of detection they do if they support it, and how
they translate the passed parameters if necessary, and bugs in how they
do any of it become the bugs of that initsystem.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Rich Freeman
On Sat, Sep 30, 2017 at 5:32 PM, Duncan <[hidden email]> wrote:

> Walter Dnes posted on Sat, 30 Sep 2017 00:20:31 -0400 as excerpted:
>
>> But, how do we reliably detect the currently running init system?  Are
>> there running processes, or entries in /sys/ or /proc/ or /dev that are
>> unique to to each init system?
>
> In theory at least, that's easy enough, just check the kernel
> commandline's (/proc/cmdline) init= if present, and fall back to matching
> against the path (canonical, to take care of symlink-based init-
> switching) of PID 1 if init= isn't present or points to the default
> /sbin/init.
>

Using the command line would give the wrong answer inside a container,
as it would tell you what init the host is using, and not what init
the container is using (which is what you want if you're running in a
container that actually has a service manager running).

Also, starting/stopping services requires identifying the service
manager, not init.  You could be running sysvinit without running
openrc.  Sure, systemd is both an init and a service manager, but it
doesn't have to be that way.  I'm not sure what runit runs as PID 1.
Certainly distinguishing between the old baselayout-1 and openrc would
not be possible just by looking at PID 1.  Of course, assuming
sysvinit=openrc might be a reasonable interim design if somebody
doesn't suggest a better approach.

I suspect that inspecting /run might be your best bet here.  It seems
like the world would benefit from some kind of standard for service
managers to identify themselves when they're running.  In an ideal
world they might even expose an API of sorts via a set of scripts in
/run (likely symlinked).  That would also potentially eliminate the
need for a generic service script in the first place.

I point these out as issues to be resolved, not a reason to give up.
If somebody thinks a generic service script would be useful they
should write one.  The fact that it isn't trivial actually suggests
that a dedicated utility is the right solution vs just having
everybody embed their own logic in their own scripts, likely also not
thinking of the above issues.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

Tom H-4
In reply to this post by Walter Dnes
On Sat, Sep 30, 2017 at 12:20 AM, Walter Dnes <[hidden email]> wrote:
> On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote


>> While having the pleasure of working with some proprietary software
>> recently, I was asked to run `service foo restart`, and was surprised to
>> see:
>> foobar ~ # service foo restart
>>  * service: service `foo' does not exist
>
> Ridiculous!  We need to develop one universal standard that covers
> everyone's use cases.  https://xkcd.com/927/
>
> But if you insist, why not just set up a short bash script called
> "service" rather than monkeying with every init system's internals?
>
> #!/bin/bash
> if [[ <condition_running_systemd> ]] ; then
>    systemctl ${2} ${1}
> elif [[ <condition_running_initrc> ]] ; then
>    /etc/init.d/${1} ${2}
> elif [[ <condition_running_some_other_init> ]] ; then
>   <do whatever that init system requires>
> else
>    echo "ERROR: Unsupported init system; 'service' call failed"
> fi

With a "[ $# -eq 2 ]" test and with "env -i set_some_envvars
/etc/init.d/${1} ${2}" (and use "rc-service ${1} ${2}" instead of
"/etc/init.d/${1} ${2}")


> This can handle a large number of different inits, with as many "elif"
> lines as you care to add. But, how do we reliably detect the currently
> running init system? Are there running processes, or entries in /sys/
> or /proc/ or /dev that are unique to to each init system?

It's not init that you want to check, it's rc.

For openrc, "[ -d /run/openrc ]" should do the trick.

For systemd, the canonical way is "[ -d /run/systemd/system ]".

Reply | Threaded
Open this post in threaded view
|

Re: Providing a `service` scripts that speaks OpenRC and systemd

William Hubbs
In reply to this post by Austin English-2
On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote:
> (Note: serious discussion, please take systemd trolling elsewhere).
>
> While having the pleasure of working with some proprietary software
> recently, I was asked to run `service foo restart`, and was surprised to
> see:
> foobar ~ # service foo restart
>  * service: service `foo' does not exist
 
 You saw this because "service" is really rc-service. At some point in
 the past, I was asked to add the "service" command to OpenRC, and all
 it is is a synonym for rc-service.

> Since `systemctl restart foo` works, I had a workaround anyway.
>
> Talking with Whubbs about it, I found that our service script only
> supports OpenRC, via rc-service. I looked around, and from what I can
> tell, most distros ship a service tool for all supported init systems. I.e.,
> Debian/Ubuntu: supports sysvinit and systemd via init-system-helpers
> CentOS/Fedora: provides support for systemd via initscripts
> OpenSUSE: has a working service binary for systemd (according to #suse)
>
> I'd like to propose moving `service` out of OpenRC and into a separate
> package that OpenRC and systemd can both use. It's very possible that we
> could simply package/use another distro's scripts (I haven't evaluated
> that though).
I would support this. "service" should be a command, separate from any
service manager, that can be a wrapper for multiple service managers.

It isn't something that the service managers have to care about, it
would just be a convenience tool for users.

I can start setting up for this as soon as OpenRC 0.33 by removing the
service binary from OpenRC.

Thanks,

William


signature.asc (201 bytes) Download Attachment