systemd: targets which are runlevel-like

[Lennart Poettering]

On Tue, 24.08.10 17:13, Matthew Miller (mattdm at mattdm.org) wrote:

> 
> On Tue, Aug 24, 2010 at 10:57:38PM +0200, Lennart Poettering wrote:
> > Actually it only shows you the active targets, those which a pending
> > job, and those which have failed before (i.e. the "interesting"
> > ones). If you pass --all it will show you inactive targets without
> > pending jobs which haven't failed, too -- but only if they are
> > referenced in some way or recently been used. And "ls
> > /lib/systemd/system/" will show you everything else.
> 
> 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".

The primary reason we do things like this is speed: we want to minimize
the amount of disk seeks and the amount of parsing we do. Hence we
strictly only access stuff that is referenced in some way, which we
hence cannot avoid to load. And that's a feature not a bug.

> 
> > Well, there are certainly some targets which you shouldn't try to start
> > via "isolate" (and some not even with "start"). To handle cases like
> > this we have added the option RefuseManualStart=. It is (for example)
> > set for shutdown.target (which if started alone would result in all
> > services to go away, but no actual "halt" being called in the end so
> > that you'd have a system with PID1 but nothing else, not even a
> > sheel). If set, then running "systemctl start" (and systemctl isolate,
> > too) will fail with an error, and in systemadm the button to start it
> > will be greyed out.
> 
> 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.
 
> > Using "isolate" on getty.target should work fine, though. If it doesn't,
> > file a bug.
> 
> What will it do? What will be running? How can I know? Do I really have to
> generate the dot graph and look at that?
> 
> Here's how I tell what will happen under sysvinit or upstart:
> 
> /sbin/chkconfig | grep 3:on
> 
> and I get a nice, no-nonsense list. 

Well, actually it's not really reliable. You don't see what is activated
via udev (bluetoothd for example), or via dbus, or via cron or via
anything else. It will strictly show you sysv services. If you are
looking for something 1:1 eqivalent, then just use "systemadm" and click on
"multi-user.target" and you can click through the services it will pull
in.

Or alternatively, use something like this:

systemctl show -p "Wants" multi-user.target

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

But don't expect this right-away, this is not completely trivial to
implement.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.