[arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch

[C Anthony Risinger]

On Sat, Apr 28, 2012 at 11:51 PM, Patrick Lauer <patrick at gentoo.org> wrote:
> On 04/29/12 11:10, C Anthony Risinger wrote:
>>
>> perhaps it is a matter of taste, but i don't think the init system's
>> purpose is to simply "initialize" things.  it is a state manager, esp.
>> considering it has abilities no other process has.  i wish i could
>> find the link now, but i read an excerpt regarding the original design
>> philosophy of the init program ... and while it wasn't 100% straight
>> forward, the original goals heavily alluded that init was a
>> intelligent supervisor, and not nearly as dumb as we now know it.
>
> well, the sysvinit /sbin/init is very good at being PID 1 ... the state
> manager gets started and/or kept alive by it - and there's so little
> code involved that there are no surprises.
> The sysvinit code is so "boring" that there are still typos in the
> comments because not enough people even look at it to notice ...

yeah ... i'm a C novice, and i'm pretty sure i can write a stable init
... that's kinda the point.  init is so incredibly dumb that it
requires no code.  is that really what "unix philosophy" is meant to
convey?  so little code and functionality?

#include <stdio.h>
int main() {
    printf( "Hello Unix!\n" );
    return 0;
}

... done! and rock-solid stable! :-)

>> for LXC systems, i previously wrote an "init" in bash, that could
>> parse inittab, and respond to SIGPWR and SIGINT (powerfail and
>> crtlaltdelete in inittab), i probably 100 LOC of bash.  basic
>> functionality was implemented in far less ... what's the point?  now i
>> have to write everything in shell scripts for stuff that could
>> perfectly well be handled by the supervisor.
>
> acpid for SIGPWR, ca:12345:ctrlaltdel:/sbin/shutdown -r now for SIGINT,
> oh wait, my defaults already do that
>
> And I didn't have to write any code for that ...

traditional init will lock up the container because it thinks it must
reboot/shutdown the system.  there is absolutely no way to make it
kill itself, and end the container "normally".  it has to be kill
-9'ed from the outside.

... systemd on the other had, realizes it's running in a container,
and simply exit()'s.

>> i write a lot of shell code, and have literally read the bash man page
>> enough times to be able to jump to any point for reference ... shell
>> code is anything but secure and rather fragile.  it's just not meant
>> to do as much as we make it.  you are probably right about the
>> firewall case, maybe it wouldn't be needed.  but my guess is that you
>> could actually make the firewall much more fault tolerant and
>> intelligent by using such a powerful supervisor as systemd.  for the
>> most part though, most systems *do* require intricate and complex
>> relationships between services, and systemd fills that need
>> splendidly, *because* it does more that "fire and forget" [initialize]
>> processes.
>
> Worse than OpenRC, especially as it has insane nuggets like "WantedBy"
> (hello threaded Intercal!)
>
> In my opinion,  if I have to start hacking random C to add or adapt
> features (which happens as soon as the builtins do the wrong things -
> that's about twice a year for me) it'll be a lot more crashy than a
> simple shell script where I add one line of code.

well, i've used systemd for quite some time, and have never needed to
hack any C.  you can always ruin shellscripts from unit files if you
like, no one is preventing that.

the introspective and investigation tools in systemd are excellent and
unmatched by any other "alternative" i've encountered ... have you
actually tried it yet?  if i want to know what my systems is doing as
a whole, who better to ask that the ONE process capable of telling me?
 pid 1 can do stuff no other can ... why squander such powers?

> [snip]
>> Rather than some conspiracy I'd hope/expect it's simply that having
>> many many coders bring wanted features but also unstoppable misdirected
>> trains as there aren't enough top notch respected eyes to notice before
>> it's too late. Elephantitis.
>> i think systemd offers a nice way to not only start your processes,
>> but also maintian their relationship to the rest of the system.
>
> So the only weak argument in favour of systemd is dependency handling,
> which has been around for a decade. Oh, and if you have stateful init
> scripts (yeah, radical, I know) you can just check if all services you
> wanted to start are started and still alive. (running "rc-status" and
> "rc" with openrc does exactly that)
>
> No need for systemd at all :)

and doing that from a remote tool?  right ... run command XYZ over
ssh, parse for ABC, etc etc.  what about timed stuff?  what about
events/services that are not daemons?  i'm a developer; i want real
interfaces to use, with precise endpoints and clear methods.  dbus
does this nicely.  in time, i can query more and more over dbus.

when i have a hundred systems, i very much do not want to babysit
them.  systemd and the associated thought path really is a great step
forward.  yes shell is nice.  i write uber-tons of shell.  but the
unit files are clean, simple, consistent, and powerful.  read some of
the man pages ... tell me how to do all that with shell and/or OpenRC
alone, because people *want* this! else systemd would not exist, nor
have so much impetus.

>> traditional init systems work fine ... so long as everything works
>> correctly on first try.  if you want to have any kind of faul
>> tolerance, or even recovering from minor outages/hiccups, you suddenly
>> need all this extra infrastructure to watch pid files, watch
>> directories, watch watch watch ...
>
> that's why I offered OpenRC as an alternative - it does all those things
> while still being boring and manageable.

manageable?  any init system that claims to only be /sbin/init is
deluding itself.  "init" is all the rc scripts, the init app itself,
all the daemon rc scripts ... *everything*.  systemd will spew out a
graphviz chart if i want.  or let me start units one by one during
boot in an interactive way ... what can OpenRC do above-and-beyond,
for ME, the interrogator?

>>  while meanwhile, your init system
>> is standing in the corner picking it's nose, because it "did it's job
>> already" and all it needed to do was "start some stuff in the first 5
>> seconds".
>
> So fix your init system :)

luckily someone did it for me!

>> ... with just what you see above, and no modifications between
>> systems, i can run a dhcp service on any interface, whether it exists
>> or not, by only making a single symlink for each interface needed.
>> when a particular interface comes into being, dhcp will be started.
>> when the interface disappears, dhcp will be killed and the unit
>> "shutdown".  if dhcp dies but the interface still exists, it will be
>> restarted.  this unit activates the network.target, but guarantees
>> that all units depending on the network will wait until it's finished
>> before being started themselves.
>
> ln -s /etc/init.d/net.lo /etc/init.d/net.eth3; /etc/init.d/net.eth3
> start <-- there's eth3 running with dhcp
>
> And for the dynamic case where you don't know the device name ahead of
> time I'd suggest using NetworkManager - it's built to handle all that
> jazz. Oh, and if you have a sane init system it'll know in what state NM
> is and thus be able to delay starting services that rely on a network
> connection.

heyo!  networkmanager on a server is going to be an even tougher sell
than systemd.  in virtualized environments, hardware can be much more
dynamic than physical servers would experience ... but this was only
an example, and far more interesting examples exist on the
inter-tubes.

> Or, if you are really kinky, write udev rules to do such things. It's
> less code than the unit file ... and udev *is* the event handler for
> such things.

udev is meant to manage symlinks to stuff in dev, and trigger
short-lived apps to do similar book-keeping, not manage or kickoff
services.  in systemd's case, a single udev rule is used to tag
devices which are then exported and usable by unit files.

>> ... doing to same with an init script requires a much more work, a lot
>> more boilerplate code, and probably another process or two+.
>
> You could do it like that, yes ... but isn't that a bit overengineered?

how so?  what if dhcpcd has a bug, and spontaneously blows up?
systemd will catch the output, the exit code, and other infos, then
restart it for me.  when something does exactly what i need, in 10
lines of key/val declarations, that's more like precise engineering in
my book.

-- 

C Anthony