Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 15:27 +0200, Denys Vlasenko wrote: plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because it has implications for the correct handoff of tty1, I believe. This was one of the trickier things to get right in systemd. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 21:23 -0500, Dan Williams wrote: systemd might be happy if you change it later, but other stuff is not. The canonical example is X, where the hostname was used as the xauth key to allow you to actually talk to the X server. When the hostname changed, there was no authorization for the new hostname in your xauth file, so starting new apps would silently fail. Basing *anything* like that on your machine hostname is just stupid. It might work for you, but it doesn't work for lots of other people, so lets fix it for everyone. And we did back in the F10 timeframe with /etc/X11/xinit/xinitrc.d/localuser.sh where we just let any local user connect, since that's exactly what xauth's hostname thing was supposed to do anyway. To clarify, we allow local connections where the UID of the connecting process matches the one specified in the xhost call (which is run after you've established a session, so you know the UID of the user whose session is trying to connect). Dan's statement could be read that we allow connections from any local user at all, which is definitely not true. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 08:53 -0400, Daniel J Walsh wrote: The memory problem is just the share number of file context that we are loading, each line of the file_context file is a regex. Currently the file_context file on my Rawhide machine is 4209 lines. If we can determine the only file context that systemd will need, based on directories we can eliminate some of the regexes. For example if we just loaded paths that begin with /var, /tmp, /dev, we would drop the regexs down to 1500. selabel_close() will free all of the file contexts mapping. So if you can bracket the usage of the mapping with a selabel_open();...;selabel_close();, then you'll only be consuming the memory when using the file contexts mapping. You don't want to do that around every file creation / relabel, of course. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 21:23 -0500, Dan Williams wrote: The next example is apps that try to find out your IP address by looking up your hostname. That's completely broken too. Do you have multiple interfaces? Multiple IP addresses? Are you behind NAT? Yeah, all that will torpedo hostname-IP lookups. Hostnames are *informational* and are never a good way to identify anything concrete on a local machine. That didn't used to be the case, but now it is. Things change in 40 years. The hostname is still used a lot in many kerberos aware programs to try to match the keys in keytabs, we are slowly trying to get over that by matching any key that can actually decrypt the ticket you are receiving, but still many programs initialize GSSAPI passing in the hostname. Until all software is fixed (NFS server is still one of them although we are in the process of fixing it) changing the hostname arbitrarily is still problematic. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 10:03 +0200, Lennart Poettering wrote: On Mon, 13.06.11 18:18, Denys Vlasenko (dvlas...@redhat.com) wrote: On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. Example from my machine: Good old ssh-agent: 404 kbytes. Shiny new dconf-service: 2452 kbytes. Shinier newer polkitd: 2836 kbytes. e-addressbook-factory: 5488 kbytes. Of course. What did you think. *Addressbook*! (Empty one in my case). No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :( ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) As mentioned this is primarily the SELinux policy which we load into RAM. I wished libselinux would optimize resource usage transparently a bit better, but even without that we should be able to optimize this a bit in the way systemd loads the policy. SELinux makes boot slower and uses more resources, there is no news in that. There's also no news in the fact that we can definitely optimize its impact wherever we are aware of it. Just to clarify: what is unique here is a long-running daemon that is loading the entire file_contexts configuration into memory and keeping it there for its entire lifetime. Previously, the closest analogy was udev, which was quickly optimized to only load entries under /dev. Old init systems didn't load the file contexts configuration at all; they didn't need it for anything. systemd needs it because it handles creation and labeling of files and sockets that used to be either handled by the daemons themselves (in which case policy could transparently label them based on their creator) or by rc scripts that would fork+exec short-lived restorecon processes to fix up labels. Ways to improve the situation for systemd would include: - Only load a subset of file_contexts entries, similar to udev. - Only load the file contexts entries temporarily, using selabel_open + selabel_close to bracket entire blocks where files are created or relabeled. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Wed, Jun 15, 2011 at 4:44 PM, Stephen Smalley s...@tycho.nsa.gov wrote: Ways to improve the situation for systemd would include: - Only load a subset of file_contexts entries, similar to udev. - Only load the file contexts entries temporarily, using selabel_open + selabel_close to bracket entire blocks where files are created or relabeled. - At policy build time, precompute a DFA for all of the regexps, and store it in a file. This file could be mmap()ed into any user of the policy, requiring no malloc(), and allowing the kernel to free the memory when it is no longer used; this should also make loading of the file_contexts configuration faster. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2011 11:03 AM, Miloslav Trma? wrote: On Wed, Jun 15, 2011 at 4:44 PM, Stephen Smalley s...@tycho.nsa.gov wrote: Ways to improve the situation for systemd would include: - Only load a subset of file_contexts entries, similar to udev. - Only load the file contexts entries temporarily, using selabel_open + selabel_close to bracket entire blocks where files are created or relabeled. - At policy build time, precompute a DFA for all of the regexps, and store it in a file. This file could be mmap()ed into any user of the policy, requiring no malloc(), and allowing the kernel to free the memory when it is no longer used; this should also make loading of the file_contexts configuration faster. Mirek I was wondering if this was possible. Any example of how to do it? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk34y+MACgkQrlYvE4MpobNqQgCgyXPAzaA15Cjsaq7BmZoy+5s5 kRYAn3hf6N4QbNFaPyszp4L6i7vHhlSR =/ZtQ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Wed, Jun 15, 2011 at 11:12:35AM -0400, Daniel J Walsh wrote: On 06/15/2011 11:03 AM, Miloslav Trma? wrote: On Wed, Jun 15, 2011 at 4:44 PM, Stephen Smalley s...@tycho.nsa.gov wrote: Ways to improve the situation for systemd would include: - Only load a subset of file_contexts entries, similar to udev. - Only load the file contexts entries temporarily, using selabel_open + selabel_close to bracket entire blocks where files are created or relabeled. - At policy build time, precompute a DFA for all of the regexps, and store it in a file. This file could be mmap()ed into any user of the policy, requiring no malloc(), and allowing the kernel to free the memory when it is no longer used; this should also make loading of the file_contexts configuration faster. Mirek I was wondering if this was possible. Any example of how to do it? At least with glibc regex, that would be terribly unportable and wouldn't buy much, as regcomp isn't very expensive, the DFA nodes are created on the fly during regexec as needed. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Wed, 2011-06-15 at 09:40 -0400, Adam Jackson wrote: On Tue, 2011-06-14 at 21:23 -0500, Dan Williams wrote: systemd might be happy if you change it later, but other stuff is not. The canonical example is X, where the hostname was used as the xauth key to allow you to actually talk to the X server. When the hostname changed, there was no authorization for the new hostname in your xauth file, so starting new apps would silently fail. Basing *anything* like that on your machine hostname is just stupid. It might work for you, but it doesn't work for lots of other people, so lets fix it for everyone. And we did back in the F10 timeframe with /etc/X11/xinit/xinitrc.d/localuser.sh where we just let any local user connect, since that's exactly what xauth's hostname thing was supposed to do anyway. To clarify, we allow local connections where the UID of the connecting process matches the one specified in the xhost call (which is run after you've established a session, so you know the UID of the user whose session is trying to connect). Dan's statement could be read that we allow connections from any local user at all, which is definitely not true. Yeah, I was loose with the details. Thanks for clearing that up. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote: I wouldn't bother much if it would be just one tiny bit of strange code in systemd, but it is FAR from being the only such code. There are lots of similar stuff, and it's not accidental. It is definitely not accidental, but unless you have bugs to file, I don't think complain generically about systemd architecture here is any productive. Where, in your opinion, is the place to discuss systemd architecture? We discussed systemd for quite a while here and it certainly far from perfect, for some things probably not even good yet. But its time to file bugs for real problems, not time for bike shedding on architectural decision that have been taken quite a while ago. I disagree, and I find the attitude we are developers, you are idiot both quite common and quite wrong. I am a developer too, do you want me to treat *you* this way too when you will have trouble with my software? -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/14/2011 12:50 PM, Denys Vlasenko wrote: On Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote: I wouldn't bother much if it would be just one tiny bit of strange code in systemd, but it is FAR from being the only such code. There are lots of similar stuff, and it's not accidental. It is definitely not accidental, but unless you have bugs to file, I don't think complain generically about systemd architecture here is any productive. Where, in your opinion, is the place to discuss systemd architecture? systemd upstream list as I has been pointed out a few times http://lists.freedesktop.org/mailman/listinfo/systemd-devel I disagree, and I find the attitude we are developers, you are idiot both quite common and quite wrong. I am a developer too, do you want me to treat *you* this way too when you will have trouble with my software? I don't think you are helping yourself with the antagonistic approach you have taken. If I had trouble with your software, I would start by asking questions on why things the way they are rather than immediately start telling you, the way you have written it is entirely wrong. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 13.06.11 18:01, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: On Mon, 13.06.11 15:27, Denys Vlasenko (dvlas...@redhat.com) wrote: kmod_setup(); === ??? We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. You assume that everyone uses IPv6. This is not true. No I am not. You can still blacklist the ipv6 module if you want to via the normal modprobe blacklisting mechanisms. (As mentioned, systemd passes -b to the modprobe command line to ensure that). I explicitly said that in a previous mail. hostname_setup(); === ??? We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. (none) is what the bash makes from empty hostname, which is the default. We just fill in one. Just because systemd sets up a hostname at boot it doesnt mean it couldn't be changed dynamically later on. In fact if you are into dynamic hostnames you should send me a big cake for my birthday as thank you, because I give you stuff like this for F16: https://fedoraproject.org/wiki/Features/nssmyhostname http://www.freedesktop.org/wiki/Software/systemd/hostnamed Why do you set up stuff no one asked you to? Yeah, I explained that already. machine_id_setup(); === ??? Similar to the hostname we ensure that the machine id is always initialized, and has the same lifetime and validity guarantees as the hostname. i.e. that it is simply usable by *every* process started, regardless when. Point me at one program which uses machine id. I never saw one. And anyway, why do you set up stuff no one asked you to? /etc/machine-id is a generalization of the D-Bus machine id, which is used by quite a number of programs directly and indirectly. With systemd we try to make this available globally and independently of D-Bus and add new semantics for stateless systems. plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. Plymouth is not a part of Unix. Init process has no business knowing about distro specific stuff like that. Well, since you appear to have invented Unix I think we simply have to disagree here. This is an antithesis to modular, Unix way of doing things. Just because you can turn each trivial operation into a separate binary you shouldn't necessarily do that. Where did I propose turning everything into a separate binary? Well, I say calling sethostname() is a syscall we should simply do in PID 1 and then forget about, but you want this in a separate process (hence separate binary). It is what makes your system slow and heavy-weight. Insisting that we invoke sethostname() in a separate process is just stupid. I am mean, come on, think about it. It is *ONE* system call to the the hostname with sethostname(). Invoking /bin/hostname instead is at least 40 or so (and many of those quite heavy weight). And really, why are we even discussing the frickin hostname like this? Because it's a perfect example of a thing init process has no business doing. Ever. The lightness of the syscall is irrelevant. For example, you also do modprobing of various things, which is far from being just one syscall, so this argument is moot. Well, I guess we simply have to disagree. My interest is a tighly integrated, small, minimal, lightweight system. Yours seem to be a big, archaic, chaotic, redundant, resource intensive system. But that's fine. Do you know what mono means? It's greek and means one. And lithic means stone. And if systemd communicates with Plymouth, then this is not monolothic at all, since systemd and ply are two processes, not one. Init process should not have intrinsic knowledge about splash screens! systemd knows nothing about splash screens. All it does is send status updates to Plymouth. This is basic idea of modularity. This is how Unix always worked.
Re: systemd: please stop trying to take over the world :)
On Mon, 13.06.11 17:19, Matthew Garrett (mj...@srcf.ucam.org) wrote: On Mon, Jun 13, 2011 at 05:13:39PM +0100, Peter Robinson wrote: On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett mj...@srcf.ucam.org wrote: The point of providing a platform is that developers can make certain assumptions about available functionality. It's no longer reasonable to treat IPv6 as an optional part of the internet, any more than it's reasonable to consider IPv4 as optional. But if you don't want it, simply don't build it. I believe the ipv6 module is going to be built in soon anyway. http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html I'd assumed that Dennis was talking about non-Fedora environments, since ipv6 hasn't been meaningfully optional in Fedora for ages. Note that ipv6-less systems are explicitly supported by systemd, by means of blacklisting the kmod in the modprobe configuration. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, Jun 14, 2011 at 01:13:01AM +0200, Kevin Kofler wrote: Denys Vlasenko wrote: Try rm /usr/sbin/console-kit-daemon. Works like a charm. Randomly removing pieces of installed packages has never been supported. I think the console-kit-daemon service can be disabled, but xinit prefixes xsession with ck-xinit-session which seems to start the daemon on demand. It would be nice if xinit could be configured to not use it. Same for ssh-agent. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 13.06.11 18:01, Miloslav Trmač (m...@volny.cz) wrote: On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering mzerq...@0pointer.de wrote: plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. The long-term question here is what happens when Plymouth is replaced by something different, first in one specialist distribution, later by one major distribution (perhaps Fedora), and only much later by most distributions?. Will systemd only support the new thing, forcing the slower distributions to backport patches? Will systemd support both systems, and over time become burdened with compatibility code? Something else? As usual, we'll decide case-by-case and as I know myself and the triviality of this code we'd probably support both for a while and then drop the old code a bit later. Historically, each distribution had its own system integration scripts that supported only the tools the distribution cared about, so there never was a single project fighting with the matrix of N distributions x M implementations of major features. With systemd we have a very strict policy: we want to gently push the distros to standardize on the same components for the base system. That means that if you use ply and systemd together you get the best features but you can still use them independently too. It's loosely coupled, but we do want to get people to use this combination and no other by offering them the best support for this combination. (Also, most of them don't emit useful info on --help...) They aren't user binaries. They are in /lib/systemd, not /usr/bin... But they do implement user-visible functionality, and have user-visible /proc/cmdline options. Yes, old initscripts didn't document the behavior either, but the sysadmin (who, for better or worse, pretty much has to be able to read shell code) could find them and could understand and debug the boot process by reading /etc/rc.*. I think that asking the sysadmin to read the C code of systemd to understand the boot process and how it can be configured is rather excessive. I think systemd documentation is much better than the documentation of most other open source projects. If we missed something in the documentation please file a bug and we'll fix it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 13.06.11 18:18, Denys Vlasenko (dvlas...@redhat.com) wrote: On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. Example from my machine: Good old ssh-agent: 404 kbytes. Shiny new dconf-service: 2452 kbytes. Shinier newer polkitd: 2836 kbytes. e-addressbook-factory: 5488 kbytes. Of course. What did you think. *Addressbook*! (Empty one in my case). No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :( ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) As mentioned this is primarily the SELinux policy we load. I wished libselinux would optimize memory usage transparently, but even without any changes in libselinux we should be able to optimize this a bit. Yes, using SELinux makes your boot a bit slower and consumes more resources, there is no news in that, and there's also no news in the fact that we can optimize this a bit when we are aware of it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 13.06.11 18:18, Denys Vlasenko (dvlas...@redhat.com) wrote: On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. Example from my machine: Good old ssh-agent: 404 kbytes. Shiny new dconf-service: 2452 kbytes. Shinier newer polkitd: 2836 kbytes. e-addressbook-factory: 5488 kbytes. Of course. What did you think. *Addressbook*! (Empty one in my case). No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :( ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) As mentioned this is primarily the SELinux policy which we load into RAM. I wished libselinux would optimize resource usage transparently a bit better, but even without that we should be able to optimize this a bit in the way systemd loads the policy. SELinux makes boot slower and uses more resources, there is no news in that. There's also no news in the fact that we can definitely optimize its impact wherever we are aware of it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 13.06.11 19:02, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. Wow, that's convincing proof. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 13.06.11 22:46, Denys Vlasenko (dvlas...@redhat.com) wrote: In this case you are not better/worse than before, once the network will come up you'll add a script to change the hostname. Setting it earlier in systemd makes no difference. You continue to avoid answering my question: WHY systemd, a service management tool, bothers with setting hostname? It's not its task! As mentioned already: so that all userspace can rely on a valid hostname to be set. Which makes things much nicer for early boot logging as one example. And then there is simplicity, because you need no further configured service deps and you use less resources too, and it's simpler to read the sources, and faster, and more robust. Slide 6: We can now boot a system shell-free IOW: shell is bad, my new shiny toy is good. Oh god. If you had listened you'd have understood that my aim is to deemphasize shell in the boot process, not as an interactive tool or scripting tool. It's about the boot process, and nothing but the boot process. And as a matter of fact in all my talks I explicitly underline that fact. You are FUDding, and it's not helpful. Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? That is not a technical argument, but just FUDing. Of course, systemd is not an aircraft carrier. If all arguments you can come up with are made up arguments then you have no arguments at all. If you want to criticise systemd, then do it on technical grounds, not FUDing with things I never said and you sucked out of your fingers. More to the point: Lennart can call his program whatever he wants, even Nuclear Submarine. The point is: some people might disagree with having service management tool with Napoleonic aspirations. For one, I do! Good for you then. Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. Yeah, it's not the right tool for the boot process. Doesn't mean it wasn't useful for interactive use or for scripting. Just not the right tool for the boot process. Since you seem to have trouble understanding that, let me repeat it a couple of times: shell is not the best tool to accomplish a quick and reliable bootup. shell is not the best tool to accomplish a quick and reliable bootup. shell is not the best tool to accomplish a quick and reliable bootup. shell is not the best tool to accomplish a quick and reliable bootup. shell is not the best tool to accomplish a quick and reliable bootup. Slide 79: Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots, cryptsetup, ... That's what I refer to by taking over the world. Well, I just refer to that as systemd as a platform for building an OS from. Note that neither slides, nor this email thread produced an explanation WHY all this stuff is thrown together into one project. In fact those slides you refer to explain all that. If you don't listen and don't want to read, then I cannot help you. One last try with different words, nonetheless: simplicity, speed, robustness, compactness, functionality. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 14.06.11 09:20, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote: I wouldn't bother much if it would be just one tiny bit of strange code in systemd, but it is FAR from being the only such code. There are lots of similar stuff, and it's not accidental. It is definitely not accidental, but unless you have bugs to file, I don't think complain generically about systemd architecture here is any productive. Where, in your opinion, is the place to discuss systemd architecture? systemd is being discussed on the systemd mailing list and on the IRC channel. This is much like most projects are discussed on their respective mailing lists and IRC channels, and you should know that. We discussed systemd for quite a while here and it certainly far from perfect, for some things probably not even good yet. But its time to file bugs for real problems, not time for bike shedding on architectural decision that have been taken quite a while ago. I disagree, and I find the attitude we are developers, you are idiot both quite common and quite wrong. Oh come on. I have wide open ears. If people make constructive suggestions we listen, and we change things. We'll not change everything, and not without very good reasons, but claiming we wouldn't listen is just insulting. I am pretty sure you you will find a bunch of people who will testify that we implemented a feature they requested on this ML, on bz, at a conference, on IRC or some other place for them. Or we fixed a bug for them, or we even changed behaviour of systemd in one way or another on their request. Making a good case, being polite and convincing gets you a long way. systemd is developed in the open. You can easily participate in various ways. However, if you come overly late to the party, are insulting and demanding, imply we are idiots OR SHOUT ALL THE TIME, then we might be less willing to consider your requests. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 09:42 +0200, Lennart Poettering wrote: On Mon, 13.06.11 18:01, Denys Vlasenko (dvlas...@redhat.com) wrote: Maybe. It's not up to a piece of software to decide. In Unix, admins should have power to decide, not programs. Programs provide the means, they don't dictate policies. Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. And you pitch systemd to be used by embedded devices. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! I think systemd is much more optimized that what existed previously. (what else is parallelization but optimization?) I bet with you that a systemd system (modulo SELinux) can be built in a way that uses much less resources and boot time than one built on Upstart. I never used upstart. I used daemontools. I bet you can't beat *that* on resource front. Boot time is comparable. daemontools does not support socket activation for parallelizing execution of servers with its clients. So yes, we can beat *that*. I said you can't beat *that* on resource front. On resource front. Can you beat it on resource front? I mean, this is like comparing apples and oranges. systemd gives you an OS building box, daemontools nothing but a service supervisor. Which is what I *like* about daemontools. It's Unix way to be nothing but a tool for one purpose, ans serve it well. If you use daemontools you also need an init system, and boot scripts, and everything else. So yeah, if you compare systemd and daemontools+sysvinit+initscripts then, hell yeah, I can beat that. This is not true. daemontools can be set up in a way than most init scripts are no longer necessary. It also achieves parallelized start. It can also be used as an init replacement, but unlike systemd, it does not make it a requirement. On my home machine I use a separate init (which does only child reaping), daemontools, and a very small set of init scripts (yes, horror, shell scripts). It starts in about 3 seconds. The system fully booted to text mode uses 20 megs of RAM total, all processes plus kernel, but excluding fs cache. You can't beat that. In fact, you are yet to reply why systemd uses eleven megs of RAM all by itself. daemontools don't do socket activation, therefore I'm not proposing we use daemontools instead of systems. IOW, I do not claim that daemontools is a better service management tool that systemd. I do argue that deamontools goal to provide ONLY service management instead of being shampoo and conditioner in one pack is a better approach. Hmm? systemd is an init system, so it is of course PID 1. Again. *Why it has to have PID 1* to spawn and control services? Can you please answer this? Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized processes. Why service daemon needs to receive death notifications from daemonized processes? -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/14/2011 11:17 AM, Somebody in the thread at some point said: Hi - Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. And you pitch systemd to be used by embedded devices. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! IPv6 is optional though, Lennart says you can blacklist the module. If it acts gracefully if IPv6 is not builtin or installable by module then all is well. Embedded as an argument needs a lot of care. It means several very different things, but many of those things are out of scope for Fedora, eg, ARM7. (Use busybox there ^^) For what's left, eg ARM9+ that you can run normal Linux and Fedora on, ipv6 is going to be workable if the memory allows. Looking a year or two ahead, where Embedded will extend to Cortex A15 quad core, and IPv6 will presumably have gained traction, the tradeoffs involved with cutdown environments like busybox / dropbear and IPv4-only are going to start being harder to accept. So while it's super healthy to press system tools on bloat, it is quite possible to deploy the Embedded argument to go too far and conflict with what Fedora is and trying to do overall -- and what other Embedded guys will want from it in future. Embedded is generally converging towards the kind of full strength systems we use on x86 today. -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote: On Mon, 13.06.11 22:46, Denys Vlasenko (dvlas...@redhat.com) wrote: Slide 6: We can now boot a system shell-free IOW: shell is bad, my new shiny toy is good. Oh god. If you had listened you'd have understood that my aim is to deemphasize shell in the boot process You go quite farther than that. We can now boot a system shell-free. *Shell-free*. You are not saying driving boot process by shell scripts is slow because ... ... ... (an argument I would agree with), you are aiming at *eliminating* shell scripts from boot process. Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? That is not a technical argument, but just FUDing. No, it is a technical argument. I am saying that this is not how things are supposed to be done in Unix. I am saying that you are trying to incorporate as much stuff as possible into systemd, and I think it's wrong. You don't like me saying this? Well, not a surprise. I also don't like when people tell me that I'm wrong. Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. Yeah, it's not the right tool for the boot process. Doesn't mean it wasn't useful for interactive use or for scripting. Just not the right tool for the boot process. Since you seem to have trouble understanding that, let me repeat it a couple of times: shell is not the best tool to accomplish a quick and reliable bootup. Can shell play a part in the boot process, or is it now completely banished? I don't know, is something like this acceptable in the new world of systemd? ulimit -d $((16*1024*1024)) exec my_favorite_program some_opts Slide 79: Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots, cryptsetup, ... That's what I refer to by taking over the world. Well, I just refer to that as systemd as a platform for building an OS from. Note that neither slides, nor this email thread produced an explanation WHY all this stuff is thrown together into one project. In fact those slides you refer to explain all that. If you don't listen and don't want to read, then I cannot help you. One last try with different words, nonetheless: simplicity, speed, robustness, compactness, functionality. Good that you don't include modularity any more. At least one of my arguments reached through, it seems. Let's take a look at each of them: simplicity - I don't see it speed - yes robustness - actually yes, your code seems to be good in that area compactness - no functionality - too much of it. I'd call it bloat I would also add monolithic and inflexible. Sorry. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 11:31 +0100, Andy Green (林安廸) wrote: Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. And you pitch systemd to be used by embedded devices. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! IPv6 is optional though, Lennart says you can blacklist the module. If it acts gracefully if IPv6 is not builtin or installable by module then all is well. Embedded as an argument needs a lot of care. It means several very different things, but many of those things are out of scope for Fedora, eg, ARM7. (Use busybox there ^^) For what's left, eg ARM9+ that you can run normal Linux and Fedora on, ipv6 is going to be workable if the memory allows. Looking a year or two ahead, where Embedded will extend to Cortex A15 quad core, and IPv6 will presumably have gained traction, the tradeoffs involved with cutdown environments like busybox / dropbear and IPv4-only are going to start being harder to accept. I talk to a lot of embedded people. Tiny machines are not going to disappear anytime soon - they just go into smaller and smaller gadgets. For example, there are still a noticeable segment of NOMMU CPUs, meaning if you really target embedded, you need to learn how to live with vfork only. You can't just handwave embedded away by assuming that embedded will get big enough for me to not really care about optimizing for size. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/14/2011 04:13 PM, Denys Vlasenko wrote: I talk to a lot of embedded people. Tiny machines are not going to disappear anytime soon - they just go into smaller and smaller gadgets. For example, there are still a noticeable segment of NOMMU CPUs, meaning if you really target embedded, you need to learn how to live with vfork only. You can't just handwave embedded away by assuming that embedded will get big enough for me to not really care about optimizing for size. Since ipv6 is really optional in systemd, why are you even arguing about this at all, anymore? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 14.06.11 12:17, Denys Vlasenko (dvlas...@redhat.com) wrote: On Tue, 2011-06-14 at 09:42 +0200, Lennart Poettering wrote: On Mon, 13.06.11 18:01, Denys Vlasenko (dvlas...@redhat.com) wrote: Maybe. It's not up to a piece of software to decide. In Unix, admins should have power to decide, not programs. Programs provide the means, they don't dictate policies. Dude, systemd requires the functionality of the three modules it loads explicitly. systemd requires ipv6. No it doesn't. All it does is make use of IPv6 if it is available (where available means: if compiled in to the kernel or compiled as kmod and not blacklisted). It requires the kernel module to be loaded properly at boot to make use of that, hence it will try loading it, unless it is explicitly blacklisted. And you pitch systemd to be used by embedded devices. Yes, I do. Do you really think all embedded devices will be happy with having such an arbitrary requirement? Heck, I know embedded device people who remove even ipv4! I said multiple times explicitly that systemd explicitly supports IPv6-less systems. If you use daemontools you also need an init system, and boot scripts, and everything else. So yeah, if you compare systemd and daemontools+sysvinit+initscripts then, hell yeah, I can beat that. This is not true. It is. daemontools can be set up in a way than most init scripts are no longer necessary. It also achieves parallelized start. This is bogus. It can also be used as an init replacement, but unlike systemd, it does not make it a requirement. On my home machine I use a separate init (which does only child reaping), daemontools, and a very small set of init scripts (yes, horror, shell scripts). It starts in about 3 seconds. The system fully booted to text mode uses 20 megs of RAM total, all processes plus kernel, but excluding fs cache. Good for you, but what does that have to do with Fedora? You can't beat that. In fact, you are yet to reply why systemd uses eleven megs of RAM all by itself. Hey, read my mails: SELinux policy, SELinux policy, SELinux policy, SELinux policy, SELinux policy. Hmm? systemd is an init system, so it is of course PID 1. Again. *Why it has to have PID 1* to spawn and control services? Can you please answer this? Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized processes. Why service daemon needs to receive death notifications from daemonized processes? To be able to supervise them? That's a key feature of supervision of services: that you know when a daemon is gone, and know the exit code and whether it crashed or not. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Is not it easy to remove everything from: default.target basic.target graphical.target ... and then add whatever we want to start or to execute or mount? I do not really care what systemd CAN do, but really care what it is doing on my system. So, may be some cleaning will be the wise solution. One would like to eat fish Eat one's cake and have it И волки сыты и овцы целы. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/14/2011 11:43 AM, Somebody in the thread at some point said: For what's left, eg ARM9+ that you can run normal Linux and Fedora on, ipv6 is going to be workable if the memory allows. Looking a year or two ahead, where Embedded will extend to Cortex A15 quad core, and IPv6 will presumably have gained traction, the tradeoffs involved with cutdown environments like busybox / dropbear and IPv4-only are going to start being harder to accept. I talk to a lot of embedded people. Tiny machines are not going to disappear anytime soon - they just go into smaller and smaller gadgets. Me too... I think maybe considerations valid at the low-end devices you know very well are blinding you a bit to how applicable those considerations are, eg -- For example, there are still a noticeable segment of NOMMU CPUs, meaning if you really target embedded, you need to learn how to live with vfork only. ... NOMMU and ARM7 that can't run Fedora are to discussions about architecture of Fedora. You can't just handwave embedded away by assuming that embedded will get big enough for me to not really care about optimizing for size. My point was that pressure against bloat is good. But when I look at compromises made in stuff commonly used in ARM7 / cross world, I wouldn't want to see that happening in Fedora in the name of a debloating jihad that simply doesn't matter on most of the platforms it targets. Still, I hope this thread at least reminded people that it doesn't hurt to have a modest memory footprint ^^ -Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/14/2011 04:06 AM, Lennart Poettering wrote: On Mon, 13.06.11 19:02, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. Wow, that's convincing proof. Lennart One question - does systemd run /etc/rc.local script? If not where do I put my own little things I want to happen at boot up. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 14.06.11 12:36, Denys Vlasenko (dvlas...@redhat.com) wrote: On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote: On Mon, 13.06.11 22:46, Denys Vlasenko (dvlas...@redhat.com) wrote: Slide 6: We can now boot a system shell-free IOW: shell is bad, my new shiny toy is good. Oh god. If you had listened you'd have understood that my aim is to deemphasize shell in the boot process You go quite farther than that. We can now boot a system shell-free. *Shell-free*. Yupp, and this is one of the reasons why we boot so fast and can boot a reasonably comprehensive userspace in less than one second. A shell-free boot doesn't mean there wasn't any /bin/sh anymore. I mean, I use bash all the time, it's a key way how I interface with my machine. I use it in build scripts and everything, and I have no plans at all to remove it from that and doing that would be crazy. But in the boot process? I don't think it is the best tool for the job, and unnecessary, and if we deemphasize or remove it from the boot process we have a lot to win. You are not saying driving boot process by shell scripts is slow because ... ... ... (an argument I would agree with), you are aiming at *eliminating* shell scripts from boot process. Yes, I want to deemphasize the shell in the boot process, and ideally remove it entirely from the boot process. Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? That is not a technical argument, but just FUDing. No, it is a technical argument. I am saying that this is not how things are supposed to be done in Unix. I am saying that you are trying to incorporate as much stuff as possible into systemd, and I think it's wrong. You don't like me saying this? Well, not a surprise. I also don't like when people tell me that I'm wrong. Wow, you honestly believe that suggesting systemd would turn into an aircraft carrier is a technical argument? Must be good stuff you are smoking... I think we'll just have to agree to disagree and leave it at that. Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. Yeah, it's not the right tool for the boot process. Doesn't mean it wasn't useful for interactive use or for scripting. Just not the right tool for the boot process. Since you seem to have trouble understanding that, let me repeat it a couple of times: shell is not the best tool to accomplish a quick and reliable bootup. Can shell play a part in the boot process, or is it now completely banished? I don't know, is something like this acceptable in the new world of systemd? systemd will not take /bin/sh away from you. It will just give you the right tools so that you don't need it anymore for booting, thus saving resources, making things faster and more robust. We will continue to support SysV init scripts for a long time, for compatibility reasons, and you'll always be able to plug a shell script into the ExecStart= line of a systemd service file, if you want to. ulimit -d $((16*1024*1024)) exec my_favorite_program some_opts Sure you can do that, systemd will not take that away from you. However, we offer you a nicer, more descriptive, more homogenous way to do that in the service file itself, simply by using LimitDATA= in the service file. Easier to use, more descriptive, faster and involves no shell. In fact those slides you refer to explain all that. If you don't listen and don't want to read, then I cannot help you. One last try with different words, nonetheless: simplicity, speed, robustness, compactness, functionality. Good that you don't include modularity any more. At least one of my arguments reached through, it seems. Uh? systemd is modular. Absolutely, you can choose the parts you want and the ones you don't, which is handy for embedded uses. If you however ask why we integrate a lot of previously separate stuff in systemd, then answering to make it modular would be kinda bogus. systemd is absolutely modular, but modularity is not a reason for integrating things the way we do. Oh, and the list above why we do this is not complete anyway, there's a lot I could still add as reasons why we integrate things like this. For example we want to use systemd as gentle push for the distros using it to unify, standardize and de-balkanize the basic set of components of the OS. Let's take a look at each of them: simplicity - I don't see it What's so hard to understand, that with systemd you need 10 basic packages to build a minimal system, and without systemd you need 50. systemd is hence much simpler to understand. (these are not exact numbers) speed - yes robustness - actually yes, your code seems to be good in that area compactness - no Oh hell, absolutely. It's much
Re: systemd: please stop trying to take over the world :)
On Tue, 14.06.11 07:14, Steve Clark (scl...@netwolves.com) wrote: On 06/14/2011 04:06 AM, Lennart Poettering wrote: On Mon, 13.06.11 19:02, Denys Vlasenko (dvlas...@redhat.com) wrote: On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. Wow, that's convincing proof. Lennart One question - does systemd run /etc/rc.local script? If not where do I put my own little things I want to happen at boot up. Yes, it does run that on Fedora by default. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 09:53 +0200, Lennart Poettering wrote: Changing a machine hostname at random times is just asking for trouble. Well, but it has been used in the past, and as definitely something we should support in one way or another. Never said we shouldn't allow it to change, just that if you do some things may break in more or less evident ways. Which is why we have this: https://fedoraproject.org/wiki/Features/nssmyhostname and http://www.freedesktop.org/wiki/Software/systemd/hostnamed and there are even people working on sending out change notifications from /proc/sys/kernel/hostname in the kernel. What's the problem of having a specific hostname set up at boot time ? The user might want to change it? Does setting it at boot time prevent you from changing it later ? DHCP wants to change it? Name conflict in the local network, and Avahi wants to change it? Of course, the latter we don't necessarily want to do by default, but they are valid uses. There is always good reasons to change it at one time or another, none of these say it is a bad idea to set it early though. In general I see 3 categories of machine: - diskless machines that needs to get the hostname from DHCP as they have no local configuration storage whatsoever - personal, un-managed machines that can change name on a whim. - managed machines, that may have keytabs and can never change name but use things like dynDNS instead to tell other machines where they are. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 13:14 +0200, Lennart Poettering wrote: On Tue, 14.06.11 12:36, Denys Vlasenko (dvlas...@redhat.com) wrote: On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote: On Mon, 13.06.11 22:46, Denys Vlasenko (dvlas...@redhat.com) wrote: Slide 6: We can now boot a system shell-free IOW: shell is bad, my new shiny toy is good. Oh god. If you had listened you'd have understood that my aim is to deemphasize shell in the boot process You go quite farther than that. We can now boot a system shell-free. *Shell-free*. Yupp, and this is one of the reasons why we boot so fast and can boot a reasonably comprehensive userspace in less than one second. Wrong. Running shell scripts per se is not a significant slowdown. daemontools does it all the time. It just *runs them in parallel*. Performing system initialization *from* shell scripts *is* significant slowdown, because writing parallelized init in shell, correctly, is not easy. A shell-free boot doesn't mean there wasn't any /bin/sh anymore. I mean, I use bash all the time, it's a key way how I interface with my machine. I use it in build scripts and everything, and I have no plans at all to remove it from that and doing that would be crazy. I never thought you want to do that. No argument here. But in the boot process? I don't think it is the best tool for the job, and unnecessary, and if we deemphasize or remove it from the boot process we have a lot to win. I don't think this is the only your motivation. You want to acquire as much turf as possible. Killing shell scripts everywhere in init process and requiring everyone to use systemd's way to set ulimit and whatnot etc will give you significant amounts of authority and power. Packaging people will be forced to come to you and ask for this and that (anything they could do in shell scripts, but not they can't). This will feel good, right? You will be such an important guy! I don't see any other reason for the crusade to eliminate shell scripting from boot process. You are too clever to actually believe that shell script start time is the biggest problem in boot time. systemd will not take /bin/sh away from you. It will just give you the right tools so that you don't need it anymore for booting, thus saving resources, making things faster and more robust. We will continue to support SysV init scripts for a long time, for compatibility reasons, and you'll always be able to plug a shell script into the ExecStart= line of a systemd service file, if you want to. ulimit -d $((16*1024*1024)) exec my_favorite_program some_opts Sure you can do that, systemd will not take that away from you. However, we offer you a nicer, more descriptive, more homogenous way to do that in the service file itself, simply by using LimitDATA= in the service file. Easier to use, more descriptive, faster and involves no shell. Exactly as I suspected. Your new shiny way is better than our stupid old way. Except that I was quite happy with the old stupid way of setting data segment limit. I don't want to learn new way just to stroke your oversized ego by being forced to do it your way. daemontools has it right: it doesn't force me to abandon what worked so well for 40 years. It allowed me to run a service by writing a small shell script which can set, say, ulimit. Or cd to a directory. Or chroot. Or export a variable. Or mkdir /var/run/FOO... -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 12:53 +0200, Lennart Poettering wrote: daemontools can be set up in a way than most init scripts are no longer necessary. It also achieves parallelized start. This is bogus. Amazingly deep argument. Can you do better than this? Hmm? systemd is an init system, so it is of course PID 1. Again. *Why it has to have PID 1* to spawn and control services? Can you please answer this? Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized processes. Why service daemon needs to receive death notifications from daemonized processes? To be able to supervise them? That's a key feature of supervision of services: that you know when a daemon is gone, and know the exit code and whether it crashed or not. This is bogus (c) Lennart. You can't know that because you have no idea that dead process with pid N is a daemon you started for service FOO. Because when you started it, its pid was not N (if it really did daemonize). With sufficient amount of nutty hackery it may be possible to figure is out, but it will be either racy, or will require labeling (process groups? session ids? cgroups?) which, in general, is not reliable: processes can escape from that. Much saner solution is to simply require controlled processes to not daemonize. (Today it is a common practice to equip every daemon with a don't daemonize switch for this, so it's not a problem.) This way, service management tool will get death notifications in a natural way, via its parent-child relationship with the service process. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, Jun 14, 2011 at 01:42:42PM +0200, Denys Vlasenko wrote: (anything they could do in shell scripts, but not they can't). This will feel good, right? You will be such an important guy! I think most lurkers have understood you seem to have some personal issues with Lennart. Please still show some respect or continue in private please. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 14.06.11 07:25, Simo Sorce (s...@redhat.com) wrote: What's the problem of having a specific hostname set up at boot time ? The user might want to change it? Does setting it at boot time prevent you from changing it later ? No, systemd will initialize it at boot and is happy if you change it later. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/14/2011 04:00 AM, Lennart Poettering wrote: On Mon, 13.06.11 18:18, Denys Vlasenko (dvlas...@redhat.com) wrote: On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. Example from my machine: Good old ssh-agent: 404 kbytes. Shiny new dconf-service: 2452 kbytes. Shinier newer polkitd: 2836 kbytes. e-addressbook-factory: 5488 kbytes. Of course. What did you think. *Addressbook*! (Empty one in my case). No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :( ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) As mentioned this is primarily the SELinux policy we load. I wished libselinux would optimize memory usage transparently, but even without any changes in libselinux we should be able to optimize this a bit. Yes, using SELinux makes your boot a bit slower and consumes more resources, there is no news in that, and there's also no news in the fact that we can optimize this a bit when we are aware of it. Lennart I just released an updated version of libselinux that will no longer do the dups check on loading file labeling. Testing with matchpathcon, I see a four time speed up on loading the file context file. Basically from 1 Second down to .25 seconds. The memory problem is just the share number of file context that we are loading, each line of the file_context file is a regex. Currently the file_context file on my Rawhide machine is 4209 lines. If we can determine the only file context that systemd will need, based on directories we can eliminate some of the regexes. For example if we just loaded paths that begin with /var, /tmp, /dev, we would drop the regexs down to 1500. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk33Wb0ACgkQrlYvE4MpobNmgQCgw65ed5f489YvTnB4XZ6fMbxG X+0AnRi2iUSSuqsb/GzIPeXg5lLh8Cr1 =L1oe -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 14:08 +0200, Lennart Poettering wrote: On Tue, 14.06.11 07:25, Simo Sorce (s...@redhat.com) wrote: What's the problem of having a specific hostname set up at boot time ? The user might want to change it? Does setting it at boot time prevent you from changing it later ? No, systemd will initialize it at boot and is happy if you change it later. As I thought, then I see no problem here. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Miroslav Lichvar wrote: I think the console-kit-daemon service can be disabled, but xinit prefixes xsession with ck-xinit-session which seems to start the daemon on demand. It would be nice if xinit could be configured to not use it. ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able to access your hardware without it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/14/2011 06:36 AM, Denys Vlasenko wrote: You go quite farther than that. We can now boot a system shell-free. *Shell-free*. You are not saying driving boot process by shell scripts is slow because ... ... ... (an argument I would agree with), you are aiming at *eliminating* shell scripts from boot process. I think the key word here is 'can': Lennart is saying that shell is slow and unreliable and systemd allows you to engineer a streamlined boot process that brings all the necessary parts of the system up without the shell. He's not eliminating the possibility of using shell for any additional stuff, if that's what you want---just like you can get it to run a telnetd service, you should be able to run '/bin/sh myscript' service. Slide 14: systemd is an Init System systemd is a Platform I am saying that this is not how things are supposed to be done in Unix. I am saying that you are trying to incorporate as much stuff as possible into systemd, and I think it's wrong. [...] I would also add monolithic and inflexible. Sorry. You argue that it should be possible to tailor systemd to bring up a different system than Lennart imagined. It seems to me that it's reasonable that you need a different systemd, then. There are several ways of approaching this, from the most crude to most elegant: - edit the part of systemd where Lennart starts the services and compile your own version - reconfigure via compile-time conditionals - reconfigure at run-time via loadable modules, like the kernel I think that currently systemd is not configurable in the second and third sense. I agree with you that it be more in the Unix way for it to be configurable. I wonder if it's worth the effort to make it run-time configurable, even if it could use some existing run-time modular infrastructure, e.g. from the kernel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, Jun 14, 2011 at 04:36:25PM +0200, Kevin Kofler wrote: Miroslav Lichvar wrote: I think the console-kit-daemon service can be disabled, but xinit prefixes xsession with ck-xinit-session which seems to start the daemon on demand. It would be nice if xinit could be configured to not use it. ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able to access your hardware without it. You can still manage permissions of the devices by other means, which may fit better your use cases. I have edited the xinitrc-common script, but it's not marked as config, so the change is lost after every xorg-x11-xinit update. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Am 14.06.2011 16:36, schrieb Kevin Kofler: Miroslav Lichvar wrote: I think the console-kit-daemon service can be disabled, but xinit prefixes xsession with ck-xinit-session which seems to start the daemon on demand. It would be nice if xinit could be configured to not use it. ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able to access your hardware without it so tell me why our main server runs without even for usb-devices? fedora 9 - 14 /etc/rc.local # nobody needs killall console-kit-daemon 2 /dev/null /dev/null [root@arrakis:~]$ ps aux | grep -i console root 13685 0.0 0.0 105440 864 pts/1S+ 17:36 0:00 grep --color -i console signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Denys Vlasenko (dvlas...@redhat.com) said: In this case you are not better/worse than before, once the network will come up you'll add a script to change the hostname. Setting it earlier in systemd makes no difference. You continue to avoid answering my question: WHY systemd, a service management tool, bothers with setting hostname? It's not its task! It's part of the task of booting the system. For example, rc.sysinit, in order: 1) mount assorted psuedo-filesystems 2) print a welcome message 3) start udev a.) set clock b.) initialize console settings c.) bring up loopback 4) load ancient legacy module scripts 5) run sysctl 6) set hostname ... whole bunch of other stuff after this elided ... None of these were user-modifiable actions; attempting to change any of these is a void-your-warranty-you-get-all-pieces action. So, in migrating to systemd, we have an opportunity to examine each of these actions that's done at boot, and decide the most appopriate place for it. For the above items, 1, 2, 3a, 3c, and 6 are done in systemd itself. 3, 3b, 4, and 5 are done as standard systemd units. If you're seriously arguing that we should have instead made all these things configurable, I'm not really interested - they weren't before, and making them configurable isn't really useful for making a standardized OS platform. If you want to discuss which is done in which place during startup, we can do that, but at that point we're arguing over details which aren't all that relevant. Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. It's a needless pejorative, yes. But it doesn't change the fact that shell is highly overused in our prior boot process. ~1000 lines of initscripts + functions to cover what is essentially 'exec atd' is overkill, and isn't really needed. Slide 79: Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots, cryptsetup, ... That's what I refer to by taking over the world. Yes, it's obviously taking over the world by: - changing where fsck is called from point A to point B - changing where mount is called from point A to point B - loading policy from init, *just as it was with SysVinit* - adding features to support initrd-less boots (which we didn't have before) - handling shutdown (WTF is your init system supposed to do if not this?) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 10:21 -0400, Simo Sorce wrote: On Tue, 2011-06-14 at 14:08 +0200, Lennart Poettering wrote: On Tue, 14.06.11 07:25, Simo Sorce (s...@redhat.com) wrote: What's the problem of having a specific hostname set up at boot time ? The user might want to change it? Does setting it at boot time prevent you from changing it later ? No, systemd will initialize it at boot and is happy if you change it later. As I thought, then I see no problem here. systemd might be happy if you change it later, but other stuff is not. The canonical example is X, where the hostname was used as the xauth key to allow you to actually talk to the X server. When the hostname changed, there was no authorization for the new hostname in your xauth file, so starting new apps would silently fail. Basing *anything* like that on your machine hostname is just stupid. It might work for you, but it doesn't work for lots of other people, so lets fix it for everyone. And we did back in the F10 timeframe with /etc/X11/xinit/xinitrc.d/localuser.sh where we just let any local user connect, since that's exactly what xauth's hostname thing was supposed to do anyway. The next example is apps that try to find out your IP address by looking up your hostname. That's completely broken too. Do you have multiple interfaces? Multiple IP addresses? Are you behind NAT? Yeah, all that will torpedo hostname-IP lookups. Hostnames are *informational* and are never a good way to identify anything concrete on a local machine. That didn't used to be the case, but now it is. Things change in 40 years. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, 10.06.11 15:07, Denys Vlasenko (dvlas...@redhat.com) wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. As pointed out elsewhere, this is mostly the SELinux policy, and definitely something we can optimize in one way or another. I understand your desire to replace everything by systemd. I have no such desire. I really do. syslogd, klogd, mount, fsck, and a dozen other things We don't replace syslogd, klogd, mount, fsck and dozen of other things. Now I hear about plans to incorporate ConsoleKit into it (hearsay, so maybe it's not true). Yes, systemd as a platform will include a tiny daemon which takes over the role of CK. Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? libattr? Does it mean it requires filesystem which implements extended attributes? If not, why does it use libattr then? libaudit? What systemd has in common with audit? Michal already answered these questions, so I am not going to repeat this here. libwrap? systemd is a network application now too? Yupp, Google for socket activation systemd. libdbus?... this is a lost battle I guess... Yupp, since Upstart used that already since ages. I propose to stop for a second and optimize systemd down instead of trying to add even more bells and whistles to it. Or else you'll soon end up linking against every /lib/lib*.so* I think systemd is much more optimized that what existed previously. (what else is parallelization but optimization?) I bet with you that a systemd system (modulo SELinux) can be built in a way that uses much less resources and boot time than one built on Upstart. (How? We simply spawn shell (or even zero) shells and other interpretors, and start a number of seldom-things only when needed and the rest in parallel). It is an *init replacement*, not the replacement for everything. I like to see it as a modular platform to build an OS from. It includes an init system and a few auxiliary tools (readahead for example, and C implementations of the basic boot scripts). Every new feature you add and library you link against works against that goal. Nah, don't think so. We have fewer deps, and less dependencies than the equivalent Upstart- and shell based boot. It is my intention to minimize the minimum set of packages you need to bootstrap a Linux system. While the systemd package might get a bit bigger than sysvinit through that -- *overall* you get a much smaller and simpler system, build from a much smaller number of source packages. That saves resources, makes things simpler and faster. To be honest, I doubt the wisdom of implementing service manager as an init process. There is no inherent reason why it has to be init - you can run it as *a child of init*, and keep init very simple. No, that would complicate things for little reason. I find a system whose PID after boot is in the 500 range much simpler and leaner than one that is in the 5000 range. Then, if service manager would crash, at least it doesn't take system down with it... If systemd crashes it will freeze, but not take the system down. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, 10.06.11 18:58, Denys Vlasenko (dvlas...@redhat.com) wrote: On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote: On 06/10/2011 03:59 PM, Steve Clark wrote: On 06/10/2011 09:36 AM, Michal Schmidt wrote: systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. ^^^ So you just end up with a froze system instead of a crashed system No, only systemd freezes itself. Other processes continue running. systemd-26/src/main.c::crash() is the function which does it. Assuming it will not recurse by crashing again, of course. It calls log_error and assert_se, which go into log_dispatch(), which logs to syslog, may try to write to klog, and whatnot... this doesn't look too robust to me. But anyway. Assuming it successfully froze. Does it help? Yes. How much? Well, it's better than instant oops which happens when PID 1 exits, but reaping of processes reparented to init will stop, which, for example, makes the hang from pid exhaustion just a question of time. Ultimately, this stems from the decision to make systemd to run as PID 1 process. Are there technical reasons for this? Yupp, if we oops the kernel all processes are aborted at the same time. If we just freeze systemd they can still be shutdown cleanly and everything synced to disk. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Hi Lennart,
On Mon, 2011-06-13 at 10:15 +0200, Lennart Poettering wrote:
On Fri, 10.06.11 15:07, Denys Vlasenko (dvlas...@redhat.com) wrote:
I understand your desire to replace everything by systemd.
I have no such desire.
What is this then?
int main(int argc, char *argv[]) {
...
if (arg_running_as == MANAGER_SYSTEM !serialization) {
locale_setup();
if (arg_show_status || plymouth_running()) == ??
status_welcome();
kmod_setup(); === ???
hostname_setup(); === ???
machine_id_setup(); === ???
loopback_setup();
test_mtab();
test_usr();
test_cgroups();
}
plymouth_running()? Plymouth? Systemd knows about plymouth? Why?
This is an antithesis to modular, Unix way of doing things.
It starts to have shadows of monolithic Windows-like
we know better than you what you need approach.
hostname_setup()?
machine_id_setup()? Why systemd has *source-code-level knowledge*
about it? I would say that if admin wants to have /etc/machine-id,
he can set up startup code to generate it.
For one, I had no /etc/machine-id on machines I was administering
for decades, with no ill effects. I don't want init to know better
than me what I want to have.
kmod_setup() loads autofs4, ipv6 and unix modules.
Why? What if I don't want to run automounter?
systemd will force me to do so?
Why it (a *program*) took upon itself to decide what modules should
be running? There decisions are traditionally up to *humans*
in Unix world.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
We don't replace syslogd, klogd, mount, fsck and dozen of other things.
What is /lib/systemd/systemd-fsck then?
/lib/systemd/systemd-logger?
(Also, most of them don't emit useful info on --help...)
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).
Yes, systemd as a platform will include a tiny daemon which takes over
the role of CK.
That's what I was referring to by taking over the world.
Today I can remove CK from my Fedora install if I want to.
If it goes into systemd, I will be unable to do so.
Yet another bit of freedom taken away.
I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*
I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart.
I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.
(How?
We simply spawn shell (or even zero) shells and other interpretors, and
start a number of seldom-things only when needed and the rest in
parallel).
Optimizing towards not spawning shell at all is a strange optimization
target. Reducing the need to spawn shells - yes, eliminating - no.
It is an *init replacement*, not the replacement for everything.
I like to see it as a modular platform to build an OS from.
That's what I was referring to by taking over the world.
It includes an
init system and a few auxiliary tools (readahead for example, and C
implementations of the basic boot scripts).
Readahead is a band aid for stuff which is bloated enough
to affect boot by sheer amount of necessary reading.
I don't say others must not use it, but I would like to be able
to switch it off. (For one, it makes bloat more noticeable,
so I can see what needs fixing.)
As I said, freedom to do things as admin wants
is important trait of Unix way.
C implementation of shell scripts tends to be too rigid.
I don't see why you are trying to do that.
If it because bash startup time is too long, I have
a few faster shells for you...
Every new feature you add and library you link against
works against that goal.
Nah, don't think so. We have fewer deps, and less dependencies than the
equivalent Upstart- and shell based boot.
Competing with Upstart is easy :)
It is my intention to minimize
the minimum set of packages you need to bootstrap a Linux system. While
the systemd package might get a bit bigger than sysvinit through that --
*overall* you get a much smaller and simpler system, build from a much
smaller number of source packages. That saves resources, makes things
simpler and faster.
Everyone who likes coding thinks that his favorite package is great.
I have no doubt that you are proud of systemd. It actually isn't
a bad software.
However, allow me to have a not completely rosy view of it either.
Saves resources is not exactly true, as I see it,
on memory consumption front.
To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no
Re: systemd: please stop trying to take over the world :)
On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering mzerq...@0pointer.de wrote: plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. The long-term question here is what happens when Plymouth is replaced by something different, first in one specialist distribution, later by one major distribution (perhaps Fedora), and only much later by most distributions?. Will systemd only support the new thing, forcing the slower distributions to backport patches? Will systemd support both systems, and over time become burdened with compatibility code? Something else? Historically, each distribution had its own system integration scripts that supported only the tools the distribution cared about, so there never was a single project fighting with the matrix of N distributions x M implementations of major features. What is /lib/systemd/systemd-fsck then? A wrapper, which handles the exit code and reacts properly to it. (Also, most of them don't emit useful info on --help...) They aren't user binaries. They are in /lib/systemd, not /usr/bin... But they do implement user-visible functionality, and have user-visible /proc/cmdline options. Yes, old initscripts didn't document the behavior either, but the sysadmin (who, for better or worse, pretty much has to be able to read shell code) could find them and could understand and debug the boot process by reading /etc/rc.*. I think that asking the sysadmin to read the C code of systemd to understand the boot process and how it can be configured is rather excessive. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: On Mon, 13.06.11 15:27, Denys Vlasenko (dvlas...@redhat.com) wrote: kmod_setup(); === ??? We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. You assume that everyone uses IPv6. This is not true. hostname_setup(); === ??? We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? machine_id_setup(); === ??? Similar to the hostname we ensure that the machine id is always initialized, and has the same lifetime and validity guarantees as the hostname. i.e. that it is simply usable by *every* process started, regardless when. Point me at one program which uses machine id. I never saw one. And anyway, why do you set up stuff no one asked you to? plymouth_running()? Plymouth? Systemd knows about plymouth? Why? Because we need to constantly send updates to it. It's a trivial socket operation. It's a trivial thing and spawning a separate process to send those updates each and every single time is a major waste of resources and basically doubles the processes we have to spawn at boot. Plymouth is not a part of Unix. Init process has no business knowing about distro specific stuff like that. This is an antithesis to modular, Unix way of doing things. Just because you can turn each trivial operation into a separate binary you shouldn't necessarily do that. Where did I propose turning everything into a separate binary? It is what makes your system slow and heavy-weight. Insisting that we invoke sethostname() in a separate process is just stupid. I am mean, come on, think about it. It is *ONE* system call to the the hostname with sethostname(). Invoking /bin/hostname instead is at least 40 or so (and many of those quite heavy weight). And really, why are we even discussing the frickin hostname like this? Because it's a perfect example of a thing init process has no business doing. Ever. The lightness of the syscall is irrelevant. For example, you also do modprobing of various things, which is far from being just one syscall, so this argument is moot. Do you know what mono means? It's greek and means one. And lithic means stone. And if systemd communicates with Plymouth, then this is not monolothic at all, since systemd and ply are two processes, not one. Init process should not have intrinsic knowledge about splash screens! This is basic idea of modularity. This is how Unix always worked. Things should not be *too* interconnected. Things should be modular. In your presentation, you have Integration as slide 17 and Modularization as slide 18. Do you realize that these are the opposite things? More integration means less modularization. You can't have both. systemd is not running Plymouth stuff in the same process, is it merely communicating with it. Thanks that at least for now you don't have plans to incorporate Plymouth. No, systemd tries to load those modules but if you are into retro computing you can still blacklist them using the usual modprobe blacklisting, and systemd will honour that (i.e. by passing -b to modprobe). Why it (a *program*) took upon itself to decide what modules should be running? There decisions are traditionally up to *humans* in Unix world. Nah. udev loads modules automatically. udev loads modules according to config file, not by hard-coding stuff in C code. IOW: udev does not load modules which *udev developer* wants, it loads modules which *admin* wants. (Of course, admin might choose to use standard config, but he does this on his own volition). In fact on almost all systems there should be no need to ever load a module manually. Maybe. It's not up to a piece of software to decide. In Unix, admins should have power to decide, not programs. Programs provide the means, they don't dictate policies. Now I hear about plans to incorporate ConsoleKit into it (hearsay, so maybe it's not true). Yes, systemd as a platform will include a tiny daemon which takes over the role of CK. That's what I was referring to by taking over the world. Well, we simplify things a lot
Re: systemd: please stop trying to take over the world :)
On Mon, Jun 13, 2011 at 06:01:22PM +0200, Denys Vlasenko wrote: On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. You assume that everyone uses IPv6. This is not true. The point of providing a platform is that developers can make certain assumptions about available functionality. It's no longer reasonable to treat IPv6 as an optional part of the internet, any more than it's reasonable to consider IPv4 as optional. But if you don't want it, simply don't build it. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: On Mon, Jun 13, 2011 at 06:01:22PM +0200, Denys Vlasenko wrote: On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: We load a couple of kernel modules which systemd needs, and are sometimes compiled as module only and which cannot be autoloaded for a reason or another. This is ipv6, autofs4, unix.ko, and we load them explicitly so that we can use them. You assume that everyone uses IPv6. This is not true. The point of providing a platform is that developers can make certain assumptions about available functionality. It's no longer reasonable to treat IPv6 as an optional part of the internet, any more than it's reasonable to consider IPv4 as optional. But if you don't want it, simply don't build it. I believe the ipv6 module is going to be built in soon anyway. http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, Jun 13, 2011 at 05:13:39PM +0100, Peter Robinson wrote: On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett mj...@srcf.ucam.org wrote: The point of providing a platform is that developers can make certain assumptions about available functionality. It's no longer reasonable to treat IPv6 as an optional part of the internet, any more than it's reasonable to consider IPv4 as optional. But if you don't want it, simply don't build it. I believe the ipv6 module is going to be built in soon anyway. http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html I'd assumed that Dennis was talking about non-Fedora environments, since ipv6 hasn't been meaningfully optional in Fedora for ages. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, Jun 13, 2011 at 6:18 PM, Denys Vlasenko dvlas...@redhat.com wrote: ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) Maybe if you send me the money first ;) (Sorry for private spam, hit wrong button) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. What's the problem of having a specific hostname set up at boot time ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. What's the problem of having a specific hostname set up at boot time? The problem with having specific hostname I had is when I boot many dozens of diskless machines off the very same network filesystem, I definitely DONT want them to use the same hostname. One method I saw in use in real world in this situation is to assign hostnames by looking up (MAC_address,hostname) pairs in a database (say, a config file), and then set the found hostname. Of course, this is not possible until said database is available over network. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 19:02 +0200, Denys Vlasenko wrote: On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote: On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote: We invoke sethostname() from inside systemd since that is one of the most trivial system calls known to men and doing this with a separate binary is just absurd. This way we also can ensure that the hostname is always initialised which is very useful for early boot logging and other stuff. On systemd you get the guarantee that the hostname is always set up if you run in userspace, You can't possibly know what kind of (possibly dynamic) hostname admin might want to assign to his machine. The static hostname may be as useless as default (none) which is set by kernel. Anyway, logging with default hostname is not a catastrophe. Why do you set up stuff no one asked you to? Changing a machine hostname at random times is just asking for trouble. I just tried it. So far flames don't shoot out of my notebook. What's the problem of having a specific hostname set up at boot time? The problem with having specific hostname I had is when I boot many dozens of diskless machines off the very same network filesystem, I definitely DONT want them to use the same hostname. But until you can get the real one you basically are. One method I saw in use in real world in this situation is to assign hostnames by looking up (MAC_address,hostname) pairs in a database (say, a config file), and then set the found hostname. Of course, this is not possible until said database is available over network. In this case you are not better/worse than before, once the network will come up you'll add a script to change the hostname. Setting it earlier in systemd makes no difference. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, Jun 13, 2011 at 10:33:19AM +0200, Lennart Poettering wrote: Uh, and even much healthier than Upstart, which you seem to be a big fan of. Ohloh lists 3 patch authors. (But I figure that is out-of-date, it cannot be that low) I'm guessing its just ohloh having as much trouble operating launchpad as humans do. I know I have quite a large branch somewhere in there, but it usually takes me a good while to find evidence of it too. In general, though, someone else would have to understand what Upstart is supposed to be in order to contribute code. Since that is explicitly and by choice only documented in Scott's head, its kinda hard to do. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote: Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? More to the point: Lennart can call his program whatever he wants, even Nuclear Submarine. The point is: some people might disagree with having service management tool with Napoleonic aspirations. For one, I do! Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. I think this is the crux of the argument. It seemed to me one of the goals of systemd was to stop having a wide variety of possible mechanisms to do similar things. To intentionally remove the ability to swap out components. Part of that was to make things faster, part of it was to make them simpler (for uses of simpler meaning fewer options). The trick is whether or not you agree with that as a set of goals. If you do not then systemd is not fun and not for you. If you do then you are happy with it. I think the problem I've heard repeatedly is that a fair number of people are surprised how the decisions about those goals were made. I also think that as it becomes more well known: the lack of flexibility in specific places in systemd will be patched out/around. So, the items you're complaining about will become options or configuration items when people with significant-enough clout demand they change. It happens all the time. Some folks adapt to how things are and work with what their given. Others take out a baseball bat and beat things until they work and send their patches along. Others still take out a checkbook and start writing checks or alternatively, refrain from writing those checks. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/13/2011 02:10 PM, seth vidal wrote: On Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote: Slide 14: systemd is an Init System systemd is a Platform systemd is a platform? Really? What next? systemd is an Aircraft Carrier? More to the point: Lennart can call his program whatever he wants, even Nuclear Submarine. The point is: some people might disagree with having service management tool with Napoleonic aspirations. For one, I do! Slide 50: Shell is evil Move to systemd, daemons, kernel, udev, ... Again, shell, a tool which endured for 40+ years, is suddenly evil. I don't think this being the consensus. I think this is the crux of the argument. It seemed to me one of the goals of systemd was to stop having a wide variety of possible mechanisms to do similar things. To intentionally remove the ability to swap out components. Part of that was to make things faster, part of it was to make them simpler (for uses of simpler meaning fewer options). The trick is whether or not you agree with that as a set of goals. If you do not then systemd is not fun and not for you. If you do then you are happy with it. I think the problem I've heard repeatedly is that a fair number of people are surprised how the decisions about those goals were made. I also think that as it becomes more well known: the lack of flexibility in specific places in systemd will be patched out/around. So, the items you're complaining about will become options or configuration items when people with significant-enough clout demand they change. -sv Coming out of pure lurk mode - I think Seth's observations here are true for a many of the things that have gone on in Fedora recently (at the risk of opening wounds... eg. gnome3). Your options are: 1) Complain 2) Get involved in the development to the point where you are one of those with enough clout to 'demand change' - or at least do 1) with some concrete technical observations as devoid as possible of vitriol and anger, at which point Complain would no longer really be the correct term. 3) Quietly move on to something more suited to your needs. For my part I've chosen 3). My servers have always run Scientific Linux and I've migrated my laptop to SL6 rather than F15. My desktops and those of my users have been updated to F14, though I'll 'support' F15 for those who want to pursue that upgrade path. In the F14 EOL time frame, I'll re-evaluate F16 wrt whether some of my issues with F15 have been patched out/around and make a decision as to whether to fully migrate away from Fedora at that point. As a pure consumer of the product without the time to get involved with 2), I don't think it's my place to pursue 1), nor would it be very productive. If you choose to pursue 1), I think you'd have more success and have a more productive hearing if you were to also engage in 2). To pursue only 1), as many seem to, will only lead to bad blood and a sore head as you continue to bang it into that tree. To emphasize, this is not intended as a complaint or a flame towards those working on Fedora development - just an observation on where time might be more productively spent for those who have a problem with certain components/development directions in Fedora. Returning to lurk mode, -Karl -- | Karl A. Misselt Office: Steward 254 | | Steward Observatory Phone: 520-626-0196 | | University of Arizona FAX: 520-621-9555 | | Tucson, AZ 85721-0065 miss...@as.arizona.edu | |Malo Periculosam Libertatem Quam Quietum Servitium| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Karl Misselt wrote: Coming out of pure lurk mode - I think Seth's observations here are true for a many of the things that have gone on in Fedora recently (at the risk of opening wounds... eg. gnome3). If GNOME 3 is your problem, try KDE Plasma or Xfce. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote: On Mon, 2011-06-13 at 13:30 -0400, Simo Sorce wrote: What's the problem of having a specific hostname set up at boot time? The problem with having specific hostname I had is when I boot many dozens of diskless machines off the very same network filesystem, I definitely DONT want them to use the same hostname. But until you can get the real one you basically are. Yes, and as far as it is a temporary condition for a few seconds at boot, it's not a problem. So why the rush to set it as soon as possible via systemd? Seriously, what are you arguing about ? It is so simple to set it via systemd and it *is* an init task that it just fine to set it in there so all process will just have the right answer from the get go. Unless there is a *problem* with doing it early I really don't want to get int the bike shedding here. One method I saw in use in real world in this situation is to assign hostnames by looking up (MAC_address,hostname) pairs in a database (say, a config file), and then set the found hostname. Of course, this is not possible until said database is available over network. In this case you are not better/worse than before, once the network will come up you'll add a script to change the hostname. Setting it earlier in systemd makes no difference. You continue to avoid answering my question: WHY systemd, a service management tool, bothers with setting hostname? It's not its task! Because it *is* a system initialization task, and systemd can do it better than a shell script called in a random order later on, without, as far as I can see, any side effects in this case. I wouldn't bother much if it would be just one tiny bit of strange code in systemd, but it is FAR from being the only such code. There are lots of similar stuff, and it's not accidental. It is definitely not accidental, but unless you have bugs to file, I don't think complain generically about systemd architecture here is any productive. We discussed systemd for quite a while here and it certainly far from perfect, for some things probably not even good yet. But its time to file bugs for real problems, not time for bike shedding on architectural decision that have been taken quite a while ago, unless you want to argue for getting rid of it completely and reverting back to the previous init mechanism. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Sun, Jun 12, 2011 at 6:42 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Sat, Jun 11, 2011 at 12:03:33PM +0100, Peter Robinson wrote: for decades. Fedora 14's init system isn't that different to the first version of RHL (4.0) I started using back in 96. This is somewhat misleading. There have been many rewrites of the init system in the past decade. In fact, the Fedora 14 init system has the capability to be quite different than the SysVinit scripts that were adopted in the mid-90s. What is true is that Fedora 14 had not switched to using the incompatible-with-SysVinit features of its default (or any of its optional) init systems so the presentation and behaviour was almost the same as older SysVinit. That's true but due to the way we used it upstart was more or less a renamed sysVinit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Sun, Jun 12, 2011 at 08:19:03AM +0200, drago01 wrote: On Sun, Jun 12, 2011 at 6:42 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Sat, Jun 11, 2011 at 12:03:33PM +0100, Peter Robinson wrote: for decades. Fedora 14's init system isn't that different to the first version of RHL (4.0) I started using back in 96. This is somewhat misleading. There have been many rewrites of the init system in the past decade. In fact, the Fedora 14 init system has the capability to be quite different than the SysVinit scripts that were adopted in the mid-90s. What is true is that Fedora 14 had not switched to using the incompatible-with-SysVinit features of its default (or any of its optional) init systems so the presentation and behaviour was almost the same as older SysVinit. That's true but due to the way we used it upstart was more or less a renamed sysVinit. Which is what I said in my last sentence, yes? ;-) I wanted to clarify that there have been a lot of new, rewritten init systems in the Linux ecosystem in the past decade, including upstart. It's just the Fedora default init system that's been an old fuddy-duddy about adopting any of the rewritten-requiring features until now. -Toshio pgprGP1DjmOBj.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Sun, Jun 12, 2011 at 6:01 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Sun, Jun 12, 2011 at 08:19:03AM +0200, drago01 wrote: On Sun, Jun 12, 2011 at 6:42 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Sat, Jun 11, 2011 at 12:03:33PM +0100, Peter Robinson wrote: for decades. Fedora 14's init system isn't that different to the first version of RHL (4.0) I started using back in 96. This is somewhat misleading. There have been many rewrites of the init system in the past decade. In fact, the Fedora 14 init system has the capability to be quite different than the SysVinit scripts that were adopted in the mid-90s. What is true is that Fedora 14 had not switched to using the incompatible-with-SysVinit features of its default (or any of its optional) init systems so the presentation and behaviour was almost the same as older SysVinit. That's true but due to the way we used it upstart was more or less a renamed sysVinit. Which is what I said in my last sentence, yes? ;-) Oh indeed ... probably a case of -E_NOCOFFEE ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, 10 Jun 2011 18:42:11 +0200 Denys Vlasenko wrote: On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote: Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? to implement PAMName= (man systemd.exec) I don't see any users of this feature on my F15. I searched with Google and come up empty too. But anyway, assuming it's a useful feature, why it has to be done by systemd? A nice property of systemd is that it takes care of setting up the environment for each service. PAMName can be considered one of the pieces of the environment. It is expected that services will eventually start taking advantage of it and cease to implement these things themselves. It makes them simpler. See http://0pointer.de/public/systemd-man/daemon.html for how new-style daemons are made simpler. libwrap? systemd is a network application now too? to implement TCPWrapName= (man systemd.exec) Again, why it has to be done *by systemd*? As systemd takes away the responsibility of creating sockets from the services when it offers socket activation, it makes sense to offer the option to filter the activation requests using libwrap. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 11 Jun 2011 03:35, Rahul Sundaram methe...@gmail.com wrote: On 06/11/2011 05:20 AM, Genes MailLists wrote: Lets be blunt here - he pushed very very very hard on these very lists to get systemd in - now its in F15 and there are problems - so no punting please. Upstream and fedora are the same for syste That is a gross over simplification. Fedora is just one of the many distros integrating systemd and there are developers from other distros including Novell involved in systemd and contributing to it. If we start discussing every project where Red Hat is heaving involved, that list is long [1] Yes he spoke with another distro - but no-one is using it. So its a fedora only project until its picked up somewhere else - which has not happened yet. That's not true. Mandriva 2011 is already including it by default. So is MeeGo. actually meego will only ship it in 1.3 which will be out around the time of f16 Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. ~11MB equals ~8 cents of RAM ... so meh. If that's all you have to worry about its a good indication that they aren't any real problems ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Sat, Jun 11, 2011 at 9:17 AM, drago01 drag...@gmail.com wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. ~11MB equals ~8 cents of RAM ... so meh. If that's all you have to worry about its a good indication that they aren't any real problems ;) 11Mb on a device that may only have 256 such as an XO-1 or a phone or some other ARM based device is actually quite a bit, over 4% in fact. 8c x 2.5m devices is around $200K. While 4Gb is pretty standard in laptops, and 1Tb isn't uncommon in servers now days there are also 100s of devices that run linux in a whole lot less than that. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Sat, Jun 11, 2011 at 12:50 AM, Genes MailLists li...@sapience.comwrote: On 06/10/2011 03:13 PM, Rahul Sundaram wrote: what would be really nice is to redirect systemd discussions to its upstream mailing list. Fedora devel is hardly the best place for it. Rahul Beg to differ - rather vehemently too - politely but vehemently. systemd is only available in fedora[1] - we are the test pigs for better or for worse - and there are most certainly bugs in fedora's systemd. Both opensuse and meego are moving to it currently and it will be in their next releases. Fedora being the first isn't surprising as Red Hat employed people are the leads on the project and its one of our four foundations. I would be be very surprised if there weren't bugs, its the first rewrite of the init system for decades. Fedora 14's init system isn't that different to the first version of RHL (4.0) I started using back in 96. Lets be blunt here - he pushed very very very hard on these very lists to get systemd in - now its in F15 and there are problems - so no punting please. Upstream and fedora are the same for systemd. Not sure what your point is here. Some bugs like sendmail failing to start have been there since September 2010 ( almost 9 months ... ) - people are reporting the same issue on F15 in the fedora lists ... who is fixing this stuff ? e.g. https://bugzilla.redhat.com/show_bug.cgi?id=692008 https://bugzilla.redhat.com/show_bug.cgi?id=633774 Reading through both of those bugs they both look to be a regression in the handling of NetworkManager dispatcher scripts [1] which are now fixed and should be in stable [2] since 2nd June have you bothered to test this and update the bugs? Its unfortunate the problem with the dispatcher scripts wasn't picked up prior to release but the bug was fixed upstream by the NM maintainer in a day once it was reported [3]. Ok so he's on vacation - this is a very core part of the OS - who is backing him up I wonder? Who else is on the project? A number of people, but as pointed out above its not necessarily always systemd's fault. System startup is a complex process and has a lot of interdependencies. Surely you're not saying there is no-one else working on systemd... and when LP is away/busy nothing will get done ... otherwise I strongly urge it be replaced by upstart asap. That's certainly not the case, you only have to look as far as the upstream mailing list to see that. The fact that Ubuntu is the only project now sticking with upstart (and i believe it was actually used by Fedora in a mainline release first too) shows its uptake. A lot of projects will have a lead architect that is the main driving force behind the project in the early stages of the project, systemd is certainly not alone here. In fact if you bothered to go and look at upstart I think you'll find its the same there, and what's more with everyone moving to systemd there's likely a lot less people working on upstart. Peter [1] https://bugzilla.redhat.com/show_bug.cgi?id=703321 [2] https://admin.fedoraproject.org/updates/NetworkManager-0.8.9997-1.git20110531.fc15 [3] https://bugzilla.gnome.org/show_bug.cgi?id=649773 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Sat, Jun 11, 2011 at 12:03:33PM +0100, Peter Robinson wrote: for decades. Fedora 14's init system isn't that different to the first version of RHL (4.0) I started using back in 96. This is somewhat misleading. There have been many rewrites of the init system in the past decade. In fact, the Fedora 14 init system has the capability to be quite different than the SysVinit scripts that were adopted in the mid-90s. What is true is that Fedora 14 had not switched to using the incompatible-with-SysVinit features of its default (or any of its optional) init systems so the presentation and behaviour was almost the same as older SysVinit. -Toshio pgpiCY2Gmt5D6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 03:07 PM, Denys Vlasenko wrote: I understand your desire to replace everything by systemd. I really do. syslogd, klogd, mount, fsck, and a dozen other things I forget or don't know. You're exaggerating. Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? to implement PAMName= (man systemd.exec) libattr? Does it mean it requires filesystem which implements extended attributes? If not, why does it use libattr then? systemd uses libcap. libcap depends on libattr. libwrap? systemd is a network application now too? to implement TCPWrapName= (man systemd.exec) libaudit? What systemd has in common with audit? Start and stop of a service is an auditable event. http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html To be honest, I doubt the wisdom of implementing service manager as an init process. There is no inherent reason why it has to be init - you can run it as *a child of init*, and keep init very simple. Then, if service manager would crash, at least it doesn't take system down with it... systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 09:36 AM, Michal Schmidt wrote: On 06/10/2011 03:07 PM, Denys Vlasenko wrote: I understand your desire to replace everything by systemd. I really do. syslogd, klogd, mount, fsck, and a dozen other things I forget or don't know. You're exaggerating. Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? to implement PAMName= (man systemd.exec) libattr? Does it mean it requires filesystem which implements extended attributes? If not, why does it use libattr then? systemd uses libcap. libcap depends on libattr. libwrap? systemd is a network application now too? to implement TCPWrapName= (man systemd.exec) libaudit? What systemd has in common with audit? Start and stop of a service is an auditable event. http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html To be honest, I doubt the wisdom of implementing service manager as an init process. There is no inherent reason why it has to be init - you can run it as *a child of init*, and keep init very simple. Then, if service manager would crash, at least it doesn't take system down with it... systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. ^^^ So you just end up with a froze system instead of a crashed system Michal -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 09:07 AM, Denys Vlasenko wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. systemctl --all shows 258 units total on my machine, thus systemd uses ~40 *KILO*bytes of state per unit? I understand your desire to replace everything by systemd. I really do. syslogd, klogd, mount, fsck, and a dozen other things I forget or don't know. It's called featuritis. Now I hear about plans to incorporate ConsoleKit into it (hearsay, so maybe it's not true). Look where it is now: Top: Mem total:2035840 anon:431208 map:78924 free:419084 slab:91624 buf:108040 cache:942336 dirty:196 write:0 Swap total:4095996 free:4095996 PID VSZ VSZRW RSS (SHR)*DIRTY (SHR) STACK COMMAND 1818 624m 365m 185m 13472 155m64 224 /usr/lib/firefox-4/firefox 1816 433m 189m 166m 17248 142m 0 204 evolution 1257 53672 40400 22664 6004 18336 4176 132 /usr/bin/Xorg 1 15384 11856 13664 1340 11752 0 132 /sbin/init ^ ^ 11.7 megs of malloc space 1839 275m 40224 24208 10572 11020 0 132 /usr/bin/gnome-terminal 1713 202m 45284 20308 9736 9604 576 132 /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin 1843 171m 9448 20264 10012 8440 344 204 xchat 1770 152m 55672 19412 10972 6108 0 132 nautilus It's the *fourth* largest process on my system! # ldd `which systemd` linux-gate.so.1 = (0x00a6b000) libselinux.so.1 = /lib/libselinux.so.1 (0x414f6000) libdbus-1.so.3 = /lib/libdbus-1.so.3 (0x41bc1000) libpthread.so.0 = /lib/libpthread.so.0 (0x0019a000) libudev.so.0 = /lib/libudev.so.0 (0x422c9000) libwrap.so.0 = /lib/libwrap.so.0 (0x420fa000) libpam.so.0 = /lib/libpam.so.0 (0x420e6000) libaudit.so.1 = /lib/libaudit.so.1 (0x420cc000) libcap.so.2 = /lib/libcap.so.2 (0x4152f000) librt.so.1 = /lib/librt.so.1 (0x00be8000) libc.so.6 = /lib/libc.so.6 (0x00295000) /lib/ld-linux.so.2 (0x00276000) libdl.so.2 = /lib/libdl.so.2 (0x00af6000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x00f68000) libnsl.so.1 = /lib/libnsl.so.1 (0x0095c000) libattr.so.1 = /lib/libattr.so.1 (0x420c5000) Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? libattr? Does it mean it requires filesystem which implements extended attributes? If not, why does it use libattr then? libwrap? systemd is a network application now too? libaudit? What systemd has in common with audit? libdbus?... this is a lost battle I guess... I propose to stop for a second and optimize systemd down instead of trying to add even more bells and whistles to it. Or else you'll soon end up linking against every /lib/lib*.so* At the very least, I would like to see its memory consumption to go down substantially. It is an *init replacement*, not the replacement for everything. One of init's goal is to be *simple* and *stable*. Every new feature you add and library you link against works against that goal. To be honest, I doubt the wisdom of implementing service manager as an init process. There is no inherent reason why it has to be init - you can run it as *a child of init*, and keep init very simple. Then, if service manager would crash, at least it doesn't take system down with it... Yes, whatever happened to the *NIX philosophy of simple non-complex programs that did their job well. It has seemed to serve well since the 70's. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 03:59 PM, Steve Clark wrote: On 06/10/2011 09:36 AM, Michal Schmidt wrote: systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. ^^^ So you just end up with a froze system instead of a crashed system No, only systemd freezes itself. Other processes continue running. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote: Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? to implement PAMName= (man systemd.exec) I don't see any users of this feature on my F15. I searched with Google and come up empty too. But anyway, assuming it's a useful feature, why it has to be done by systemd? I looked at implementation. systemd-26/src/execute.c::setup_pam(): /* We set up PAM in the parent process, then fork. The child * will then stay around until killed via PR_GET_PDEATHSIG or * systemd via the cgroup logic. It will then remove the PAM * session again. The parent process will exec() the actual * daemon. We do things this way to ensure that the main PID * of the daemon is the one we initially fork()ed. */ I don't see any attempt to free at least something in the child. So, systemd forks a process with eleven megabyte of malloced stuff to act just as a babysitter - wait for parent to die, call pam_end, exit? For how long will it hang around in the system - possibly days? Yes, COW, so not all of these eleven megabytes will be around... ...at first, until parent execs, or modifies sufficiently many pages so that most of them are copied. But memory consumption is not really the gist of my argument, it's: why systemd tries to be all things for all people? Why it has to care about PAM? I think most tools which need it do it themselves, and we can write a small, really small helper for those which don't. libwrap? systemd is a network application now too? to implement TCPWrapName= (man systemd.exec) Again, why it has to be done *by systemd*? On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote: Yes, whatever happened to the *NIX philosophy of simple non-complex programs that did their job well. It has seemed to serve well since the 70's. Exactly my point. -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote: On 06/10/2011 03:59 PM, Steve Clark wrote: On 06/10/2011 09:36 AM, Michal Schmidt wrote: systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. ^^^ So you just end up with a froze system instead of a crashed system No, only systemd freezes itself. Other processes continue running. systemd-26/src/main.c::crash() is the function which does it. Assuming it will not recurse by crashing again, of course. It calls log_error and assert_se, which go into log_dispatch(), which logs to syslog, may try to write to klog, and whatnot... this doesn't look too robust to me. But anyway. Assuming it successfully froze. Does it help? Yes. How much? Well, it's better than instant oops which happens when PID 1 exits, but reaping of processes reparented to init will stop, which, for example, makes the hang from pid exhaustion just a question of time. Ultimately, this stems from the decision to make systemd to run as PID 1 process. Are there technical reasons for this? -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 08:42 PM, Denys Vlasenko wrote: On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote: Why does systemd link against libpam? systemd does logins now, not /bin/login or gdm or ...? to implement PAMName= (man systemd.exec) I don't see any users of this feature on my F15. I searched with Google and come up empty too. But anyway, assuming it's a useful feature, why it has to be done by systemd? I looked at implementation. systemd-26/src/execute.c::setup_pam(): /* We set up PAM in the parent process, then fork. The child * will then stay around until killed via PR_GET_PDEATHSIG or * systemd via the cgroup logic. It will then remove the PAM * session again. The parent process will exec() the actual * daemon. We do things this way to ensure that the main PID * of the daemon is the one we initially fork()ed. */ I don't see any attempt to free at least something in the child. So, systemd forks a process with eleven megabyte of malloced stuff to act just as a babysitter - wait for parent to die, call pam_end, exit? For how long will it hang around in the system - possibly days? Yes, COW, so not all of these eleven megabytes will be around... ...at first, until parent execs, or modifies sufficiently many pages so that most of them are copied. But memory consumption is not really the gist of my argument, it's: why systemd tries to be all things for all people? Why it has to care about PAM? I think most tools which need it do it themselves, and we can write a small, really small helper for those which don't. libwrap? systemd is a network application now too? to implement TCPWrapName= (man systemd.exec) Again, why it has to be done *by systemd*? On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote: Yes, whatever happened to the *NIX philosophy of simple non-complex programs that did their job well. It has seemed to serve well since the 70's. Exactly my point. It looks like it is the right time to think about upstart again. I will definitely check it out on rawhide. Thanks to OP for pointing on some difficulties. More important that it will be not so easy to clean that all up latter and we will get eventually unmanageable windows. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 9:07 AM, Denys Vlasenko dvlas...@redhat.com wrote: It's the *fourth* largest process on my system! # ldd `which systemd` 1) Looking at what libraries a binary links to a is a terrible way to optimize memory usage; try massif, say 2) It'd be a lot more productive to be positive and not phrase your message in such an antagonistic way (in fact, this message would probably be better on the systemd-devel mailing list) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 5:58 PM, Denys Vlasenko dvlas...@redhat.com wrote: On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote: On 06/10/2011 03:59 PM, Steve Clark wrote: On 06/10/2011 09:36 AM, Michal Schmidt wrote: systemd does not take the system down when it crashes. It catches the signal, dumps core and freezes, but does not exit. ^^^ So you just end up with a froze system instead of a crashed system No, only systemd freezes itself. Other processes continue running. systemd-26/src/main.c::crash() is the function which does it. Assuming it will not recurse by crashing again, of course. It calls log_error and assert_se, which go into log_dispatch(), which logs to syslog, may try to write to klog, and whatnot... this doesn't look too robust to me. But anyway. Assuming it successfully froze. Does it help? Yes. How much? Well, it's better than instant oops which happens when PID 1 exits, but reaping of processes reparented to init will stop, which, for example, makes the hang from pid exhaustion just a question of time. Ultimately, this stems from the decision to make systemd to run as PID 1 process. Are there technical reasons for this? Would be nice to see the systemd author join this discussion? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/11/2011 12:36 AM, mike cloaked wrote: Would be nice to see the systemd author join this discussion? I am sure you can get answers when someone is off vacation. However what would be really nice is to redirect systemd discussions to its upstream mailing list. Fedora devel is hardly the best place for it. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 8:13 PM, Rahul Sundaram methe...@gmail.com wrote: On 06/11/2011 12:36 AM, mike cloaked wrote: Would be nice to see the systemd author join this discussion? I am sure you can get answers when someone is off vacation. However what would be really nice is to redirect systemd discussions to its upstream mailing list. Fedora devel is hardly the best place for it. Rahul OK I guess we'll get more discussion when he comes back from his holiday - sorry I was unaware of the vacation but thanks for clarifying. I guess that your reference to moving to upstream indicates that systemd is now sufficiently established that discussion of problems is an upstream issue for bug triage/fixing? I would imagine that the user list may have useful exchanges too but that it would be important to get any issues moved upstream from there too? The most important outcome is that bugs are fixed so whatever route is best for that (including bugzilla of course) users should add input to. Hence links to upstream for systemd are made available so that the best exposure to recourse to resolution is optimised? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 9:44 PM, mike cloaked mike.cloa...@gmail.com wrote: I guess that your reference to moving to upstream indicates that systemd is now sufficiently established that discussion of problems is an upstream issue for bug triage/fixing? I would imagine that the user list may have useful exchanges too but that it would be important to get any issues moved upstream from there too? The most important outcome is that bugs are fixed so whatever route is best for that (including bugzilla of course) users should add input to. Hence links to upstream for systemd are made available so that the best exposure to recourse to resolution is optimised? I also presume that by upstream you are referring to http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 04:44 PM, mike cloaked wrote: On Fri, Jun 10, 2011 at 8:13 PM, Rahul Sundarammethe...@gmail.com wrote: On 06/11/2011 12:36 AM, mike cloaked wrote: Would be nice to see the systemd author join this discussion? I am sure you can get answers when someone is off vacation. However what would be really nice is to redirect systemd discussions to its upstream mailing list. Fedora devel is hardly the best place for it. Rahul OK I guess we'll get more discussion when he comes back from his holiday - sorry I was unaware of the vacation but thanks for clarifying. I guess that your reference to moving to upstream indicates that systemd is now sufficiently established that discussion of problems is an upstream issue for bug triage/fixing? I would imagine that the user list may have useful exchanges too but that it would be important to get any issues moved upstream from there too? The most important outcome is that bugs are fixed so whatever route is best for that (including bugzilla of course) users should add input to. Hence links to upstream for systemd are made available so that the best exposure to recourse to resolution is optimised? I hope discussions continue on Fedora lists as well. systemd impacts lots of fedora users who just read Fedora lists. I've subscribed to gnome, network manager, btrfs, virt, lvm, selinux, anaconda, kickstart, desktop, and etc. Sure, folks subscribe to more lists than that, but when you can't spend much timre reading the lists, having discussions concentrated in your distro of choice's lists frees up precious time to actively participate in testing. As a Fedora user and tester it is far easier to just peruse the Fedora lists. Once systemd settles in and is no longer viewed with suspicion, then maybe add upstream for the rare issue. Please don't be a wet blanket, folks, let the discussions continue here. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/10/2011 03:13 PM, Rahul Sundaram wrote: what would be really nice is to redirect systemd discussions to its upstream mailing list. Fedora devel is hardly the best place for it. Rahul Beg to differ - rather vehemently too - politely but vehemently. systemd is only available in fedora[1] - we are the test pigs for better or for worse - and there are most certainly bugs in fedora's systemd. Lets be blunt here - he pushed very very very hard on these very lists to get systemd in - now its in F15 and there are problems - so no punting please. Upstream and fedora are the same for systemd. Some bugs like sendmail failing to start have been there since September 2010 ( almost 9 months ... ) - people are reporting the same issue on F15 in the fedora lists ... who is fixing this stuff ? e.g. https://bugzilla.redhat.com/show_bug.cgi?id=692008 https://bugzilla.redhat.com/show_bug.cgi?id=633774 Ok so he's on vacation - this is a very core part of the OS - who is backing him up I wonder? Who else is on the project? Surely you're not saying there is no-one else working on systemd... and when LP is away/busy nothing will get done ... otherwise I strongly urge it be replaced by upstart asap. gene/ [1] Yes he spoke with another distro - but no-one is using it. So its a fedora only project until its picked up somewhere else - which has not happened yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
Denys Vlasenko wrote: Mem total:2035840 anon:431208 map:78924 free:419084 [snip] 1 15384 11856 13664 1340 11752 0 132 /sbin/init So this singleton process is taking 0.76% of your RAM. What the heck are you complaining about? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On 06/11/2011 05:20 AM, Genes MailLists wrote: Lets be blunt here - he pushed very very very hard on these very lists to get systemd in - now its in F15 and there are problems - so no punting please. Upstream and fedora are the same for syste That is a gross over simplification. Fedora is just one of the many distros integrating systemd and there are developers from other distros including Novell involved in systemd and contributing to it. If we start discussing every project where Red Hat is heaving involved, that list is long [1] Yes he spoke with another distro - but no-one is using it. So its a fedora only project until its picked up somewhere else - which has not happened yet. That's not true. Mandriva 2011 is already including it by default. So is MeeGo. OpenSUSE has announced that it is using it by default in their next release. Not to mention other distros who have included it in their repos. It is far from a Fedora only project. The proper place for general discussions about systemd is http://lists.freedesktop.org/mailman/listinfo/systemd-devel Only Fedora specific bugs should be discussed here. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
