From: Raymond Jennings <shentino@gmail.com>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
Date: Thu, 25 Feb 2016 15:46:22 -0800 [thread overview]
Message-ID: <CAGDaZ_rK+TBiQ7q6reEGTmM9Ay9y4q=5jqVvMruMZXhKSUEKng@mail.gmail.com> (raw)
In-Reply-To: <pan$5c11e$fd53b9ce$9acfb524$bbf39a05@cox.net>
[-- Attachment #1: Type: text/plain, Size: 8517 bytes --]
I think this might be one reason that /etc/mtab was deprecated in favor of
a symlink to /proc/mounts :P
On Thu, Feb 18, 2016 at 9:07 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> 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
>
>
>
[-- Attachment #2: Type: text/html, Size: 9898 bytes --]
next prev parent reply other threads:[~2016-02-25 23:47 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
2016-02-25 23:46 ` Raymond Jennings [this message]
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='CAGDaZ_rK+TBiQ7q6reEGTmM9Ay9y4q=5jqVvMruMZXhKSUEKng@mail.gmail.com' \
--to=shentino@gmail.com \
--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