The future of initsystem in Chromium OS

[Jóhann B. Guðmundsson]

Greetings

Are there any plans for chromium OS moving away from using upstart as the preferred init system to using systemd instead?

If the answer is yes then I would like you to know that those of us that have been doing systemd distribution integration work ( Arch,Fedora,Gentoo,OpenSuse,Mageia etc ) have been collaborating and collectively sharing experience and knowledge among ourselves how the migration process is, has taken place in our distributions as well been collectively sharing units across those distributions, making the transaction to systemd as smooth as possible in the process and I would like you to know that I'm available to assist the Chromium community anyway I can in making the transaction to systemd as smooth as possible should you need it.

Thanks
           Jóhann B.

[Mike Frysinger]

there aren't any resources currently allocated to the effort that i'm aware of.  that isn't to say we think it's a dumb idea or never plan on looking at it, just that it's low priority as it's not known/guaranteed to be better than what we have currently.  what we have currently is (1) a known value and (2) fast [enough] and (3) working in production (trial by fire).

basically it needs someone to:

 - prototype the entire system (convert all existing upstart scripts to systemd units)

 - gather boot timing statistics (we have support for this already integrated in our firmware/kernel/upstart init scripts)

 - show that the end result is indeed "better" as defined largely by speed (other metrics are important too like ease of debugging and ease of use/implementation and size, but if a systemd implementation is slower than what we have, then we really don't care)

only once we have real data available would a decision be made.

-mike

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
 

["Jóhann B. Guðmundsson"]

On 02/06/2014 08:58 PM, Mike Frysinger wrote:
> there aren't any resources currently allocated to the effort that i'm
> aware of. that isn't to say we think it's a dumb idea or never plan
> on looking at it, just that it's low priority as it's not
> known/guaranteed to be better than what we have currently. what we
> have currently is (1) a known value and (2) fast [enough] and (3)
> working in production (trial by fire).
>
> basically it needs someone to:
> - prototype the entire system (convert all existing upstart scripts
> to systemd units)

Should not be a problem.

If you point me to the repo containing those initscript I probably can
have them migrated within a day no more then a weekend.

> - gather boot timing statistics (we have support for this already
> integrated in our firmware/kernel/upstart init scripts)

Systemd already comes with an boot analyzer [1] and I will need to know
what hardware you are using for you testing for real comparison.

On my Thinkpad T420
LENOVO 4180WPD/4180WPD, BIOS 83ET76WW (1.46 ) 07/05/2013
Intel(R) Core(TM) i5-2540M CPU
4GB RAM
Samsung SSD 840 Series 250GB disk

$ systemd-analyze
Startup finished in 1.604s (kernel) + 310ms (initrd) + 1.690s
(userspace) = 3.606s

That's firmware time + 3.6 seconds booting into full blown F20 Gnome
without losing desktop functionality bluetooth,networking etc but with
all the "generic" Fedora has enable by default out of the box turned off.

> - show that the end result is indeed "better" as defined largely by
> speed (other metrics are important too like ease of debugging and ease
> of use/implementation and size, but if a systemd implementation is
> slower than what we have, then we really don't care)

Debugging and ease of use over sys V script is a given but I will need
to know the target size as well as the boot time you are achieving.

I can also provide you with "sales pitch" outside the distro's if you
want one but in reality seeing is believing right ;)

* Aggressive parallelization systemd boot.

* Monitoring of every process it starts.

* Flexible application restart mechanisms.

* Centralized place to look for logs.

* Support for watchdog chaining.

* Very flexible dependency mechanism.

* Provides the tools to debug and diagnose the init process:
systemd-analyze, systemd-cgls, systemd-cgtop, bootchart, pybootchargui, etc.

* On demand launch of services can improve boot time and conserve resources.

* Extremly flexible timer-based activation.

So fourth and so on and few sample where embedded already using systemd

Ångström you know the distribution tailored for embedded devices and is
shipped with the BeagleBone Black, BeagleBoard-xM and BeagleBone it runs
systemd.

Yocto Project which is an open source collaboration project that
provides templates, tools and methods to help you create custom
Linux-based systems for embedded products regardless of the hardware
architecture yup it runs systemd.

Sailfish which is a Linux-based mobile operating system developed and
run on smartphones by Jolla hello systemd

*Any* GENIVI specification-compliant Linux®- based open source
infotainment (IVI) product on the market runs systemd and let's see what
GENIVI says about systemd...

"'Systemd' is an emerging technology for improving startup efficiency
and control. In-vehicle infotainment users (drivers and passengers)
expect the system to be functioning within seconds after turning the
key, unlike well-known mobile devices such as smartphones that may take
minutes to start up from full power-off. Unlike phones and PCs, cars
cannot leave the infotainment system in a suspended state because the
vehicle battery will run down potentially preventing the car from
starting." By enforcing systemd, drivers can be assured that their
GENIVI-based infotainment head unit, though packed with features more
like an Android- or iOS-based smartphone, will be no more burden on the
battery than an AM/FM radio with built-in digital clock. And it'll turn
on just as quickly, too."

Tizen an open source, standards-based software platform supported by
leading mobile operators, device manufacturers, and silicon suppliers
for multiple device categories such as smartphones, tablets, netbooks,
in-vehicle infotainment devices, and smart TVs.


1. http://www.freedesktop.org/software/systemd/man/systemd-analyze.html

[Richard Barnette]

On 2/6/14, 2:13 PM, "Jóhann B. Guðmundsson" wrote:
>
> On 02/06/2014 08:58 PM, Mike Frysinger wrote:
>> there aren't any resources currently allocated to the effort that i'm
>> aware of. that isn't to say we think it's a dumb idea or never plan
>> on looking at it, just that it's low priority as it's not
>> known/guaranteed to be better than what we have currently. what we
>> have currently is (1) a known value and (2) fast [enough] and (3)
>> working in production (trial by fire).
>>
>> basically it needs someone to:
>> - prototype the entire system (convert all existing upstart scripts
>> to systemd units)
>
> Should not be a problem.
>
> If you point me to the repo containing those initscript I probably can
> have them migrated within a day no more then a weekend.
>

Well, I see you're not lacking in chutzpah... :-)

The bulk of the upstart jobs are in src/platform/init.
The git repository is here:
https://chromium.googlesource.com/chromiumos/platform/init/

There are also some important jobs and scripts in
src/platform/login_manager; the git repo is here:
https://chromium.googlesource.com/chromiumos/platform/login_manager/

You may find the system is slightly more complicated than
you're guessing. Certainly, there's no significant sharing
with Ubuntu.

Tips you'll need in order to understand the system:
* In the 'init' repo: Read the comments in boot-services.conf
and system-services.conf.
* In the 'init' repo: You will probably need to understand the
chromeos_startup script.
* In the 'login_manager' repo: Get familiar with what happens in the
ui.conf job, and in the follow-on script session_manager_setup.sh.
* Note that Chrome is an integral part of the boot flow. In
particular, Chrome calls in to session_manager to indicate when the
login screen is ready; this is what causes session_manager to
execute 'initctl login-prompt-visible'.

Note also that although many of the upstart jobs are in the repositories
above, there are others that aren't.

Before you invest any time beyond a little bit of learning, I want
to follow-up on Mike's comments:

Boot performance is a key metric that matters. Generally, I rate
any change in excess of .1 second as significant. However, my
experience with Chrome OS boot time is that /sbin/init (Upstart)
isn't a significant contributor to boot performance. The biggest
contributors are Chrome, X, the kernel, and chromeos_startup, in
that order. Changing the init daemon basically can't affect any
of them. I'd rate getting change of .1 second merely by changing
/sbin/init as plausible, but a change as big as .5 second is likely
somewhere between "really hard" and "not going to happen".

Moreover: although boot time changes as small as .1 second matter,
basic software engineering matters, too. Converting to systemd
is likely to be disruptive and expensive. So, there'd also need
to be a demonstrable maintenance win to justify a conversion.

--
--jrb

["Jóhann B. Guðmundsson"]

On 02/06/2014 11:34 PM, Richard Barnette wrote:
>>
>> If you point me to the repo containing those initscript I probably can
>> have them migrated within a day no more then a weekend.
>>
> Well, I see you're not lacking in chutzpah... :-)

I got a ich to scratch so why not scratch it worst case scenario I
scratched it so hard I get scars ;)

>
> The bulk of the upstart jobs are in src/platform/init.
> The git repository is here:
> https://chromium.googlesource.com/chromiumos/platform/init/
>
> There are also some important jobs and scripts in
> src/platform/login_manager; the git repo is here:
> https://chromium.googlesource.com/chromiumos/platform/login_manager/
>
> You may find the system is slightly more complicated than
> you're guessing.

I'll just ping the list if I start bumbing my head against the wall to
much.

Hmm...

I would think that changes to X would be unavoidable along side this
since I'm pretty sure you would be interested implementing the systemd
integration socket activation.patch set [1][2][3] from Łukasz as well as
Hans work in progress in upstream X, to add systemd-logind integration
to the xserver which is expected to land for 1.16 as in the xserver
will be able to run as a systemd-logind session controller and will be
started inside a (pam) user-session, Now this requires changes to apps
starting the xserver ( specifically to display-managers GDM/KDM etc. )
which will ( finally ) allow for it to run properly as non-root, or drop
root rights early on, which turn reduces it's attack surface.

But maybe I'm mistaken in thinking that since I'm not all familiar with
Chromium OS and that might not be beneficial to Chromium OS et all...

>
> Moreover: although boot time changes as small as .1 second matter,
> basic software engineering matters, too. Converting to systemd
> is likely to be disruptive and expensive. So, there'd also need
> to be a demonstrable maintenance win to justify a conversion.
>

There is both the collective collaboration taking place between
distributions as well as systemd being part of the genivi and lined up
for lsb specification and it being part of both the enterprise OS'es (
Red Hat with RHEL 7 and already part of latest enterprise Suse ) and the
fact that the fragmentation in the plumbing layer is slowing seizing to
exist and it playing a big role in achieving that, it should
significantly reduce the maintainance burden in the long run for
everyone. ( As opposed to trying to maintain anything outside what's
already happening )

JBG

1.
http://cgit.freedesktop.org/xorg/xserver/commit/?id=b3d3ffd19937827bcbdb833a628f9b1814a6e189
2.
http://cgit.freedesktop.org/xorg/lib/libxtrans/commit/?id=e1e6121a1638d43d9929589b4723da2b38cb6b44
3.
http://cgit.freedesktop.org/xorg/lib/libxtrans/commit/?id=e1e6121a1638d43d9929589b4723da2b38cb6b44

[Scott James Remnant]

On Thursday, February 6, 2014 2:13:39 PM UTC-8, Jóhann B. Guðmundsson wrote:

 

Systemd already comes with an boot analyzer [1] and I will need to know
what hardware you are using for you testing for real comparison.

Hardware should obviously be a Chromebook!

The current generation are reasonably similar in two distinct branches, the x86-based ones such as the Acer C710 & HP Chromebook 14 and the arm-based ones such as the Samsung Chromebook and HP Chromebook 11

I think we'd want to see boot performance before/after on both types.

Debugging and ease of use over sys V script is a given but I will need
to know the target size as well as the boot time you are achieving.

Boot time varies on exact hardware, but is basically anything from 3s (Pixel) to 8s (HP Chromebook 11) .

Scott

[Scott James Remnant]

On Thursday, February 6, 2014 4:24:19 PM UTC-8, Jóhann B. Guðmundsson wrote:

 

I would think that changes to X would be unavoidable along side this
since I'm pretty sure you would be interested implementing the systemd
integration socket activation.patch set [1][2][3] from Łukasz as well as
Hans work in progress in upstream X, to add systemd-logind integration
to the xserver which is expected to land for 1.16  as in the xserver
will be able to run as a systemd-logind session controller and will be
started inside a (pam) user-session, Now this requires changes to apps
starting the xserver ( specifically to display-managers GDM/KDM etc.  )
which will ( finally ) allow for it to run properly as non-root, or drop
root rights early on, which turn reduces it's attack surface.

But maybe I'm mistaken in thinking that since I'm not all familiar with
Chromium OS and that might not be beneficial to Chromium OS et all

 

I don't know what systemd-logind does, but you should probably know at this point that Chromium OS does not use "GDM" or "KDM" or any desktop manager you're previously aware of.

Our "session manager" is a shell script that starts the X server and its dependencies, and then handles starting Chrome once the X server is running. We have a separate login manager that is used by Chrome to deal with unlocking cryptohome's, authentication, etc.

The actual UI you're using to login is Chrome.

Once a cryptohome is unlocked, there isn't a "window manager" - that's Chrome too.

So you'll probably have to wade in to some of that too, especially since notification of which bits are ready (e.g. X is up, login window is up, etc.) are handled by Upstart events now.

> Moreover:  although boot time changes as small as .1 second matter,
> basic software engineering matters, too.  Converting to systemd
> is likely to be disruptive and expensive.  So, there'd also need
> to be a demonstrable maintenance win to justify a conversion.
>

There is both the collective collaboration taking place between
distributions as well as systemd being part of the genivi and lined up
for lsb specification and it being part of both the enterprise OS'es (
Red Hat with RHEL 7 and already part of latest enterprise Suse ) and the
fact that the fragmentation in the plumbing layer is slowing seizing to
exist and it playing a big role in achieving that, it should
significantly reduce the maintainance burden in the long run for
everyone. ( As opposed to trying to maintain anything outside what's
already happening )

Chromium OS doesn't always use the same kind of "plumbing" as other distributions; some parts are familiar, but others will not be. For example we have our own network/connection manager (shill) - we don't use network manager or connman, we have our own disk manager (crosdisks) - we don't use udisks, we have our own power managers (powerd/power_manager) - we don't use upower.

So be prepared for surprises :-)

Scott

["Jóhann B. Guðmundsson"]

On 02/07/2014 02:55 AM, Scott James Remnant wrote:
>
> Chromium OS doesn't always use the same kind of "plumbing" as other
> distributions; some parts are familiar, but others will not be.

I would assume the same X on the plumbing layer so here is Hans speaking
about what he has been working on at fosdem [1]

And long story put short in the ( not ) so distant future ( this will
hit Fedora 21. scheduled for august since it includes Gnome 3.12 which
will have switched to wayland ) display manager developers probably will
need to make changes to how the xserver is started as in making their
display manager(s) to always started inside a user session, which is a
change that is also necessary for display managers who want to support
wayland since as wayland must always be started like this and as you can
see this work is heavily integrated into systemd.

So if chromium OS wants to run X as non root and is considering
switching to wayland in the distant future switching to systemd is the
right choise from maintenance perspective ( the alternative being
forking various parts and maintain it downstream with the maintenance
overhead such things bring )



JBG

1.
http://ftp.osuosl.org/pub/fosdem//2014/H1301_Cornil/Saturday/Making_the_Xserver_run_without_root_rights.webm

[Jóhann B. Guðmundsson]

On Friday, February 7, 2014 2:58:07 PM UTC, Jóhann B. Guðmundsson wrote:

To answer my own question regarding wayland there already seems to be existing wayland integration of at least the Chromium Browser in the wild...

1. https://01.org/ozone-wayland/blogs/tiagovignatti/2014/chromium-browser-wayland
2. https://github.com/01org/ozone-wayland
3, https://www.youtube.com/watch?v=EJB2pznc6iY

[Scott James Remnant]

Switching to Wayland, or Mir, or our own display server (there was an experimental project to output directly to DRI/DRM) is pretty much in the same bucket as switching init system - it's not something we would do just to "keep up with the Joneses", but something we would only do if there was a definite advantage to doing it.

So it's quite unrelated to initsystem, and certainly not a rationale for switching for us.

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

View archives, change email options, or unsubscribe: http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

--

Scott James Remnant | Chrome OS Systems | key...@google.com | Google

[Mike Frysinger]

we're already running X as non-root.  from the current R34 releases via `top`:

  949 xorg       0 -20 24188  18m  11m S   2.0  0.9   0:39.03 X

-mike

[Parithy Sivakumar]

Appreciate the details. I am just a regular google user with some curiousity. May I know the current status?

1) Is there any effort for systemd now?

2) what display manager is being used now? Any plans to change it to surface flinger?

3) Does it use glibc or bionic?

4) Apart from Google branding, flash, DRM, codecs, Digital signatures/certificates, android runtime, some configuration files for software update, are there any differences between chromium and chrome os?

5) Is there any effort to port android runtime to Chromium OS?

Thanks

Parithy

On Friday, February 7, 2014 at 11:08:12 PM UTC+5:30, Scott James Remnant wrote:

Switching to Wayland, or Mir, or our own display server (there was an experimental project to output directly to DRI/DRM) is pretty much in the same bucket as switching init system - it's not something we would do just to "keep up with the Joneses", but something we would only do if there was a definite advantage to doing it.

So it's quite unrelated to initsystem, and certainly not a rationale for switching for us.

On Fri, Feb 7, 2014 at 6:58 AM, "Jóhann B. Guðmundsson" <joha...@gmail.com> wrote:

On 02/07/2014 02:55 AM, Scott James Remnant wrote:

Chromium OS doesn't always use the same kind of "plumbing" as other distributions; some parts are familiar, but others will not be.

I would assume the same X on the plumbing layer so here is Hans speaking about what he has been working on at fosdem [1]

And long story put short in the ( not ) so distant future ( this will hit Fedora 21. scheduled for august since it includes Gnome 3.12 which will have switched to wayland ) display manager developers probably will need to make changes to how the xserver is started as in making their display manager(s) to always started inside a user session, which is a change that is also necessary for display managers who want to support wayland since as wayland must always be started like this and as you can see this work is heavily integrated into systemd.

So if chromium OS wants to run X as non root and is considering switching to wayland in the distant future switching to systemd is the right choise from maintenance perspective ( the alternative being forking various parts and maintain it downstream with the maintenance overhead such things bring )



JBG

1. http://ftp.osuosl.org/pub/fosdem//2014/H1301_Cornil/Saturday/Making_the_Xserver_run_without_root_rights.webm

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

View archives, change email options, or unsubscribe: http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

[Parithy Sivakumar]

Found this for systemd status:.

https://bugs.chromium.org/p/chromium/issues/detail?id=583671

Can't really make anything out apart from "its in progress"

would be nice if somebody can quantify it and express it in terms of percentage completed

[Mike Frysinger]

(1) still waiting for someone to post data

(2) we use Aura which sits directly on top of the linux kernel's KMS/DRM stack.  surfaceflinger doesn't make sense.

(3) we use glibc everywhere.  bionic doesn't make sense.

(4) please see the faq

(5) not at this time

-mike

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

[Richard Barnette]

> On Apr 2, 2017, at 11:00 PM, Parithy Sivakumar <parithys...@gmail.com> wrote:
>
> Found this for systemd status:.
> https://bugs.chromium.org/p/chromium/issues/detail?id=583671
> Can't really make anything out apart from "its in progress"
> would be nice if somebody can quantify it and express it in terms of percentage completed
>

I believe "in progress" is the best available summary. I don't
believe anyone is tracking the work with a detailed plan.
Moreover, the work is only about making systemd a viable alternative.
I'm not aware of any commitment to switch to systemd when that
work is done. It might happen, or it might not.

[DennisLfromGA]

As a side benefit, systemd might help with some crouton issues as well on newer releases.