Armin K. wrote: > On 05/25/2012 03:52 PM, Bruce Dubbs wrote: >>> $ systemd-analyze >>> Startup finished in 1686ms (kernel) + 7995ms (userspace) = 9682ms >> It's not clear what that does. From dmesg, it looks like the kernel is >> till running at 6.7 seconds. It will take a little longer for the >> kernel to load all those modules. >> >> I don't understand where systemd gets it's numbers. It >> > > [ 1.176174] Switching to clocksource tsc > [ 1.374790] systemd[1]: RTC configured in localtime, applying delta > of 120 minutes to system time. > [ 2.487258] udevd[55]: starting version 183 > > So, basically kernel finishes loading of builtin stuff at 1.176 seconds > and then systemd starts and pulls in udev. That's where it gets that > value from. Others are just modules, and they are running paralely with > other services. As for other messages, it's just usb subsystem which > turns on and off my mouse for some reason.
I think the reason it finishes so early for you is that the drivers are modules and have not yet been initialized. Is /sbin/init a link to systemd? My system has [ 1.880758] Switching to clocksource hpet Perhaps that difference is just HW. >> cgroups should be optional. Imposing complexity on simple problems is >> not letting the user decide. >> > > No, it is listed in README as requirement. Also it is not systemd's > fault that kernel exposes cgroups like that. OK then. We could write a script that would do: 'mount | grep -v cgroups' if there are no parameters and another command: alias cgroups='mount |grep --color=never cgroups' > From README: > > REQUIREMENTS: > Linux kernel >= 2.6.39 > with devtmpfs > with cgroups (but it's OK to disable all controllers) > optional but strongly recommended: autofs4, ipv6 > dbus >= 1.4.0 We'll need to add dbus to LFS. :( The only requirement I can see is expat so we'll need that too. > libcap I suppose they mean libcap2 which has attr as a dependency. So we have to add 3 packages that we don't want to support systemd what we don't want in order to get udev which we do want. > PAM >= 1.1.2 (optional) > libcryptsetup (optional) > libaudit (optional) > libselinux (optional) > tcpwrappers (optional) > >>> securityfs seems to be hardcoded into systemd binary. Others are cgroups >>> which expose like that. Also, /tmp can be set not to use tmpfs if desired. >> Another case of taking away user choice. > I agree on this one. It was optional until 183 I think. But that one is > disabled in kernel by default, so it won't get mounted unless you enable > it in the kernel. > >>> So, is LFS still going to avoid systemd? I said on trac that it is not >>> possible to install just udev from systemd tarball. >> I've asked on the hotplug list, but I havn't received a response. > Well, I have to disappoint you. Systemd announce mail arrived today and > I'll just post some highlights from Change Log: > > * udev: all udev sources are merged into the systemd source tree now. > All future udev development will happen in the systemd tree. It > is still fully supported to use the udev daemon and tools without > systemd running, like in initramfs or other init systems. Building > udev though, will require the *build* of the systemd tree, but > udev can be properly *run* without systemd. Other than the dependency issue, I can live with that. > * udev: the daemon binary is called systemd-udevd now and installed > in /usr/lib/systemd/. Standalone builds or non-systemd systems need > to adapt to that, create symlink, or rename the binary after building > it. Naming is not a terribly important issue. We could symlimk some names though. >> If you want to build a simple web server with no xorg, why would we need >> dbus? Another case of imposing a lack of choice. > DBus is really no big problem. You can't avoid dependencies just like > that. I don't think it would be problematic for anyone using server > since it does not use nearly anything when it comes to resources. > > Also, if you think of a *simple* server, you can ditch udev and create > static nodes. Again, LFS gives user a choice. It is up to user to decide > what they need and what they don't need. That's true. We don't show the users much about mknod any more. > Today's hardware is not very limited, so I think 2 or 3 libraries > compiled into something, or service or two more running won't make it > collapse. > > But yeah, there are always minimalists that will get in someone's way of > accomplishing something. We argued on this once already, so no arguments > this time please. > > I just want to make clear one thing that will most people say > > Note: I don't know how big is something. Just trying to make some analogy. > > " Systemd is big. How can someone compare 100 000 lines of systemd code > with 1000 lines of init code. Also, Bootscripts are simple, they just > require 5 or 10 lines. " > > This one is not true in many ways. Systemd will act as many programs as > it's possible. > > Bootscripts functions use at least 5 or so programs including grep, awk, > bash itself and so on. So you can count 10 000 more lines to the 1000 > lines of init program. Those are part of LSB Core. Using them does not add overhead. > Also, it interfaces directly with libkmod without any need for modprobe > tools. Count out 1000 lines more to that. I don't use modules. > It uses builtin fsck functions that only interface with fsck.fstype, so > no need for big initscript for that. So we are going to remove e2fsprogs? The largest script we have is checkfs and that is only 144 lines. Most are error messages and comments. Easy to read, easy to change. > It uses system calls for setting hostname, so you can count several > lines of hostname program to the number above. > > The point of all this is: Yes, it is bigger ... But it is far more > powerfull. And yes, it does not give the user view of what it's doing. > > You can count out at least 20 000 of lines for userspace programs like > analyzer, graphs and systemctl which is really nice tool, which can > enable/disable services (analog of initd-tools for sysvinit scripts), > which can display which services are running, status of the service, > when it was started and such. > > There is also a journal which can act as system log and logind which is > an login daemon which aims to replace consolekit. So, not really part of > init system. Count out at least 10 000 lines more of the code from above. > > And of course, systemd has full compatibility with sysvinit scripts as > long as they have LSB headers. It can manage them very well. > > So no offense, I was just trying to explain that systemd is not that > bigger, but it does include some features that someone might not want, > need or like. No offense. Why would you think that? I think the biggest problem with systed is lack of control by the user. Reading a script and making a line or two change is quite easy. We have a total of about 2500 lines of shell scripts in lfs divided into about 20 files. Analyzing a large compile program that has 222 c programs 139 header files and 149025 lines of (c/h) code is not easy at all. Yes, it has increased functionality but also is opaque and forces that functionality on users whether they want it or not. >>> Also, if intended to use systemd-logind as consolekit replacement, >>> linux-pam is necesary for pam_systemd.so. >> We use the login from shadow. > Just listing optional deps and telling what is their use. > > Also, dbus-python is required at runtime for systemd-analyze. I suppose we will need to do a minimal install in LFS and a more complete install with all the bells and whistles in BLFS. Sigh. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
