Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro

[Rich Freeman]

On Thu, Feb 18, 2016 at 3:57 AM, Duncan <1i5t5.duncan@×××.net> wrote:
> Rich Freeman posted on Wed, 17 Feb 2016 08:46:34 -0500 as excerpted:
>
>> When systemd says "target" - think "virtual service."  The equivalent in
>> openrc would be an init.d script that has dependencies but which doesn't
>> actually launch any processes.
>>
>> Targets also take the place of runlevels in systemd.
>
> The systemd official comparison of targets is to runlevels, except much
> more flexible as it's actually possible for multiple targets to be in the
> process of being reached at once, not services or "virtual services", and
> indeed, my immediate internal reaction at seeing the "virtual services"
> definition was "no, they're like runlevels", before I even reached the
> next paragraph, where you add that.
>
> Basically, I'd put the runlevel comparison first and primary, as systemd
> documentation does, tho now that I've seen the usage, "virtual services"
> /does/ add some richness to the definition, helping to accent the fact
> that multiple targets can be processed at once.  So it's a difference in
> emphasis, while agreeing in general.

So, perhaps this is getting a bit off-topic, and a bit theoretical.

I've found that in general you aren't going to be effective with
systemd until you grok some of its basic concepts, and this is one of
them.  And, frankly, I've never found the "target = runlevel" analogy
very helpful when it comes to understanding just what systemd is
doing.

It is true that systemd uses targets to accomplish what other
solutions use runlevels for.  However, runlevels are used for things
that have nothing to do with traditional runlevels.

Here are a few cases where the runlevel analogy fails:

1.  In most service manager / rc implementations the system is at only
one runlevel at any time (of course it might be transitioning between
two).  In systemd targets can be started independent of the overall
"runlevel" and targets that are dependencies of the main runlevel can
be reached in parallel at any order semi-independently.

2.  Targets are used for many intermediate states that most sane rc
implementations would never make a separate runlevel, such as gettys
running, local filesystems mounted, remote filesystems mounted,
network interfaces exist, network is online, name resolution working,
swap running, etc.  These really don't work like runlevels, and there
is no strict sequential order that these get loaded in.

3.  Targets can be used for convenience just as virtual packages are
in most distros.  For example, I have an nfs-client target (which just
runs whatever daemons are needed to mount remote nfs shares).  While
upstream doesn't do it this way you could define a samba target that
starts both nmbd and smbd.  I use targets to group services that get
launched together by cron jobs, and so on.

4.  In the runlevel paradigm you usually think of services running
inside a runlevel (perhaps this isn't strictly true, but most people
think this way, in part because runlevels don't change much).  In
systemd this really isn't the case.  Services run before targets, or
after them.  A target won't be considered running if anything it
depends on isn't running.

5.  I'd have to check, but I wouldn't be surprised if systemd doesn't
actually require specifying a target at all.  Your default "runlevel"
could be apache2.service, which means the system would boot and launch
everything necessary to get apache working, and it probably wouldn't
even spawn a getty.  This is NOT analogous to just putting only
apache2 in /etc/runlevels/default, because in that example openrc is
running the default runlevel, and it only pulls in apache2.  Systemd
is purely dependency driven and when you tell it to make
graphical.target the default runlevel it is like running emerge
kde-meta.  If all you wanted was kde-runtime you wouldn't redefine
kde-meta to pull in only kde-runtime, you'd just run emerge
kde-runtime.  Again, I haven't tested this, but I'd be shocked if it
didn't work.  Of course, specifying a service as a default instead of
a target is very limiting, but it would probably work.  Heck, you
could probably specify a mount as the default and the system would
just boot and mount something and sit there.  Or you could make it a
socket and all it would do is sit and listen for a connection
inetd-style.


I find it more helpful to think of targets as just units that don't do
anything.  We don't use them in openrc but I suspect it would work out
of the box, and maybe we should even consider doing it in at least
some cases.  For example, right now /etc/init.d/samba uses some
scripting to launch both nmbd/smbd and fancy config file parsing to
let the users control which ones launch.  You could instead break that
into three files - smbd, nmbd, and samba.  The first two would launch
one daemon each, and the samba init.d script wouldn't actually launch
anything, but would just depend on the others.  That would be the
systemd target approach.

Apologies if this is a bit off-topic in an openrc discussion, but I
think the concept of virtual services is a potentially powerful one,
and I think that it might be something openrc would actually benefit
from using.

However, what I will say is until you actually appreciate that systemd
targets are just virtual units then you'll probably find the entire
systemd startup process to be an indecipherable mess.  Not groking
this stuff also makes it easy to incorrectly specify dependencies.
I'm sure a few of us running openrc over the years have accidentially
stuck a service in the wrong runlevel and had something break.  Well,
in systemd you might have 47 "runlevels" not actually starting in any
particular order so it is much easier to get it wrong if you don't
realize how they work.  They aren't strictly sequential, so there
isn't always one "runlevel" that always comes last that you can be
lazy and stick something "in."


-- 
Rich