Re: systemd: targets which are runlevel-like
On Tue, 24.08.10 12:31, Matthew Miller (mat...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: targets which are runlevel-like
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? 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? 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. Can I get that with systemd? -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: targets which are runlevel-like
On Tue, 24.08.10 17:13, Matthew Miller (mat...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: targets which are runlevel-like
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? 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. 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. Okay, so, *THIS* is a big selling point for systemd. It knows about all that stuff, so it can give me a nice simple list. Put things like that front and center, and you'll have people lining up to switch. (Minor detail that it doesn't, currently, give you that nice simple list.) 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. That is something like a 1:500 equivalent. 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? Does it recurse? It'd be nice to have it in a nice list, too. The other direction is useful as well. When does gpm get started? is just sbin/chkconfig --list gpm. 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. But don't expect this right-away, this is not completely trivial to implement. Trust me, thinking that any of this is trivial is not a problem I am having. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: targets which are runlevel-like
On Tue, 24.08.10 18:07, Matthew Miller (mat...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: targets which are runlevel-like
On Wed, Aug 25, 2010 at 12:36:54AM +0200, Lennart Poettering wrote: $ 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. So, the feature request is: make this really shiny. If it can be done before F14 final release, that would be awesome and help people really like systemd. If it can't be, document clearly that it's planned. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
