From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B09021388C0 for ; Thu, 25 Feb 2016 23:47:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0E40921C054; Thu, 25 Feb 2016 23:47:04 +0000 (UTC) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0166021C007 for ; Thu, 25 Feb 2016 23:47:02 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id dm2so63399615obb.2 for ; Thu, 25 Feb 2016 15:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=A0LGM6PhY5c8FmQ0NkxWQ4XFoQpWw6FC3Kpjhlq7YLA=; b=PFlqletrkcl+SxwpxApIigNNHCFfbmhbLxcwpuYRFEgZ6W1yAa0TsrxwROXcm8oYjX kLcq70GWbIu89EpzXEw8xZrKxlYD/eWGWmJle6K0pksSd74n9mt3Yjjp/iETVbZWeR8e rGhc7wPvDN48zmLVU7PyEaclY6VW4+OQQRe3wCCeX03mi7Lo2f+vYxgxdoowiUUwfWG/ tGRwxxB/tOQNn6eRAY8cYTQNL17EZ6rbWpvOXoOvZ+Z6YH3RB+kGLAawNvN8CYaLjmkf vDSyUzLLKTexS25GzVOFYH3OafuDe/+pvWS5aImRN3JIMB0uWcnxNYuEBH9CrlcADZbJ OE1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=A0LGM6PhY5c8FmQ0NkxWQ4XFoQpWw6FC3Kpjhlq7YLA=; b=SCuK1NHJz2uzM9h9BbJuUFqdSeZXT8ljHOdbt8HyFJB30HedEaAbFxVDB6nhrwg2I5 q3NiJUaq+furT8xRiStzzAg7jxfewj7dA7J6EY7SvHXfnWl51xIy0ozD6lPBqMjmbG4R oOnG3ifkNoVrGBDlIH62wPKvnuAAcNMTasx0eF44RKnIR6M+PJxbgjM/cOf/OjBR9UHw szIbYQyE6BlbKg5r1fxXBbTtqh+AgavCz4eYh/c16AyE9JVf3OQqwlpxjOuXu/5+bdFn 44GXRpQOLZU1Y7y2M0mTbNVf9CtaVQwrwq1TkPiL0I2XpMhihT+4a9BKqWXwxoG1AZgr eJ8A== X-Gm-Message-State: AG10YOQ2PdFCA2tMu9inpSMHYIUYBFmryexF8+y7DgTFqB6NeaDf+AahrqujrCZR0IVRDOdoSNdGtJje1JsQ9w== X-Received: by 10.182.196.104 with SMTP id il8mr39344566obc.71.1456444022179; Thu, 25 Feb 2016 15:47:02 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.202.207.69 with HTTP; Thu, 25 Feb 2016 15:46:22 -0800 (PST) In-Reply-To: References: <20160216180533.GB1450@whubbs1.gaikai.biz> <20160216184129.GB1704@whubbs1.gaikai.biz> From: Raymond Jennings Date: Thu, 25 Feb 2016 15:46:22 -0800 Message-ID: Subject: Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro To: gentoo-dev Content-Type: multipart/alternative; boundary=089e0149c63693cdf3052ca0cc86 X-Archives-Salt: bceb2284-ec13-49f5-91b9-2a7095a1a675 X-Archives-Hash: 110da8f0861b6fc3a7853672a63b0e71 --089e0149c63693cdf3052ca0cc86 Content-Type: text/plain; charset=UTF-8 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 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 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 > > > --089e0149c63693cdf3052ca0cc86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this might be one reason that /etc/mtab was deprec= ated in favor of a symlink to /proc/mounts :P

On Thu, Feb 18, 2016 at 9:07 PM, Dunc= an <1i5t5.duncan@cox.net> wrote:
Rich Freeman posted on Thu, 18 Feb 2016 07:22:36 -0500 as excerpt= ed:

> 4.=C2=A0 In the runlevel paradigm you usually think of services runnin= g
> inside a runlevel (perhaps this isn't strictly true, but most peop= le
> think this way, in part because runlevels don't change much).=C2= =A0 In
> systemd this really isn't the case.=C2=A0 Services run before targ= ets, or
> after them.=C2=A0 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" (t= he term
used in the systemd.target (5) manpage itself).=C2=A0 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.=C2=A0 As<= br> 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=3D 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 usin= g
systemctl list-units --type=3Dtarget in answer to a question about how to find what "runlevel" you're in.=C2=A0 That command seems to r= eturn 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.=C2=A0 Systemctl isolate <unit&g= t; will
then cause it to be started exclusively, stopping anything that's not a=
dependency of that unit.=C2=A0 The systemctl emergency, rescue, reboot,
shutdown, etc, commands, then become effectively shortcuts to the longer systemctl isolate <named-target-unit> command form.

> 5.=C2=A0 I'd have to check, but I wouldn't be surprised if sys= temd doesn't
> actually require specifying a target at all.=C2=A0 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.=C2=A0 This is NOT analogous to just putting only a= pache2
> in /etc/runlevels/default, because in that example openrc is running t= he
> default runlevel, and it only pulls in apache2.=C2=A0 Systemd is purel= y
> dependency driven and when you tell it to make graphical.target the > default runlevel it is like running emerge kde-meta.=C2=A0 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.=C2=A0 Again, I hav= en't tested
> this, but I'd be shocked if it didn't work.=C2=A0 Of course, s= pecifying a
> service as a default instead of a target is very limiting, but it woul= d
> probably work.=C2=A0 Heck, you could probably specify a mount as the d= efault
> and the system would just boot and mount something and sit there.=C2= =A0 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)<= br> manpage, under default.target, this is the default unit started at
bootup.=C2=A0 Normally, it'll be a symlink to either multi-user.target<= br> (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-targe= t
unit is allowed, but systemd does have a commandline option --unit=3D,
which is explicitly documented to take a _unit_, default.target being the default, but other non-target units being possible as well.=C2=A0 Presumabl= y
systemd would examine said unit, looking for DefaultDependencies=3Dno, and<= br> if not specifically set, would start the early "system level" tar= gets,
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.=C2=A0 I'd guess yes, but have neither seen it specifically docu= mented
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.=C2=A0 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 som= e
> cases.=C2=A0 For example, right now /etc/init.d/samba uses some script= ing to
> launch both nmbd/smbd and fancy config file parsing to let the users > control which ones launch.=C2=A0 You could instead break that into thr= ee
> files - smbd, nmbd, and samba.=C2=A0 The first two would launch one da= emon
> each, and the samba init.d script wouldn't actually launch anythin= g, but
> would just depend on the others.=C2=A0 That would be the systemd targe= t
> 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 o= r
a stop, not both, for instance, and I remember actually creating custom
initscripts of that nature, back when I was still on openrc.=C2=A0 So witho= ut
/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, a= nd
> I think that it might be something openrc would actually benefit from<= br> > using.

=3D:^)

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 o= f
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 entir= e
> systemd startup process to be an indecipherable mess.=C2=A0 Not grokin= g 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.=C2=A0 Well, in = systemd
> you might have 47 "runlevels" not actually starting in any p= articular
> order so it is much easier to get it wrong if you don't realize ho= w they
> work.=C2=A0 They aren't strictly sequential, so there isn't al= ways one
> "runlevel" that always comes last that you can be lazy and s= tick
> something "in."

Umm... for anyone following systemd documentation, including most no= n-
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=3Dmulti-user.target, thereby
pulling in all its dependencies as well.=C2=A0 So multi-user.target is the<= br> standard "wanted-by/wants" single "runlevel analog" for= CLI services and
where nearly everything that doesn't have specific reason to be somewhe= re
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.=C2=A0 =C2=A0No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."=C2=A0 Richard Stallman=



--089e0149c63693cdf3052ca0cc86--