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