[lfs-dev] LFS SVN and Systemd Report

Armin K. krejzi at email.com
Fri May 25 08:11:43 PDT 2012


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.

>
> 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.

 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
         libcap
         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 untill 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.

* 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.

>
> 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.

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.

Also, it interfaces directly with libkmod without any need for modprobe 
tools. Count out 1000 lines more to that.

It uses builtin fsck functions that only interface with fsck.fstype, so 
no need for big initscript for that.

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.

>> 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.



More information about the lfs-dev mailing list