On Tue, 24.08.10 12:31, Matthew Miller (mattdm(a)mattdm.org) wrote:
As I was thinking about Bug 626840, I noticed something. With the
current
runlevel system, it's easy to know what your options are. The systemd FAQ
helpfully explains that "systemctl isolate graphical.target" is the
replacement, and that "systemctl list-units --type=target" will show me the
various possibilities.
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.
But it's very difficult to know which of these _might be a good
idea_ to use
as the target for systemctl isolate. I'm not sure what'll happen if I say
"systemctl isolate getty.target" -- will I get a nice console-mode
environment, or will I be stuck with only gettys running?
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.
Using "isolate" on getty.target should work fine, though. If it doesn't,
file a bug.
Lennart
--
Lennart Poettering - Red Hat, Inc.