From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
Date: Fri, 19 Feb 2016 05:07:23 +0000 (UTC) [thread overview]
Message-ID: <pan$5c11e$fd53b9ce$9acfb524$bbf39a05@cox.net> (raw)
In-Reply-To: CAGfcS_nRsaZFMf9LGvTHrR80Ot7X0nYwp-Bta0683YvG0JV9RA@mail.gmail.com
Rich Freeman posted on Thu, 18 Feb 2016 07:22:36 -0500 as excerpted:
> 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.
Some minor additional notes, with the first one being here.
Systemd target units are analogous to edge-triggered interrupts, which
they resemble in that they are simply "synchronization points" (the term
used in the systemd.target (5) manpage itself). Level-triggered
interrupts can be held on or held off (high or low), but edge-triggered a
re simply events that occur and then are passed as time moves on. As
such, targets can be started, but not normally (while the job queue is
idle) stopped, as they de-assert as soon as they are actually reached,
tho many of their requirements generally continue to run until stopped by
some other event, often conflicts= against some other target or general
unit being started, or specific admin systemctl stop.
Tho the systemd FAQ suggests this wasn't always so, as it suggests using
systemctl list-units --type=target in answer to a question about how to
find what "runlevel" you're in. That command seems to return nothing,
here, tho, at least while no target is actively starting, so it would
seem that answer's a bit dated.
It can be noted, however, that certain units, most often specific targets
intended to be specifically invokable by users, can be "isolated", as
they have the AllowIsolate unit setting. Systemctl isolate <unit> will
then cause it to be started exclusively, stopping anything that's not a
dependency of that unit. The systemctl emergency, rescue, reboot,
shutdown, etc, commands, then become effectively shortcuts to the longer
systemctl isolate <named-target-unit> command form.
> 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.
As mentioned both in the systemd FAQ and in the systemd.special (7)
manpage, under default.target, this is the default unit started at
bootup. Normally, it'll be a symlink to either multi-user.target
(analogous to sysvinit semi-standard runlevel 3, CLI, no X), or
graphical.target (analogous to sysvinit semi-standard runlevel 5,
launching X and and a graphical *DM login).
I don't see specific documentation of whether symlinking to a non-target
unit is allowed, but systemd does have a commandline option --unit=,
which is explicitly documented to take a _unit_, default.target being the
default, but other non-target units being possible as well. Presumably
systemd would examine said unit, looking for DefaultDependencies=no, and
if not specifically set, would start the early "system level" targets,
before starting the named unit in place of the normal default.target.
So it's definitely possible to do via systemd commandline, but I'm not
sure if default.target is followed if it doesn't symlink a target unit,
or not. I'd guess yes, but have neither seen it specifically documented
nor tested it myself, nor read of anyone else actually testing it.
>
> 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.
It should work in openrc, yes, because not all functions need filled in.
It's quite possible to have openrc initscripts that have only a start or
a stop, not both, for instance, and I remember actually creating custom
initscripts of that nature, back when I was still on openrc. So without
/both/ start and stop, only dependencies, should work too, unless there's
a specific error check for that in openrc, and I can't see why there
would be.
> 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.
=:^)
It would certainly simplify things like the named chroot stuff, that
being what I'm familiar with from my openrc days, and from the sounds of
it based on other posts, apache, too, as you'd then have a virtual
service pulling in multiple modular dependencies, instead of a seriously
complex hairball of a single service trying to cram in all this
additional functionality that really should be in other modules, making
things less complex for both maintainers and admin-users.
> 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."
Umm... for anyone following systemd documentation, including most non-
early/late-system service units whether shipped by systemd itself or
other system service upstreams or distro maintainers...
multi-user.target is roughly equivalent to the standard sysvinit runlevel
3 (that being CLI operation and default system services).
graphical.target is roughly equivalent to the standard sysvinit runlevel
5 (that being X/XDM graphical login).
And graphical.target specifically Requires=multi-user.target, thereby
pulling in all its dependencies as well. So multi-user.target is the
standard "wanted-by/wants" single "runlevel analog" for CLI services and
where nearly everything that doesn't have specific reason to be somewhere
else ends up, if enabled.
But of course, that's not guaranteed, just documented default and the
standard nearly all shipped service units use, and individual distros/
sites/installations may well be setup entirely differently, if they have
specific reason for it.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2016-02-19 5:07 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 18:05 [gentoo-dev] rfc: Does OpenRC really need mount-ro William Hubbs
2016-02-16 18:22 ` Rich Freeman
2016-02-16 18:41 ` William Hubbs
2016-02-17 2:20 ` [gentoo-dev] " Duncan
2016-02-17 13:46 ` Rich Freeman
2016-02-18 8:57 ` Duncan
2016-02-18 12:22 ` Rich Freeman
2016-02-19 5:07 ` Duncan [this message]
2016-02-25 23:46 ` Raymond Jennings
2016-02-17 14:24 ` Richard Yao
2016-02-17 17:19 ` Rich Freeman
2016-02-17 17:30 ` James Le Cuirot
2016-02-17 18:06 ` Ian Stakenvicius
2016-02-17 18:32 ` Rich Freeman
2016-02-18 3:11 ` Richard Yao
2016-02-18 9:02 ` James Le Cuirot
2016-02-18 11:39 ` Rich Freeman
2016-02-17 21:50 ` Daniel Campbell
2016-02-18 3:02 ` Richard Yao
2016-02-18 10:48 ` Rich Freeman
2016-02-17 14:05 ` [gentoo-dev] " Richard Yao
2016-02-16 19:31 ` Patrick Lauer
2016-02-16 20:18 ` Rich Freeman
2016-02-17 14:06 ` Richard Yao
2016-02-17 19:01 ` Andrew Savchenko
2016-02-17 19:26 ` Rich Freeman
2016-02-18 3:26 ` Richard Yao
2016-02-18 7:53 ` Andrew Savchenko
2016-02-16 20:03 ` Daniel Campbell
2016-02-17 8:24 ` Luca Barbato
2016-02-17 14:00 ` Richard Yao
2016-02-18 7:02 ` Robin H. Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$5c11e$fd53b9ce$9acfb524$bbf39a05@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox