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