Systemd and containers

Posted Jun 15, 2015 14:03 UTC (Mon) by dps (guest, #5725)
In reply to: Systemd and containers by raven667
Parent article: Systemd and containers

Anybody that has had significant hard disc problems and other complex problems knows that a functional system that does not require a large filesystem, like /usr, to work is worth a lot when the chips are down. Sane size initial ram discs just don't and can't provide that but small root filesystems with /bin and /lib can. The tools you need to fix your initial ram disc are unlikely be available if that is all you have.

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.

Systemd and containers

Posted Jun 16, 2015 17:16 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

> Sane size initial ram discs just don't and can't provide that but small root filesystems with /bin and /lib can.

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.

Systemd and containers

Posted Jun 17, 2015 12:26 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

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

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.

Systemd and containers

Posted Jun 18, 2015 0:24 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

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

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?

Systemd and containers

Posted Jun 18, 2015 8:38 UTC (Thu) by mchapman (subscriber, #66589) [Link]

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

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.