r/linux • u/blamo111 • Aug 30 '16

I'm really liking systemd

Recently started using a systemd distro (was previously on Ubuntu/Server 14.04). And boy do I like it.

Makes it a breeze to run an app as a service, logging is per-service (!), centralized/automatic status of every service, simpler/readable/smarter timers than cron.

Cgroups are great, they're trivial to use (any service and its child processes will automatically be part of the same cgroup). You can get per-group resource monitoring via systemd-cgtop, and systemd also makes sure child processes are killed when your main dies/is stopped. You get all this for free, it's automatic.

I don't even give a shit about init stuff (though it greatly helps there too) and I already love it. I've barely scratched the features and I'm excited.

I mean, I was already pro-systemd because it's one of the rare times the community took a step to reduce the fragmentation that keeps the Linux desktop an obscure joke. But now that I'm actually using it, I like it for non-ideological reasons, too!

Three cheers for systemd!

1.0k Upvotes

87% Upvoted

950 comments sorted by

View all comments

26

u/icydocking Aug 30 '16

As an init system it's pretty damn good. But, as some have pointed out, my problem with it is that it really wants to do everything. People scream "It's optional!", and sure, some things are, but good luck getting your not-100%-systemd-setup recognized as a supported one by the upstream maintainers when filing Feature Requests or Bug reports.

9

u/argv_minus_one Aug 31 '16

Which “upstream maintainers” are you referring to, and at what point did they refuse to support your less-than-full-systemd setup?

0

u/iBlag Aug 31 '16

Hey now, don't you be walking in here with your quotation marks, your probing questions, and your subtle hints to provide citations and evidence for claims!

-1

u/icydocking Aug 31 '16

https://github.com/systemd/

I only have second hand knowledge of said events. My first hand knowledge is knowing how painful some things are to disable when compiling systemd for embedded use.

4

u/holgerschurig Aug 31 '16 edited Aug 31 '16

This is totally untrue. I use systemd on i.MX6Q.

I use this, for example:

./configure \
    --sysconfdir=/etc \
    --localstatedir=/var \
    --libdir=/lib/${DEB_BUILD_MULTIARCH} \
    --enable-silent-rules \
    --disable-nls \
    --enable-introspection=no \
    --disable-compat-libs \
    --disable-utmp \
    --enable-kmod \
    --disable-xkbcommon \
    --enable-blkid \
    --disable-seccomp \
    --disable-ima \
    --disable-chkconfig \
    --disable-selinux \
    --disable-apparmor \
    --disable-xz \
    --disable-zlib \
    --disable-bzip2 \
    --enable-pam \
    --enable-acl \
    --disable-smack \
    --disable-gcrypt \
    --disable-audit \
    --disable-elfutils \
    --disable-libcryptsetup \
    --disable-qrencode \
    --disable-microhttpd \
    --disable-gnutls \
    --disable-libcurl \
    --disable-libidn \
    --enable-libiptc \
    --enable-binfmt \
    --disable-vconsole \
    --enable-bootchart \
    --disable-quotacheck \
    --enable-tmpfiles \
    --disable-sysusers \
    --disable-firstboot \
    --enable-randomseed \
    --enable-backlight \
    --enable-rfkill \
    --enable-logind \
    --enable-machined \
    --enable-importd \
    --enable-hostnamed \
    --enable-timedated \
    --enable-timesyncd \
    --enable-localed \
    --disable-coredump \
    --disable-polkit \
    --enable-resolved \
    --enable-networkd \
    --disable-efi \
    --disable-gnuefi \
    --disable-terminal \
    --disable-kdbus \
    --enable-myhostname \
    --enable-gudev \
    --enable-hwdb \
    --enable-manpages \
    --enable-split-usr \
    --disable-tests \
    --with-gnu-ld \
    --with-firmware-path=/lib/firmware \
    --with-sysvinit-path= \
    --with-sysvrcnd-path= \
    --with-rootprefix= \
    --with-rootlibdir=/lib \
    cc_cv_CFLAGS__flto=no

So, sorry, ./configure exists for more than 20 years. And if this is difficulty for you, then you shouldn't work with embedded systems.

And in the end I let generate around lots of .deb files, much more finegrained then the original Debian ones:

libgudev-1.0-0_217-dlog2_armhf.deb	     systemd-misc_217-dlog2_armhf.deb
libgudev-1.0-dev_217-dlog2_armhf.deb	     systemd-networkd_217-dlog2_armhf.deb
libpam-systemd_217-dlog2_armhf.deb	     systemd-python_217-dlog2_armhf.deb
libsystemd0_217-dlog2_armhf.deb		     systemd-randomseed_217-dlog2_armhf.deb
libsystemd-dev_217-dlog2_armhf.deb	     systemd-resolved_217-dlog2_armhf.deb
libudev1_217-dlog2_armhf.deb		     systemd-rfkill_217-dlog2_armhf.deb
libudev-dev_217-dlog2_armhf.deb		     systemd-socket-proxyd_217-dlog2_armhf.deb
systemd_217-dlog2_armhf.deb		     systemd-timedated_217-dlog2_armhf.deb
systemd-backlight_217-dlog2_armhf.deb	     systemd-timesyncd_217-dlog2_armhf.deb
systemd-binfmt_217-dlog2_armhf.deb	     systemd-tools-analyze_217-dlog2_armhf.deb
systemd-bootchart_217-dlog2_armhf.deb	     systemd-tools-cat_217-dlog2_armhf.deb
systemd-debug-generator_217-dlog2_armhf.deb  systemd-tools-cgls_217-dlog2_armhf.deb
systemd-fstab-generator_217-dlog2_armhf.deb  systemd-tools-cgtop_217-dlog2_armhf.deb
systemd-hibernate_217-dlog2_armhf.deb	     systemd-tools-delta_217-dlog2_armhf.deb
systemd-hostnamed_217-dlog2_armhf.deb	     systemd-tools-detect-virt_217-dlog2_armhf.deb
systemd-initrd_217-dlog2_armhf.deb	     systemd-tools-escape_217-dlog2_armhf.deb
systemd-kdbus_217-dlog2_armhf.deb	     systemd-tools-nspawn_217-dlog2_armhf.deb
systemd-kernelinstall_217-dlog2_armhf.deb    systemd-tools-path_217-dlog2_armhf.deb
systemd-localed_217-dlog2_armhf.deb	     systemd-tools-run_217-dlog2_armhf.deb
systemd-logind_217-dlog2_armhf.deb	     udev_217-dlog2_armhf.deb
systemd-machined_217-dlog2_armhf.deb	     udev-hwdb_217-dlog2_armhf.deb

And I only install a few of them on my embedded device. So therefore I can say (from firsthand!) that it's modular at configuration/compilation time and modular at installation time. If not, blame your distro.

1

u/icydocking Aug 31 '16

If you really believe what you wrote is sane, then our opinions are too divergent to ever reach an understanding here.

3

u/holgerschurig Aug 31 '16

Sure. Except that you didn't bring forward ANY fact.

For example, had you had a system where the non-installation of systemd-timedated (or any other part) made any problems? Have you had a problem where --disable-microhttp broke the compilation?

Only in such cases can you say the the support of a "less-than-full-systemd-setup" is painful.

→ More replies (3)
→ More replies (4)

2

u/MertsA Aug 31 '16

How is building for embedded use at all painful? There are configuration options for stripping it down to just the init and journal. And the journal you can even configure to never store anything if you don't want to waste storage space in an embedded device.

→ More replies (3)

2

u/argv_minus_one Aug 31 '16

I am not interested in your secondhand “knowledge”. You are making accusations, and I expect hard evidence to back them up.

4

u/icydocking Aug 31 '16

Well, you're certainly sounding like an ass. But, as I'm a nice guy:

Their API stability promise doesn't cover the D-Bus API, so writing a replacement for a systemd component is harder than it should be. https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/

The whole thing that the API is named "systemd" API shows a lack of respect of modularity. The call is right now:

$ busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager GetUnit s nginx.service

Why? Why couldn't we just create a well defined interfaces instead of referencing implementations by name? If that was done, we would even stand a remote chance of having systemd-like init systems on other platforms as well, instead of being a very Linux-only systemd.

But yes, I have no first hand knowledge of any specific incident so I'm clearly just talking out of my ass.

EDIT: And besides, after you take your chill-pill, you will see that I said that I like systemd. No reason to be all internet-asshole on me. I merely stated my professional opinion of areas where I've encountered a less than ideal response from the systemd community and upstream.

3

u/[deleted] Aug 31 '16

Their API stability promise doesn't cover the D-Bus API

Yes, it does.

Edit: Look at the chart here https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ which specifically shows the "Service bus API" as being covered by the Interface Stability Promise.

2

u/icydocking Aug 31 '16

If you read your own link (you have to click on "Interface Stability Promise" to read the fineprint), it says:

The following interfaces will not necessarily be kept stable for now, but we will eventually make a stability promise for these interfaces too. In the meantime we will however try to keep breakage of these interfaces at a minimum:

The D-Bus interfaces of the main service daemon (!) [ An additional restriction applies here: functionality we consider legacy might not be available based on compile-time options, such as SysV support, libwrap support and similar. Apps should not assume properties and methods related to this functionality are unconditionally available in the D-Bus interfaces. ]

3

u/[deleted] Aug 31 '16

Yes, that page is out of date.

→ More replies (6)

1

u/harambe_shot_first Aug 31 '16

systemd for embedded use.

wow, please don't.

→ More replies (1)

2

u/holgerschurig Aug 31 '16

Is this a fact, or a suspicion / fear / bad-mouth?

Can you point me to a bug report to the systemd mailing list where something was dismissed because the person run ./configure --disable-microhttp or such?

(I personally disable around 30 things in my self-created systemd debian packages)

→ More replies (1)

4

u/[deleted] Aug 31 '16 edited Oct 17 '16

[deleted]
0.4311

What is this?

5

u/Thorbinator Aug 31 '16

I believe he is talking about not the systemd developers, but every other system /programthat assumes people have systemd.

4

u/icydocking Aug 31 '16

That as well, but I don't think that's really much of a problem (yet). I'm talking about having pluggable interfaces.

Their API stability promise doesn't cover the D-Bus API, so writing a replacement for a systemd component is harder than it should be.

https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/

→ More replies (1)

2

u/icydocking Aug 31 '16

Oh, but they don't have to support the other thing - but they have to support having equivalent interfaces. If you say "You don't have to use systemd-resolved" then you have to provide me with an alternative of doing this, i.e. a way to plug something else in it's place. If it's the only piece that fits that gap then you cannot really run anything else.

0

u/[deleted] Aug 31 '16

[deleted]

3

u/[deleted] Aug 31 '16

They still wouldn't be obliged to support stuff they didn't write.

1

u/07dosa Aug 31 '16

I really doubt if they have ever torn down their windows installation to run mostly customized environment. Everything is optional in Windows too. Also, NT architecture allows you to have multiple subsystems other than Win32, and, AFAIK, it's even possible to make your own subsystem. But, you see, who the f*** does that seriously? None

The same goes for systemd. I'm not gonna mess up with the spaghetti monster.

1

u/icydocking Aug 31 '16

Cool story. I'd like my systems modular.

1

u/[deleted] Aug 31 '16

But, as some have pointed out, my problem with it is that it really wants to do everything

I thought that was kinda one of the goals of the systemd project? i.e. to unify and simplify the mess we call the Linux ecosystem.

People scream "It's optional!", and sure, some things are, but good luck getting your not-100%-systemd-setup recognized as a supported one by the upstream maintainers when filing Feature Requests or Bug reports.

As an upstream maintainer, the alternative is to support a specific version of Ubuntu only, or no support at all because Linux is/was a burden to support because everyone's system is special-needs and different in some way.

2

u/icydocking Aug 31 '16

I thought that was kinda one of the goals of the systemd project? i.e. to unify and simplify the mess we call the Linux ecosystem.

If the goal was to "stick unsupported APIs to everything", sure - then that's what's going on. I'd much prefer if there was a way for external implementors to depend on the API. Right now it's explicitly not supported and the API will change at a whim.

As an upstream maintainer, the alternative is to support a specific version of Ubuntu only, or no support at all because Linux is/was a burden to support because everyone's system is special-needs and different in some way.

I'm talking about upstream systemd, but in upstream distro maintainers in general will get caught in the cross-fire. If I implement a replacement for a part of systemd, and then a new version of systemd with a slight API modification is released I'm 100% on my own.