systemd: targets which are runlevel-like

[Lennart Poettering]

On Tue, 24.08.10 18:07, Matthew Miller (mattdm at mattdm.org) wrote:

> 
> On Tue, Aug 24, 2010 at 11:49:56PM +0200, Lennart Poettering wrote:
> > > Wait, so "--all" doesn't actually show me all targets, it shows me an
> > > apparently-arbitrary list of some of the possible targets?
> > It shows you all targets systemd knows about at that point in time.
> > The list of thinkable targets you could activate is more ore less
> > infinite, due to templating and stuff. I am pretty sure people would be
> > pretty annoyed if we'd dump an infinite number of targets on your screen
> > if you just type "systemctl".
> 
> Hmmm. I see what you are saying. And from a technical point of view, that
> sounds reasonable. But here's what one part of me is hearing: wow, this new
> systemd adds a whole bunch of complexity to running a machine.
> 
> That is a not a great selling point.
> 
> Is there a way to present _something_ more straightforward?

Note that using "systemctl status" on a unit that isn't loaded will work
just fine and the unit is implicitly loaded -- though not otherwise
used, and eventually a garbage collector will unload it again. So you
can easily introspect any unit, without ever thinking about loaded or
unloaded units.

What I had in mind is that the command line completion support should
make this easier. I.e. if you run "systemctl isolate" and press TAB,
then it should not only show you what systemd already knows about but
also what you could load, and it could also properly handle
instantiation, i.e. stop completion at the @ and stuff like that. That
appears like the most natural solution to me.

> > > So, most targets are actually valid for 'isolate'? What if I go to
> > > bluetooth.target?  
> > Hmm, we could add RefuseManualIsolate= to make uses like that
> > impossible, while still allowing "start".
> > /me adds this to his todo list.
> 
> Maybe the other way around -- postively list the targets which can be
> manually "isolated"? (I still strongly suggest not using this term, by the
> way.) Or did I take the FAQ's suggestion that this is what I want instead of
> runlevels too far? My impression is that in the general state of things,
> there's really only a small handful of *useful* targets for "isolate".

Interesting idea. I need to think about this.

> > Or alternatively, use something like this:
> > systemctl show -p "Wants" multi-user.target
> 
> Ok, cool, that's definitely a start. Can you put this in the FAQ?

Added.

http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks

> Does it recurse? It'd be nice to have it in a nice list, too.

Well, it's not recursive. If we want it recursive it's probably
better to calculate the full transaction, as suggested below.

> The other direction is useful as well. "When does gpm get started?" is
> just "sbin/chkconfig --list gpm".

$ systemctl show -p "WantedBy" NetworkManager.service

> > > Can I get that with systemd?
> > Well, we could add something that would allow you to calculate a
> > transaction without actually executing this. This will give you a lot
> > more than chkconfig ever did, as it would take into consideration what
> > is already running, and more than just services that are started on
> > boot-up, and the system state
> > /me adds that to his todo list.
> 
> That would be awesome. Thanks. Again, this stuff should be front-and-center.
> 
> On the todo list: it should be able to show you the change from the current
> state, and the change from nothing running at all.

The latter you can already do:

$ systemd --test --system --unit=foobar.target 

This will dump you a lot of stuff, including, at the very end the
transaction it would execute when it would be booted with this target as
destination.

This is mostly a debugging tool. It's probably not a good idea if people
would build scripts based on this, since it actually does a lot more
than just calculating the initial transaction.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.