Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Thu, 12.05.11 08:55, Scott James Remnant (sc...@netsplit.com) wrote: On Tue, May 10, 2011 at 9:39 AM, Lennart Poettering lenn...@poettering.netwrote: Note that you need to delay execution of user code after the base system is set up anyway, in order to ensure that the right perms are set on the volatile and other directories. That means having a single transaction for both user and system services effectively wins you very little. Really, what permissions? The only volatile directories on the system are all tmpfs these days so get passed the permissions in their mount options. Not quite. We have a couple of subdirs which need to be created with the right perms and right users, for example /run/user/ (i.e. the XDG_RUNTIME_DIR hierarchy). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Mon, 09.05.11 19:52, Scott James Remnant (sc...@netsplit.com) wrote: On Mon, May 9, 2011 at 12:16 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Well, right now let's make clear that Firefox/Chromium or other X clients won't be started by systemd as they are user session applications, and systemd itself will just deal with system context (ie: up to GDM/KDM...). Really? A major feature of systemd I understood was that it would also manage user sessions as a seamless part of boot along with the system session. Is that not the case? Right now you can run systemd as the user, and it will startup and work fine. Which is very handy for debugging purposes. However, we have not integrated that with D-Bus or GNOME or anything yet. This is something we want to do for F16: http://lwn.net/Articles/441328/ Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Tue, May 10, 2011 at 7:41 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'm not following all the user-session discussion, but AFAIU this management will be done by the same code, but not same process (it's not PID1). PAM (or another entity that has a role in the login/logout) will talk to systemd (PID1) and ask for a new service to be started to handle this user-session. This will still be the same code, but of course on the user context and not handle things like actual reboot/halt of the machine, mounting system filesystems. But again, I'm not following it closely and I might be wrong here. That's a shame. Having it as a separate process would mean the user session would be started all at once in one go at the end of the boot, rather than with the rest of the boot :-( Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Tue, 10.05.11 09:25, Scott James Remnant (sc...@netsplit.com) wrote: On Tue, May 10, 2011 at 7:41 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'm not following all the user-session discussion, but AFAIU this management will be done by the same code, but not same process (it's not PID1). PAM (or another entity that has a role in the login/logout) will talk to systemd (PID1) and ask for a new service to be started to handle this user-session. This will still be the same code, but of course on the user context and not handle things like actual reboot/halt of the machine, mounting system filesystems. But again, I'm not following it closely and I might be wrong here. That's a shame. Having it as a separate process would mean the user session would be started all at once in one go at the end of the boot, rather than with the rest of the boot :-( We have considered doing all of this in the same process, however ultimiately stepped away from it for security reasons. Adopting a PID1-for-everything scheme also means that you need to add a fairly complex authorization and credentials system to systemd, because you need to validate every single bus call and other operation and map it to a specific user context. Since the kernel and D-Bus are fairly good at doing access control and privilege separation between users we hence decided to make the best of it in systemd and went for the one-systemd-for-each-user scheme. Note that you need to delay execution of user code after the base system is set up anyway, in order to ensure that the right perms are set on the volatile and other directories. That means having a single transaction for both user and system services effectively wins you very little. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
于 2011年05月10日 00:10, Scott James Remnant 写道: Hey, I've been reading through the documentation on systemd and the Mailing List Archives and have had some questions, so I figured I'd post them here. These might be fairly complicated or unusual cases, and there may be no good answers now, and maybe no good answers ever, but I'd still like to get an idea of what you think. ok, i'm trying to express. First up, parallel startup using sockets. We know that the theory of this goes something like this: you have a service that many other services and processes depend on, and connect to via a socket. Rather than manually express that dependency in the configuration, you instead have the socket created by the init daemon in advance. Now you simply start the service and all of the other services and processes together, and let the blocking nature of those sockets (or the software polling a non-blocking socket) sort out the ordering for you. This seems to assume that it's a free cost to start a service or process and have it block on a socket. But that isn't true, to get to the point where it connects to the socket, that service or process first has to be loaded from disk, its shared libraries mapped and relocated, it probably has to do a bunch of initialization including reading its own configuration files, etc. No, we don't. It does not matter how long your server takes to fully start up. That's fine for low priority services out of the critical path for user interaction, but not for services we need as fast as possible. As fast as possible, this can only be done in systemd way. And service won't lost any request. In traditional way, it lost. The best example I can think is the X server itself. It's pretty much the definition of the critical path. Everything started before the X server are those basic system components needed to start the X server, I understand in systemd that this core part would be a different target to the X part and a dep of it. Everything started after the X server is up are components of the user's session that aren't totally critical for them to login or use their computer. Currently, gdm wait for X to be ready before move on. And to be worse, they use busy pull, not by some notification way. In systemd way, gdm don't have to wait. And don't even have to X itself. Just connect to X and X is there. No matter if X is currently running at all. It's during the X startup that things get interesting. There are a few discreet phases of it. Firstly we have to spawn the X server, load the executable, map and relocate shared libraries, all of that jazz. You don't want anything else happening on the system alongside this, and you most certainly don't want every X client (Chromium/Firefox!) being loaded at the same time. The default behaviour of systemd seems to be to do just this :-( No, systemd will not do this anyway. And even it really do this way, what's the point? why X must been the only running process will it is initializing ? Secondly you have the period after the X server has loaded while it initializes but before it's ready to receive clients. In a perfect world this would be fast, but we all know that it isn't. In practice the X server takes countable seconds to do this work. This is a prime place in boot optimization to start other services alongside while X does its thang. But you wouldn't want to flood the system, as you don't want to delay X's startup, just use the spare resource to get more done. Can systemd discern X has been spawned and X has initialized. Can systemd serialize services in this period (perhaps limited to one or two starting at a time)? Can it prioritize the order of those services in the X target? Yeah , we have the *period* for every server. In upstart way, it use complex method to indicate that stages. But with systemd ? We don't even have to care about that. Lastly there's the processes you'd start after X is up and services are connecting to it; again I assume this would be a different target - how would systemd know that X, and the critical X services/processes are fully up and that it can begin starting these. The important thing here is user latency - the startup of these services need to not noticeably impact system performance - not as simple as prioritization because the service itself may well need a different priority once its up. Any thoughts here? This is no such thing called, XX service is initializing, or XX service is up. No, systemd pressent us only one thing: There is XX service that is connect-able. And the first connection may took long to response. But you don't have to wait for the running stage any more. The XX servie is connect-able throughout the way. You don't have to care if XX is running or not. Just connect to it. Thanks, Scott signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
Hi Scott, Some answers below, but consider reading Lennart's reply first. I'll try to cover some points he did not in his reply. On Mon, May 9, 2011 at 1:10 PM, Scott James Remnant sc...@netsplit.comwrote: Hey, I've been reading through the documentation on systemd and the Mailing List Archives and have had some questions, so I figured I'd post them here. These might be fairly complicated or unusual cases, and there may be no good answers now, and maybe no good answers ever, but I'd still like to get an idea of what you think. First up, parallel startup using sockets. We know that the theory of this goes something like this: you have a service that many other services and processes depend on, and connect to via a socket. Rather than manually express that dependency in the configuration, you instead have the socket created by the init daemon in advance. Now you simply start the service and all of the other services and processes together, and let the blocking nature of those sockets (or the software polling a non-blocking socket) sort out the ordering for you. This seems to assume that it's a free cost to start a service or process and have it block on a socket. But that isn't true, to get to the point where it connects to the socket, that service or process first has to be loaded from disk, its shared libraries mapped and relocated, it probably has to do a bunch of initialization including reading its own configuration files, etc. Yes and that's exactly the reason it's good to start them before the other service is fully ready to be used. Say that while DBus is starting due UDisks request, UDisks may be parsing useful information from system (udev tables? -- this is speculation on what is possible, I don't know the code of udisks and if it uses this benefit) As Lennart said, the feeding the CPU and IO to kernel will let it optimize the load. Be grouping disk access or scheduling another process during IO waits for the other. See below for one of my ideas on how to feed more information to kernel. That's fine for low priority services out of the critical path for user interaction, but not for services we need as fast as possible. The best example I can think is the X server itself. It's pretty much the definition of the critical path. Everything started before the X server are those basic system components needed to start the X server, I understand in systemd that this core part would be a different target to the X part and a dep of it. Everything started after the X server is up are components of the user's session that aren't totally critical for them to login or use their computer. It's during the X startup that things get interesting. There are a few discreet phases of it. Firstly we have to spawn the X server, load the executable, map and relocate shared libraries, all of that jazz. You don't want anything else happening on the system alongside this, and you most certainly don't want every X client (Chromium/Firefox!) being loaded at the same time. The default behaviour of systemd seems to be to do just this :-( Well, right now let's make clear that Firefox/Chromium or other X clients won't be started by systemd as they are user session applications, and systemd itself will just deal with system context (ie: up to GDM/KDM...). But using your case, just like I said above, you really want that. You'd chromium and X11 to be loaded at the same time, because the kernel will handle the load and may load chromium executable while X11 is doing EDID read, then may let the dynamic linker work while X11 asks for input device, etc. Also, ideally the socket activation lets you avoid cruft (unused applications and services) being loaded. Let's say you have in your machine Apache, MySQL, Squid for local development. None of these would be loaded, because you never did a request to Apache that would make it to run, in turn it would never talk to MySQL that would not start either. If you did no try to access squid, it would not start either. Same for cups, avahi, ssh and all dbus activated services... you can see that since less is activated, less work is left to do. Secondly you have the period after the X server has loaded while it initializes but before it's ready to receive clients. In a perfect world this would be fast, but we all know that it isn't. In practice the X server takes countable seconds to do this work. This is a prime place in boot optimization to start other services alongside while X does its thang. But you wouldn't want to flood the system, as you don't want to delay X's startup, just use the spare resource to get more done. Can systemd discern X has been spawned and X has initialized. Can systemd serialize services in this period (perhaps limited to one or two starting at a time)? Can it prioritize the order of those services in the X target? It can't know. But it could be changed to be like udev-settle service and force it
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Mon, 09.05.11 16:16, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote: But I do agree with you an a way to state our priorities would be awesome. This is what Lennart said about a future way to feed it to kernel. I suggested some hackish way some time ago: I actually discussed this with a couple of GENIVI folks. They try to optimize things for booting car computers with systemd. Here's what I proposed to them: systemd already has an elaborate dependency system. It's currently mostly used for early boot, as for late boot we want people to rely on implicit deps via socket activation. However the dep system is there, and for embedded uses it might make sense to make a couple of late boot deps explicit. With that information systemd would then be able to deduce which units in the dep tree are the most waited for. These could then get an IO/CPU boost as long as they haven't fully started up yet. We'd just iterate through the cgroup to bump their cpu/io sched parms up, and bump them down when they signal that they started fully up (i.e. in this case they'd have to use Type=notify instead of Typo=simple). So yeah, we already provide most of the tools for the finegrained optimizing of the boot, except for the actual boosting of the perms and the algorithm to determine the most waited for (which however is basic graph theory), but that would probably be a patch of 100 lines or less. I'd be happy to merge such a patch, but I'd like to ask everybody looking into this, to do proper profiling first. My guess is that this kind of microoptimization might help, but we have a lot of other things to fix first (LVM, Ply, DDC, gdm, ...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Mon, 09.05.11 16:16, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote: Well, right now let's make clear that Firefox/Chromium or other X clients won't be started by systemd as they are user session applications, and systemd itself will just deal with system context (ie: up to GDM/KDM...). That's going to change in the F16 cycle hopefully. We'll spawn a per-user instance for most logins, much like launchd. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Mon, May 9, 2011 at 5:21 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 09.05.11 16:16, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote: Well, right now let's make clear that Firefox/Chromium or other X clients won't be started by systemd as they are user session applications, and systemd itself will just deal with system context (ie: up to GDM/KDM...). That's going to change in the F16 cycle hopefully. We'll spawn a per-user instance for most logins, much like launchd. I know, but even then you're in another level of the tree as you're executed from xsession (or similar) thus it would be chained on DM itself. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
