[gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[Austin English]

[-- Attachment #1.1: Type: text/plain, Size: 1099 bytes --]

(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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 866 bytes --]

[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd

[Duncan]

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

[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd

[Harald Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 1605 bytes --]

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




[-- Attachment #1.2: HTML --]
[-- Type: text/html, Size: 2186 bytes --]

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

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

:-)  :-)  *
*

[-- Attachment #2: Type: text/html, Size: 2055 bytes --]

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd

[Duncan]

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

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[Rich Freeman]

On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller <ulm@gentoo.org> 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

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2339 bytes --]

On 09/29/2017 04:53 AM, Rich Freeman wrote:
> On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller <ulm@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[Walter Dnes]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[Michał Górny]

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

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[James Le Cuirot]

On 30 September 2017 08:19:36 BST, "Michał Górny" <mgorny@gentoo.org> 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.

[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd

[Duncan]

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

Re: [gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd

[Rich Freeman]

On Sat, Sep 30, 2017 at 5:32 PM, Duncan <1i5t5.duncan@cox.net> 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

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[Tom H]

On Sat, Sep 30, 2017 at 12:20 AM, Walter Dnes <waltdnes@waltdnes.org> 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 ]".

Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]