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

[C Anthony Risinger]

On Sat, Apr 28, 2012 at 7:16 PM, Kevin Chadwick <ma1l1ists at yahoo.co.uk> wrote:
> On Sat, 28 Apr 2012 16:05:54 -0500
> C Anthony Risinger wrote:
>
>> "bloat" is not measured by LOC, but rather by degrees of uselessness.
>
> I disagree here. If many don't use/need those features aside from an
> init system initialising things then it is bloat and will have bugs
> that will even affect simple firewall systems. Of course I'd use
> OpenBSD for a firewall but I know some build a highly stripped down
> Linux (kernel).

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.

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.

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.

> I hope there's no, well this is cool, and this bits wrong fundamentally
> but we and others have done so much work, lets just carry on. Windows
> registry springs to mind. Recent events like binary and random config
> file locations keep me wondering if the support companies so heavily
> involved in Linux have motives to make Linux harder to fix and
> customise. I like sed and diff, thankyou very much, I don't want to
> learn a thousand different config tools and formats ironically in the
> name of 'ease' or 'speed/compatibility' to shut many complainers up.

what binary configs? are you referencing?  in systemd's case anyway,
the unit files all look like simple key/value environment files, and
are easily parseable by anything.  my favorite in this arena is
augeas, because it takes any config file and makes it reliably
editable ... sed is nice and all, and i use it rather heavily for
daily tasks, but it's not suitable for editing other peoples stuff in
an automatic and predictable way.

personally, i'd like to see a configfs of sorts so i could edit all
configs from a single hierarchy (python + augeas + FUSE ... *hint
hint* ... someday :-)

> OpenBSD - hotplugd, sudo - nice and simple.
>
> Linux - udev, polkit and friends - what a mess, where shall I start. Oh
> the beginning, right I'll read this book and then I'll know where the
> beginning is, of course if somethings configured this then actually
> there's a new beginning.
>
> Sorry didn't mean to rant just saying what I see from over complex
> newness disregarding strong unix heritage like cross-distro things
> such as dconf and gconf bring.
>
> 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.
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 ... 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".

>> i have custom units managing daemons like this, timers syncing
>> archlinux mirrors, units modifying /sys/ tunables (there is no
>> `sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...
>>
>> ... and on servers especially, i even have units bound to ethernet
>> devices, automatically managing the interface, and/or starting dhcp!
>
> Could you be explicit in what you've gained. Maybe I'm ignorrant of the
> details but I see perhaps this functionality being more universal and
> that's it?

i just want things to happen at the right moments without worry, reuse
as much as possible, and not need to introduce additional requirements
... in the end i'm quite sure we have the same goals :-)

i know this isn't the final way i'll do it, but i currently use this
unit file on ~3 servers:

-----------------------------------
# Bindings to physical interfaces

[Unit]
Description=dynamic inet interface [phys:%I]
Wants=network.target
Before=network.target
BindTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
After=systemd-user-sessions.service rc-local.service

[Service]
Type=simple
TimeoutSec=0
Restart=always
RestartSec=10
EnvironmentFile=/etc/conf.d/dhcpcd
PIDFile=/run/dhcpcd-%I.pid
ExecStart=-/usr/sbin/dhcpcd $DHCPCD_ARGS %I
ExecStop=-/usr/sbin/dhcpcd --exit %I

[Install]
Alias=sys-subsystem-net-devices-eth0.device.wants/net-dyn-phys at eth0.service
-----------------------------------

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

... doing to same with an init script requires a much more work, a lot
more boilerplate code, and probably another process or two+.

-- 

C Anthony