[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
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=
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
[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
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 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
[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
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 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
[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
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 ". 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
