| 1 |
On Sat, Sep 30, 2017 at 5:32 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> Walter Dnes posted on Sat, 30 Sep 2017 00:20:31 -0400 as excerpted: |
| 3 |
> |
| 4 |
>> But, how do we reliably detect the currently running init system? Are |
| 5 |
>> there running processes, or entries in /sys/ or /proc/ or /dev that are |
| 6 |
>> unique to to each init system? |
| 7 |
> |
| 8 |
> In theory at least, that's easy enough, just check the kernel |
| 9 |
> commandline's (/proc/cmdline) init= if present, and fall back to matching |
| 10 |
> against the path (canonical, to take care of symlink-based init- |
| 11 |
> switching) of PID 1 if init= isn't present or points to the default |
| 12 |
> /sbin/init. |
| 13 |
> |
| 14 |
|
| 15 |
Using the command line would give the wrong answer inside a container, |
| 16 |
as it would tell you what init the host is using, and not what init |
| 17 |
the container is using (which is what you want if you're running in a |
| 18 |
container that actually has a service manager running). |
| 19 |
|
| 20 |
Also, starting/stopping services requires identifying the service |
| 21 |
manager, not init. You could be running sysvinit without running |
| 22 |
openrc. Sure, systemd is both an init and a service manager, but it |
| 23 |
doesn't have to be that way. I'm not sure what runit runs as PID 1. |
| 24 |
Certainly distinguishing between the old baselayout-1 and openrc would |
| 25 |
not be possible just by looking at PID 1. Of course, assuming |
| 26 |
sysvinit=openrc might be a reasonable interim design if somebody |
| 27 |
doesn't suggest a better approach. |
| 28 |
|
| 29 |
I suspect that inspecting /run might be your best bet here. It seems |
| 30 |
like the world would benefit from some kind of standard for service |
| 31 |
managers to identify themselves when they're running. In an ideal |
| 32 |
world they might even expose an API of sorts via a set of scripts in |
| 33 |
/run (likely symlinked). That would also potentially eliminate the |
| 34 |
need for a generic service script in the first place. |
| 35 |
|
| 36 |
I point these out as issues to be resolved, not a reason to give up. |
| 37 |
If somebody thinks a generic service script would be useful they |
| 38 |
should write one. The fact that it isn't trivial actually suggests |
| 39 |
that a dedicated utility is the right solution vs just having |
| 40 |
everybody embed their own logic in their own scripts, likely also not |
| 41 |
thinking of the above issues. |
| 42 |
|
| 43 |
-- |
| 44 |
Rich |
Archives