On Tue, 24.08.10 18:07, Matthew Miller (mattdm@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
