[Buildroot] Systemd update

[Buildroot] Systemd update

[Dmitry Golubovsky]

Hi,

I have reached some progress with adopting systemd for Buidlroot with
proper PAM login support and working system journal.

I suggested some of my patches for upstream [1], but systemd
maintainers were not very much interested in fixes around uclibc
missing features [2], so let's keep these patches with Buildroot.

My patches and package configs are collected under this Gitorious
project [3] which is my test bench for packages being adopted for
Buildroot, and in particular under [4]. Patches are applicable to the
v186 snapshot of systemd (the latest avalable).

The patches are not 100% final at the moment I am writing this (there
are few typos I spotted and will fix them ASAP). However I am
announcing these patches for early review by the Buildroot community.

I provided some details in [1] so will not repeat them here. In
general, I am addressing the missing features at the configure.ac
level by implementing tests and setting HAVE_... flags in config.h.

The patch for getty.unit may be questionable. I need to be flexible on
what program to use as user greeter, so there is a level of
indirection added where actual getty program is symlinked to a
getty-wrapper in /sbin, and this getty-wrapper is what systemd starts.
An option to start standard busybox getty is added automatically.

As of now, I can boot a buidroot-produced image, get to the login
prompt, login with PAM, and systemd indeed places the logged-on user
session in a separate cgroup. I haven't tried whether it works with
pam_namespace though.

Few important notes (it took me some time to find out why certain
things did not work, so I am posting them here)

1. busybox should be configured with PAM support in login (under
"login utilities"), and linux-pam should be a dependency of busybox
otherwise it will not compile (PAM header files will be missing).
2. it is very important to run logged-in session in a child process
(configured sameplace, next to PAM support in login). Systemd creates
a user session and passes some pipe file descriptor to the parent
process (i. e. login). User session lives as long as that descriptor
is not closed by the parent. Busybox login, if not running logged-in
session in a child process cleans up most of it open file descriptiors
before jumping to user login shell, so new session gets killed even
before it starts ;) If using child process for logged in session,
login keeps its file descriptiors open, and the session is not killed
(it took me a lot of digging through systemd sources to trace this
down).

For now I would like to get a feedback from the Buildroot community on
this. If anybody wants to play with these additions privately please
let me know, and I'll provide more information.

Hopefully working systemd will be a useful addition to buildroot.

Thanks.

---------------------
[1] http://lists.freedesktop.org/pipermail/systemd-devel/2012-July/005920.html
[2] http://lists.freedesktop.org/pipermail/systemd-devel/2012-July/005928.htm
[3] https://gitorious.org/lfa/
[4] https://gitorious.org/lfa/myroot/trees/master/systemd-pam

-- 
Dmitry Golubovsky

Anywhere on the Web

[Buildroot] Systemd update

[Diego Iastrubni]

How does it compare with a similar setup, using "normal" logins and
busybox's init?

How much time does it take to boot under both setups?
How much memory does it take to login a single user?

 - I know this is only for your setup, but it might give us real numbers.

BTW: is PAM mandatory?

On Fri, Jul 13, 2012 at 7:08 PM, Dmitry Golubovsky <golubovsky@gmail.com>wrote:

> Hi,
>
> I have reached some progress with adopting systemd for Buidlroot with
> proper PAM login support and working system journal.
>
> I suggested some of my patches for upstream [1], but systemd
> maintainers were not very much interested in fixes around uclibc
> missing features [2], so let's keep these patches with Buildroot.
>
> My patches and package configs are collected under this Gitorious
> project [3] which is my test bench for packages being adopted for
> Buildroot, and in particular under [4]. Patches are applicable to the
> v186 snapshot of systemd (the latest avalable).
>
> The patches are not 100% final at the moment I am writing this (there
> are few typos I spotted and will fix them ASAP). However I am
> announcing these patches for early review by the Buildroot community.
>
> I provided some details in [1] so will not repeat them here. In
> general, I am addressing the missing features at the configure.ac
> level by implementing tests and setting HAVE_... flags in config.h.
>
> The patch for getty.unit may be questionable. I need to be flexible on
> what program to use as user greeter, so there is a level of
> indirection added where actual getty program is symlinked to a
> getty-wrapper in /sbin, and this getty-wrapper is what systemd starts.
> An option to start standard busybox getty is added automatically.
>
> As of now, I can boot a buidroot-produced image, get to the login
> prompt, login with PAM, and systemd indeed places the logged-on user
> session in a separate cgroup. I haven't tried whether it works with
> pam_namespace though.
>
> Few important notes (it took me some time to find out why certain
> things did not work, so I am posting them here)
>
> 1. busybox should be configured with PAM support in login (under
> "login utilities"), and linux-pam should be a dependency of busybox
> otherwise it will not compile (PAM header files will be missing).
> 2. it is very important to run logged-in session in a child process
> (configured sameplace, next to PAM support in login). Systemd creates
> a user session and passes some pipe file descriptor to the parent
> process (i. e. login). User session lives as long as that descriptor
> is not closed by the parent. Busybox login, if not running logged-in
> session in a child process cleans up most of it open file descriptiors
> before jumping to user login shell, so new session gets killed even
> before it starts ;) If using child process for logged in session,
> login keeps its file descriptiors open, and the session is not killed
> (it took me a lot of digging through systemd sources to trace this
> down).
>
> For now I would like to get a feedback from the Buildroot community on
> this. If anybody wants to play with these additions privately please
> let me know, and I'll provide more information.
>
> Hopefully working systemd will be a useful addition to buildroot.
>
> Thanks.
>
> ---------------------
> [1]
> http://lists.freedesktop.org/pipermail/systemd-devel/2012-July/005920.html
> [2]
> http://lists.freedesktop.org/pipermail/systemd-devel/2012-July/005928.htm
> [3] https://gitorious.org/lfa/
> [4] https://gitorious.org/lfa/myroot/trees/master/systemd-pam
>
> --
> Dmitry Golubovsky
>
> Anywhere on the Web
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120715/3869f1a2/attachment.html>

[Buildroot] Systemd update

[Dmitry Golubovsky]

Hi,

On Sun, Jul 15, 2012 at 10:19 AM, Diego Iastrubni <diegoiast@gmail.com> wrote:
> How does it compare with a similar setup, using "normal" logins and
> busybox's init?

It may be a bit more complicated than "traditional" sequential setup,
but infinitely more flexible. I needed such a parallel dependency
driven init program and thought of porting Android's setup, but
systemd is the same but on big steroids.

>
> How much time does it take to boot under both setups?

I do not remember how much it took under traditional setup. I get 24
sec by kernel timestamp until the moment I can login, but this also
involves setting up DHCP (since my setting is diskless) on a KVM
running on a 2 GHz AMD64. Plus it takes some time to unpack the initrd
image (mune is about 40M) So I'd discount 5 to 10 seconds for "pure
boot time"

I'll try to boot my test image later and give better measurements then.

> How much memory does it take to login a single user?

I am not sure how to measure this. Besides, in my case initrd unpacks
into memory anyway so it alone eats tens of megs.

>
>  - I know this is only for your setup, but it might give us real numbers.
>
> BTW: is PAM mandatory?

No it is not. It is the login program that lets the user in. What
systemd-pam does is to notify the session manager of new session (so
it can watch it and clean up afterwards), and set up a cgroup for the
new session. If you do not include systemd-pam in the PAM stack (or do
not use PAM at all) systemd starts getty and you can login normal way.
Again, it is just something I need for my project.

Thanks.

-- 
Dmitry Golubovsky

Anywhere on the Web

[Buildroot] Systemd update

[Diego Iastrubni]

(forwarding to the list, I hope you don't mind)


On Mon, Jul 16, 2012 at 5:15 AM, Dmitry Golubovsky <golubovsky@gmail.com>wrote:

>
> Here is dmesg output on a VM:
>
> http://pastebin.com/ZbQmMiTU
>
> [   16.881460] systemd[1]: Startup finished in 14s 40ms 662us (kernel)
> + 2s 840ms 704us (userspace) = 16s 881ms 366us.
>
> of these 16sec:
>
> [    0.392041] Trying to unpack rootfs image as initramfs...
> [   13.790005] Freeing initrd memory: 37216k freed
>
> 13 secs were spent to unpack initrd. So it could be under 10sec from
> boot to DHCP ready.
>
>
I concern is this: *is* systemd faster then traditional int?
Does paralyzing those things decrease boot time? Can this benefit the
embedded community?

I would like to review a similar setup for something like the RPI and
measure there. I need to find time for this (I am still fighting my RPI
setup... the biggest problem is that its not trivial to get a console.. so
all I have to test is my 40" TV... not ideal for kernel messages...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120716/301e312c/attachment.html>

[Buildroot] Systemd update

[Dmitry Golubovsky]

Hi,

On Mon, Jul 16, 2012 at 2:03 AM, Diego Iastrubni <diegoiast@gmail.com> wrote:
> (forwarding to the list, I hope you don't mind)

Sure, in fact I made such a forward myself shortly after I replied you.

>> [    0.392041] Trying to unpack rootfs image as initramfs...
>> [   13.790005] Freeing initrd memory: 37216k freed
>>
>> 13 secs were spent to unpack initrd. So it could be under 10sec from
>> boot to DHCP ready.
>>
>
> I concern is this: *is* systemd faster then traditional int? Does paralyzing

Well, like I said boot time is not a criterion for me, and I am not
exactly doing an embedded project, portable rather,

Thanks.

-- 
Dmitry Golubovsky

Anywhere on the Web

[Buildroot] Systemd update

[Alex Bradbury]

On 16 July 2012 07:03, Diego Iastrubni <diegoiast@gmail.com> wrote:
> I would like to review a similar setup for something like the RPI and
> measure there. I need to find time for this (I am still fighting my RPI
> setup... the biggest problem is that its not trivial to get a console.. so
> all I have to test is my 40" TV... not ideal for kernel messages...)

I'm interested in buildroot + the Raspberry Pi also (I'm currently
responsible for the official Debian wheezy based images). You might
want to have a look at
https://github.com/nezticle/RaspberryPi-BuildRoot and feel free to
contact me off-list if you're having problems building and booting a
kernel (or drop by #raspberrypi-dev on Freenode).

Alex

[Buildroot] Systemd update

[Thomas Petazzoni]

Le Mon, 16 Jul 2012 10:32:43 +0100,
Alex Bradbury <asb@asbradbury.org> a ?crit :

> I'm interested in buildroot + the Raspberry Pi also (I'm currently
> responsible for the official Debian wheezy based images). You might
> want to have a look at
> https://github.com/nezticle/RaspberryPi-BuildRoot and feel free to
> contact me off-list if you're having problems building and booting a
> kernel (or drop by #raspberrypi-dev on Freenode).

Do you think it would be possible to submit the necessary patches to
the official Buildroot, instead of maintaining a fork? It will also
make it easier for you to maintain the support for Rasberry Pi if it is
in the mainline Buildroot version.

I am definitely interested in seeing more board/SoC-specific support in
Buildroot.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Systemd update

[Alex Bradbury]

On 16 July 2012 10:41, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Le Mon, 16 Jul 2012 10:32:43 +0100,
> Alex Bradbury <asb@asbradbury.org> a ?crit :
>
>> I'm interested in buildroot + the Raspberry Pi also (I'm currently
>> responsible for the official Debian wheezy based images). You might
>> want to have a look at
>> https://github.com/nezticle/RaspberryPi-BuildRoot and feel free to
>> contact me off-list if you're having problems building and booting a
>> kernel (or drop by #raspberrypi-dev on Freenode).
>
> Do you think it would be possible to submit the necessary patches to
> the official Buildroot, instead of maintaining a fork? It will also
> make it easier for you to maintain the support for Rasberry Pi if it is
> in the mainline Buildroot version.
>
> I am definitely interested in seeing more board/SoC-specific support in
> Buildroot.

That particular patchset is not my own work, but yes - I would also
like to see something like this submitted upstream and have suggested
to the author he does so. Now we're about to get the next Wheezy
release out the door (moving to armhf thanks to the Raspbian folks)
I'm hoping I'll be able to spend some time with buildroot.

Alex

[Buildroot] Systemd update

[Maxime Ripard]

Hi Dmitry,

Le 13/07/2012 18:08, Dmitry Golubovsky a ?crit :
> I have reached some progress with adopting systemd for Buidlroot with
> proper PAM login support and working system journal.
> 
> I suggested some of my patches for upstream [1], but systemd
> maintainers were not very much interested in fixes around uclibc
> missing features [2], so let's keep these patches with Buildroot.
> 
> My patches and package configs are collected under this Gitorious
> project [3] which is my test bench for packages being adopted for
> Buildroot, and in particular under [4]. Patches are applicable to the
> v186 snapshot of systemd (the latest avalable).
> 
> The patches are not 100% final at the moment I am writing this (there
> are few typos I spotted and will fix them ASAP). However I am
> announcing these patches for early review by the Buildroot community.

Could you send these patches to the mailing list using git send-email
please ? You can find a nice tutorial here:
http://lists.busybox.net/pipermail/buildroot/2010-December/039181.html

This way, we will be able to properly review these changes.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Systemd update

[Dmitry Golubovsky]

Hi,

On Mon, Jul 16, 2012 at 5:09 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Dmitry,
> Could you send these patches to the mailing list using git send-email
> please ? You can find a nice tutorial here:
> http://lists.busybox.net/pipermail/buildroot/2010-December/039181.html

Sure I will send them to the mailing list (I contributed few packages
earlier). These patches are not 100% final though, and are better done
in  several steps, e. g. we need to add linux-pam to Buildroot first,
etc. Just a little bit later.

Thanks.

-- 
Dmitry Golubovsky

Anywhere on the Web

[Buildroot] Systemd update

[Thomas Petazzoni]

Le Mon, 16 Jul 2012 11:09:41 +0200,
Maxime Ripard <maxime.ripard@free-electrons.com> a ?crit :

> Could you send these patches to the mailing list using git send-email
> please ?

Agreed.

> You can find a nice tutorial here:
> http://lists.busybox.net/pipermail/buildroot/2010-December/039181.html

A slightly better version is available at
http://elinux.org/Buildroot_how_to_contribute (my original e-mail had
some issues).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com