Systemd and containers
Systemd and containers
Posted Jun 11, 2015 18:00 UTC (Thu) by raven667 (subscriber, #5198)In reply to: Systemd and containers by xtifr
Parent article: Systemd and containers
So the best technical mechanism to accomplish the goals you describe, of having a separate, simpler, bootstrapping system, is to put everything in the ramdisk that the firmware can load without needing the OS to be at all functional. Once you've put the bootstrapping tools in the ramdisk the seperation of /bin vs. /usr/bin no longer serves any function so you can reduce complexity by putting everything in /usr/, once you've put everything in /usr you have one clean hierarchy where all the executable code lives, that can be mounted seperately if you wish without the possibility of breakage. It's the clean seperation of configuration and mutable data from code which makes containers and stateless systems workable without getting buried under the kludgy hacks that swamped previous iterations of this idea.
Posted Jun 12, 2015 4:58 UTC (Fri)
by bandrami (guest, #94229)
[Link] (4 responses)
Posted Jun 12, 2015 8:10 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
You only need to mount one file system to get the whole kit and caboodle (which is convenient for containers or remote storage) and your root directory isn't “polluted” by lots of names.
Posted Jun 12, 2015 8:19 UTC (Fri)
by smcv (subscriber, #53363)
[Link]
/usr is not meant to change, ever, except during OS upgrades/package installations (and perhaps installations to /usr/local if you use that); so it can normally be mounted read-only, and if you're using something like OSTree, all of /usr should change atomically as a single unit. The "merged /usr" model does support a separate /usr filesystem, if the initramfs mounts it.
https://wiki.freedesktop.org/www/Software/systemd/TheCase... mentions some other possibilities, like a shared /usr between machines that have the same architecture and package-set (admittedly this makes more sense on OSs like Fedora, where services are normally installed but disabled by default, than on Debian derivatives, where unwanted services are normally not installed).
Posted Jun 12, 2015 9:35 UTC (Fri)
by Kamilion (guest, #42576)
[Link] (1 responses)
I don't want /bin, I don't want /sbin, I don't want /lib, I don't want /share, I don't want /local, and I certainly don't want /include.
It's kind of a shame that sysfs took over /sys otherwise I'd really push for just changing /usr's name to /sys.
"I do not at all have the mind of a bully... in my mind bullies are intolerant of contrary opinion, domineering and rather cowardly. I would hope that none of those terms could be fairly used in describing me." -- Conrad Black
But that would be one of those changes that breaks the world because too many things rely on /usr/bin/<something>.
Thankfully on a lot of modern systems, /bin, /sbin, and /lib are just links to their /usr counterparts. One day they'll dissipate.
Eventually the old ash/bash/perl scripts will get replaced by python3, rust, and go by the distros. Maybe even Swift if it really takes off. I'm kind of skeptical about that one. Coreutils installations will start to be rare as whatever default dynamic language on the installation medium (python3) handles doing all the unixy regexes and transforms without shelling out of process...
X will go back to being an immediate-mode drawing protocol and DRI will be a laughable thing of the past once the wayland ecosystem solidifies. Most of the application toolkits have already supported it for quite a while; then xwayland will handle loading the required xorg components when necessary, like when I want to play a good old fashioned game of xevil. Once enough time passes, xorg won't even be a default installed component anymore and it'll be like "whaaat, I have to go get xorg to run this? Pffft! I'm not going through that hassle, googleing for a native rebuild..." kinda like xQuartz on a mac...
pixman and glamor will keep older fixed function graphics adapters reasonably operational, all the way back to the good ol' ATI mach64 and matrox G200w (Darn you, integrated server KVM devices!) and various framebuffer devices, including spitting SPI out to a 320x240 touchscreen on a Pi's GPIO header.
"I always keep a firewall between my own travails and my perception of public-policy issues; otherwise I would retain no credibility as a commentator." -- Conrad Black
The internet is changing. Unix is changing. If you're not cool with that; Slackware and Linux From Scratch can always use the help! (Although LFS has a systemd version which may become standard...)
Lennart's swiped the three most useful apple services, mdns/bonjour/avahi, coreaudio/pulseaudio, launchd/systemd, ripped them to chunks, and had a go at putting together a lego tower with the results.
"There are some people whose opinion I value and respect and it would be very bothersome if I forfeited their respect. But the general public? I'm not preoccupied with the opinions of others." -- Conrad Black
I've played with that lego tower, and honestly, I like it a lot better than the old duplo sysvinit set.
"Containers in my init system? It's more common than you think." -- Adapted internet meme
Ubuntu's wiki actually put together a great little mapping page between the upstart features and the systemd features:
Posted Jun 19, 2015 22:05 UTC (Fri)
by flussence (guest, #85566)
[Link]
If they get glamor's GLSL shader engine to work on those OpenGL 1.4 chips, when even my GL2.1-capable i945 refuses to start X with it enabled, I'll be impressed. Good luck with that.
Posted Jun 15, 2015 14:03 UTC (Mon)
by dps (guest, #5725)
[Link] (4 responses)
If I want an aggressively minimised box then I just don't use systemd: kernel modules, dbus, udev and network manager are all bloat which stripped down firewall machine with fixed hardware does not need and therefore should have. Anything that requires them should be rejected when there is a reasonable alternative that does not. I might actually want some of the features on offer on a desktop but have yet to find any use for dbus whatsoever. It is possible that the fact I am neo-luddite and don't use linkedin, facebook, twitter, GUI file system interfaces, cloud services, etc is a sufficient explanation for that.
I also find systemd has significant problems when /var is a separate filesystem because some things it puts in /var suffer an existence failure when that filesystem is mounted. systemd militates against having /usr on a separate partition which is mounted read only, making the desired separation of fixed and mutable data harder. If everything was in /usr then I could not boot, period: systemd dies and I have to mount /usr and /var manually for it.
Initial ram discs which duplicate tools that are installed on a box, and are hard to update, *are* kludgy hacks.
Posted Jun 16, 2015 17:16 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (3 responses)
Why make an arbitrary limit on the ramdisk to exclude it from being used as a rescue system? The initial ramdisk/ramfs mechanism is robust enough that it can load an entire OS installer/upgrader image. It seems that you've created a tautology by redefining sanity as not having a useful ramdisk to prove that ramdisks aren't useful.
> fact I am neo-luddite
Well, OK then, you can use what ever system you like but when building a system to distribute to others, that has to be flexible and robust enough to handle whatever crazy new thing they try to do with the system, features like a complete initial ramdisk able to mount anything, are kind of a requirement and can't just be defined away.
Sure, if you only ever had to support one use and one hardware then you could remove a ton of abstractions and have a greatly simplified system but that's not something you can do if you are distributing systems for others to use in any environment.
> If everything was in /usr then I could not boot, period: systemd dies and I have to mount /usr and /var manually for it.
You pretty much have to have all filesystems mounted before you exit the initial ramdisk and start services in the live root filesystem, if you try to chroot into a system which is half missing then it won't work.
> Initial ram discs which duplicate tools that are installed on a box, and are hard to update, *are* kludgy hacks.
Initial ram disks provide a mechanism for the tools on your system to be accessible with a minimum of fuss because they are loaded by the firmware so that your filesystem is fully ready to go when you pivot into it and you aren't trying to run on a half-borken system. There is a policy in the kernel of pushing setup into user space of anything which can be done by userspace so you need to have a userspace capable of setting everything up, loading modules, mounting filesystems, iteratively as busses come online exposing new hardware, before you can transition into your root filesystem.
Posted Jun 17, 2015 12:26 UTC (Wed)
by nix (subscriber, #2304)
[Link] (2 responses)
However, on a rescue disk it's not like you can rely on swap anyway, and on modern systems this is not much of a limit: I've seen ramdisks that contain entire compiler toolchains and even kernel source trees for building needed kernel modules on command. You wouldn't want to keep that lying around in RAM on a general-purpose system (can you imagine how big the initrd/linked in initramfs must be?), but in a rescue disk it's fine.
Posted Jun 18, 2015 0:24 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (1 responses)
I have seen code which switches root to the initramfs and runs a binary from there on shutdown. Wouldn't that mean that the initrd needs to be kept resident all the time?
Posted Jun 18, 2015 8:38 UTC (Thu)
by mchapman (subscriber, #66589)
[Link]
No, the initramfs can be repopulated upon shutdown.
For example, with Dracut this is done by dracut-shutdown.service, which is pulled in by systemd's shutdown.target unit. See https://www.kernel.org/pub/linux/utils/boot/dracut/dracut... for details.
Systemd and containers
Systemd and containers
Systemd and containers
Systemd and containers
But heck, people can't even agree on what /usr means today -- I keep getting told it's Unix System Resources, but to me it's always been the /usEr/ directory.
Some of it gets a little strange, like finding a block of lego technics pieces in with your classics.
https://wiki.ubuntu.com/SystemdForUpstartUsers
It's short, it's sweet, and it's mostly useful for users of other distros as well just to get a quick cheat sheet on systemd.
Systemd and containers
Systemd and containers
Systemd and containers
Systemd and containers
Why make an arbitrary limit on the ramdisk to exclude it from being used as a rescue system?
There is a limit: initial ramdisks are not swappable (unlike, say, tmpfs). (This is why they are generally cleaned out and thrown away when switching to the initial root, so as not to waste precious physical RAM).
Systemd and containers
Systemd and containers