Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for systemd #2474

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Support for systemd #2474

wants to merge 4 commits into from

Conversation

mmoren
Copy link

@mmoren mmoren commented Mar 5, 2016

This is an attempt of having enter-chroot start systemd inside a PID namespace for kernels that support it. New param -s enables this mode. It allows one to manage services, run Gnome, and otherwise use systemd like normal people inside a chroot. I've been using it with Ubuntu Wily, and it works pretty well already.

Present challenges:

  • Currently lacking proper running session detection, so crouton always attempts to unmount the chroot when exiting a shell.

  • Requires jchroot on the host - should perhaps be added and included with crouton? Single C file which can be found and compiled from https://github.com/vincentbernat/jchroot. Now uses minijail0 which is already in CrOS.

  • A target is needed that masks (disables) some services that wreaks havok with Chrome OS managed devices like keyboard and touchpad. I have yet to figure out how to create a target file though. For now these commands should be run before using -s by first entering the chroot normally:

    # Mask services that mess with Chrome OS controlled devices etc.
    ln -sf /dev/null /etc/systemd/system/alsa-restore.service
    ln -sf /dev/null /etc/systemd/system/console-setup.service
    ln -sf /dev/null /etc/systemd/system/systemd-remount-fs.service
    ln -sf /dev/null /etc/systemd/system/systemd-udevd-control.socket
    ln -sf /dev/null /etc/systemd/system/systemd-udevd-kernel.socket
    ln -sf /dev/null /etc/systemd/system/systemd-udevd.service 
    ln -sf /dev/null /etc/systemd/system/systemd-udev-settle.service
    ln -sf /dev/null /etc/systemd/system/systemd-udev-trigger.service
    
    # Set multi-user as default target instead of graphical.
    ln -sf systemd/system/multi-user.target /etc/systemd/system/default.target
  • Lots of polish, like detecting whether or not the kernel is built with CONFIG_PID_NS and give the user nice error messages if not. (already included in all kernels)

Use jchroot to start systemd. Detects running systemd process for
chroot using PID file and enters.
@idvoretskyi
Copy link

Good job!

@drinkcat
Copy link
Collaborator

drinkcat commented Mar 8, 2016

Thanks for the PR! This is really awesome.

Currently lacking proper running session detection, so crouton always attempts to unmount the chroot when exiting a shell.

Passing remark: The whole mount-chroot/unmount-chroot logic could be simplified a lot if we used mount namespaces. Even if we do not start any init system.

In most cases it should be ok to tear down systemd if no one uses the namespace anymore (maybe after a timeout?). We need to figure out the logic ,-)

A target is needed that masks (disables) some services that wreaks havok with Chrome OS managed devices like keyboard and touchpad. I have yet to figure out how to create a target file though. For now these commands should be run before using -s by first entering the chroot normally:

We'd need to add these to core target.

Lots of polish, like detecting whether or not the kernel is built with CONFIG_PID_NS and give the user nice error messages if not.

No issues here, all of our kernels have PID_NS enabled:

~/chromiumos/src/third_party/kernel$ grep CONFIG_PID_NS */chromeos/config/base.config
v3.10/chromeos/config/base.config:CONFIG_PID_NS=y
v3.14/chromeos/config/base.config:CONFIG_PID_NS=y
v3.18/chromeos/config/base.config:CONFIG_PID_NS=y
v3.8/chromeos/config/base.config:CONFIG_PID_NS=y
v4.4-experimental/chromeos/config/base.config:CONFIG_PID_NS=y

(note to self, CLA in file, thanks!)

@drinkcat drinkcat added this to the xenial support milestone Mar 8, 2016
Clean environment with env when entering chroot.
Use read -r.
@mmoren
Copy link
Author

mmoren commented Mar 8, 2016

Nice! Didn't know about minijail0. Got it working with minor weirdness - running /lib/systemd/systemd directly from minijail0 seems to fail, but exec'ing the same command from within a shell works (???).

Agreed that using mount namespaces instead of juggling the mounts by scripts would be nice. For now though, I'll look into how to detect whether or not the systemd PID namespace is in use, for unmounting the old way.

@drinkcat
Copy link
Collaborator

drinkcat commented Mar 9, 2016

Nice! Didn't know about minijail0. Got it working with minor weirdness - running /lib/systemd/systemd directly from minijail0 seems to fail, but exec'ing the same command from within a shell works (???).

Did you try this option?

  -I:         Run <program> as init (pid 1) inside a new pid namespace (implies -p).

@mmoren
Copy link
Author

mmoren commented Mar 9, 2016

Did you try this option?

-I: Run as init (pid 1) inside a new pid namespace (implies -p).

Yes, that's what I'm using. The weirdness is this:

# Works
minijail0 ... -I /bin/bash -c "exec /lib/systemd/systemd"

# Does not work (exits immediately with code 255)
minijail0 ... -I /lib/systemd/systemd

@mmoren mmoren mentioned this pull request Mar 21, 2016
@dnschneid
Copy link
Owner

Thank you so much for doing this!
It makes a lot of sense to get PID namespaces working without complicating things by trying to do filesystem namespaces at the same time (#2063)...

@zxvv
Copy link
Contributor

zxvv commented Apr 6, 2016

One option for installing the service, while preventing it from starting would be:

env RUNLEVEL=1 apt-get install alsa-utils console-setup ...

An option to disable services after they are installed would be:

systemctl disable alsa-utils
systemctl disable console-setup
...

@dnschneid dnschneid modified the milestones: Fixit Oct 2016, xenial support Oct 11, 2016
@MarcusHallettUAH
Copy link

Right, so I'll drop an issue for this a bit later, but I've got a few questions for @sn0e, @drinkcat, @dnschneid, or anyone else in the project that I haven't found answers to in the issues section.

Firstly, does this work? I can't seem to upgrade to xenial (or anything past trusty) due to the systemd issue.

Secondly, how does this work? My *nix development and admin skills are lagging.

Thirdly, how do I go about building this and compiling it from source.

Fourthly, is cruton still alive and well? I'm having trouble tracking your development milestones and progress. That's probably because I'm dense and presently have the luxury of relying on cleverer minds than mind for product management.

Finally, is there just a simple fix that I'm missing for the systemd problem that you've already implemented, and that's just slipped by me?

I'm just messing about with my relic of a Cr-48, if that is indicative of anything.

@acornejo
Copy link

acornejo commented Feb 2, 2017

What would it take to get this merged? I am not so interested in systemd per-se, but on having crouton run inside its own pid namespace (i.e. wrap with minijail0).

@KellyLSB
Copy link

Any news on this? I'm assuming it's being backlogged to preference Crostini? Was there any plans on making this mergeable?

@KellyLSB
Copy link

Patched these mods into my current enter-chroot; works like a charm!

@ikeofkc
Copy link

ikeofkc commented Nov 24, 2018

Can someone explain/link how to setup crouton using these/any mods as the last commenter stated they did? This issue is over 2 years old so I don't really have much hope in waiting longer.

@MetaNite64
Copy link

Any info on whether this will be merged? I would love this to happen in the mainstream.

@ty1118
Copy link

ty1118 commented Sep 20, 2021

Patched these mods into my current enter-chroot; works like a charm!

How'd you do this?

@picostove picostove removed their assignment Nov 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.