On Thu, Feb 18, 2016 at 3:57 AM, Duncan <1i5t5.dun...@cox.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
