Trimming legacy fat with systemd

Recently, Michael Stapelberg prepared a detailed listing of systemd's component sizes. It clearly shows how much space is really required, and how much space can be saved by giving up various optional components of systemd. It's a nice document. On the other hand, how much we can save by dropping legacy shell utilities?

Let's take some hypothetical system not designed to be accessed interactively by sysadmin. You may call it embedded, you may call it minimal cloud image or just specialised spin/just-enough-OS. We are going to remove all the tools which duplicate functionality already provided by systemd.

Above binaries are needed because they’re doing something plain shell scripts can’t do – syscalls. Growing number of Linux API can be manipulated by means of echo, mkdir and ln, but there always will be need for some syscalls.

By removing legacy utilites, we save total of (magical) 640 kilobytes. Not much. Probably not worth the hassle. What else can we remove? /usr/sbin/hostname (20 304 bytes)? start-stop-daemon? vcsonsole setup, quotacheck, sysctl, cryptsetup, syslog, acpid?

Sizes were collected on Fedora 20 amd64 system.

Archived comments:

Stanisław 'dozzie' Klekot 2013-07-17 23:32:33

Erm.
/usr/bin/cd -- What is this? I've never seen such binary (probably because it's impossible to expose chdir() as an external command).
/usr/bin/umask -- The same. What is it?
/usr/bin/su, which is rarely located in /usr/bin, is pretty much required anyway for any system that is not horribly crippled (mainly for interactive use; I do not consider it a tool to use in scripts).

syslog virtually cannot be removed from system. systemd's journald is not (and doesn't seem to be going to be) a sensible solution for general-purpose logging and it focuses on collecting logs on a single host. Unattended or embedded system should be able to log to some remote destination.

And all the rest of your breakdown, it's actually useless. You try to measure size of executables for purposely-built system, but you take references from a desktop OS. You haven't even scratched surface of special purpose systems (BusyBox anyone?).

zdz 2013-07-18 08:38:04

% cat /usr/bin/umask
#!/bin/sh
builtin umask "$@"

And other builtins in similar manner.
For busybox, I'm not sure if it provides ”enough Linux” to run systemd.

Stanisław 'dozzie' Klekot 2013-07-18 10:10:25

Okay, and how do you expect that to affect *parent* process you issued the command in? Because bash and zsh don't take the shortcut of trying to execute the script in the same process.

shasta 2013-07-18 20:48:45

dozzie, you say that syslog cannot be removed? Well, apparently Lennart sees things differently ;-)
http://thread.gmane.org/gmane.linux.redhat.fedora.devel.announce/1117/

Stanisław 'dozzie' Klekot 2013-07-18 21:05:19

Of course he sees things that way. He is the creator of journald. But hey! Suddenly there is still a need for syslog!

Journald can't operate sensibly in installations intended for no interactive sessions. There just has to be remote logging possibility, and that journald doesn't provide.

Journald is pretty much only good for desktop cases. It will do for Fedora, as I don't know of anybody using it on servers anyway, but it's way too crippled logging solution to replace syslog altogether.

You may read a bit of Rainer Gerhards' articles about journald, shasta. He's the author of rsyslog, so he is biased the other way (but very little, I think) -- this should straighten your view on logging.

shasta 2013-07-18 23:04:43

Why do you think my view on logging needs straightening? :-) I didn't say I agree with Lennart.

I am a big fan of syslog-ng, plus - as a long time Slackware user I don't see journald/systemd crawling into my bed anytime soon. Honestly, I'm just a spectator for this whole systemd drama, watching it from a safe distance. ;-)

And as for work, well, I will always have to deal with some sort of crap anyway, so whether this is Solaris 8 or systemd - doesn't make much of a difference to me ;-)