On Thu, 22.07.10 09:13, Chris Adams (cmadams@xxxxxxxxxx) wrote: > IMHO, systemd seems to cram a bunch of existing things (init, inetd, > chkconfig, service, pstree, etc.) together, and the assumption is that > this is new and good. I don't really agree. For example, if on-demand > activation for socket-based services is the way to go, why has everybody > abandonded that model by moving away from inetd? Having init directly > manage services came before sysVinit (hello /etc/inittab), but nobody > uses that anymore either. For starters, systemd is not really about on-demand starting of services. Only very few services in the end will be started on-demand. Socket activation is awesome for four reasons, only one of them being that you actually implement on-demand spawning of daemons, if you wish to. 1. Parallelization: we can completely get rid of any serialization of startup. We can start *every* signle daemon at the same time in one big step, regardless whether one of them needs another. i.e. we can start avahi at the same time as dbus at the same time as syslog at the same time as nscd, although every single one of them might want to connect to another one in this list and in traditional thinking they hence would have needed to be started one after the other, so that every service using another services can be sure it can talk to the one it needs. I mean, how awesome is that? We can completely remove *any* kind of serialization from daemon startup. 2. Simplicity: dependencies become redundant. Nowhere you really have to declare that avahi requires dbus or dbus requires syslog the way we currently do in the LSB init script headers: because the sockets will be established during early boot. All of them. And if some service wants to talk to them he can just do so, without any explicit dependency configured. How awesome is this? We can complete remove *any* kind of declaration of dependencies from daemon startup! 3. Robustness: The sockets stay around all the time, and always connectable. You can kill a daemon but you won't lose a single connection while doing that! Particularly for stateless protocols (such as DNS or syslog) we can automatically restart a daemon when it crashes, and when it comes back it will go on where it left of, as if nothing happened! The client will not even notice! How awesome is that? Restarting daemons without losing connections? 4. On-Demand Startup: Yes, this too. But this actually is relevant for a a select few daemons, where it is likely that they aren't used during boot anyway. If a daemon willk be clearly used during bootup it is smart to start it as early as possible, and not as late as possible because then the first user would have to wait for it which prolongs not shortens the boot process. The select few daemons which can benefit from on-demand starting is stuff like SSH or CUPS which in most installations is used seldomly only. But even if we do on-demand by default for these admins can still start them unconditionally during boot if they want, simply by placing a single symlink. Anyway, these four features of socket based activation are what make it so great. Reducing the whole logic to "inetd in an init system" is completely besides the point, because it's actually completely unlike it. While we do socket passing we do it for different reasons and in a different way. We support inetd compatibility, but in general things will be different from classic inetd setups in so many ways. Anyway, I have tried to explain this many times before. For example in my long blog story. I know I sound like a broken clock, but I can only encourage people ro read it. http://0pointer.de/blog/projects/systemd.html Note that this scheme is not new. launchd championed it. It is part of Apple MacOS since a while. So if you ask "why has every body abandoned that model" then this is a completely bogus statement. Because MacOS just recently moved to it, fully and completey, all over the board. Please, read my blog novel. It is long. But in it I actually try in lengths to explain what is so great about systemd. Yes, really grokking the greatness of socket based activation actually takes a while. But try to wrap your head around it. You might enjoy this talk from an Apple Engineer which explains the logic. It's about launchd, not systemd. But the socket based activation is similar in both systems. So listen to it with a grain of salt: http://video.google.com/videoplay?docid=1781045834610400422# > Also, hasn't starting lots of services in parallel been tried before and > found to thrash the system, actually slowing down boot instead of > speeding it up? Well, if the IO scheduler cannot cope with it (and indeed it seems it is not perfoming as well as it should), then this needs to be fixed in the IO scheduler. In general an elevator should benefit from having a larger set of requests to choose from. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
