Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Broken by design: systemd

ewontfix.com

Post reply on HN
Print view View original

11–20 of 48 posts

Re: Broken by design: systemd

#11

Post by dalias »

zanny wrote: post #8
zimbatm wrote: post #4

systemd is like a second kernel in user-space.

Which should be good. If the OPs arguments about how dangerous it is to empower and stuff a lot of functionality into pid 1, think of how running in kernel mode on a cpu gives you power when your code is in the kernel proper. So moving functionality out of kernel mode and into user mode is great. The only steps after that are moving as much functionality as possible to the user, and then to nobody. We do trend toward…

Functionality is not being moved out of the kernel and into userspace. It's being moved out of legacy freedesktop.org components (hald, ConsoleKit, PolicyKit, etc.) and into PID 1. Where should it be moved to? /dev/null.

Re: Broken by design: systemd

#12

Post by rcxdude »

zanny wrote: post #7
rcxdude wrote: post #3

Earlier quoted context omitted.

I don't know. Given what I know about how cgroups and systemd works, I don't think there's any particular issue with having a thin shim and starting systemd as PID 2, and so getting some of the reliability gains this article talks about. But I don't have all that much knowledge of the details and there may be good technical reasons why that is a bad idea (the man page notes that it is possible via a command line flag…

The article remarks its pid 1 to catch "bad" services that disown their parents and get defaulted to pid 1. But I figure if they switched the bulk of systemd to pid 2, any negligent services would get complained about until they were fixed.

This is something systemd can already handle. Linux has APIs to change the 'reaper' process (PR_SET_CHILD_SUBREAPER) so that orphaned processes move to a non PID 1 process.

Re: Broken by design: systemd

#13

Post by nona »

Not everything of systemd is in PID 1. And yes, what some people consider necessary and important or even essential features missing from sysvinit, others consider bloat.

Just to ensure we're all talking about the same thing, here's an overview of systemd's footprint: http://people.debian.org/~stapelberg/docs/systemd-dependenci...

From the article: "On most machines, systemd will bring from 236 KiB to 550 KiB of additional libraries to be loaded into memory. When recompiling systemd without its optional dependencies (e.g. for embedded systems), this shrinks to 368 KiB in the worst case.

The RSS (Resident Set Size) of systemd is 1.8 MiB, whereas sysvinit uses 0.8 MiB — both measured on typical Debian wheezy installations."

Re: Broken by design: systemd

#14

Post by TheCondor »

Why don't the anti-systemd folks publish some actual attacks against that big ol' attack surface?

I've been using it for maybe 18 months, it was different and different is some times scary but I have had no problems at all. Migrated some legacy init scripts and it's a piece of cake. It's fast, it works, it does what it claims to do. I've been shipping unix software mostly on linux for 15 years and there are very real reasons systemd, launchd, smf, upstart and other "do more than nothing" init systems exist and companies making money selling them write them. All of them are much much more simple for the administrator to use too...

Re: Broken by design: systemd

#15

Post by nona »

dalias wrote: post #11
zanny wrote: post #8

Earlier quoted context omitted.

Which should be good. If the OPs arguments about how dangerous it is to empower and stuff a lot of functionality into pid 1, think of how running in kernel mode on a cpu gives you power when your code is in the kernel proper. So moving functionality out of kernel mode and into user mode is great. The only steps after that are moving as much functionality as possible to the user, and then to nobody. We do trend toward…

Functionality is not being moved out of the kernel and into userspace. It's being moved out of legacy freedesktop.org components (hald, ConsoleKit, PolicyKit, etc.) and into PID 1. Where should it be moved to? /dev/null.

I think you need to look a bit more closely at what's actually going into PID 1. See for example: http://people.debian.org/~stapelberg/docs/systemd-dependenci...

I don't see any logind/hostnamed/journald or any of that stuff in PID1.

Re: Broken by design: systemd

#16

Post by nly »

> systemd makes it impossible to upgrade without rebooting. This leads to "Linux" becoming the laughing stock of Windows fans, as happened with Ubuntu a long time ago.

This irked me. It's just an unnecessary comparison. The ZDnet article linked is, and always was, completely fallacious in comparing an OS critical update channel to a fully-fledged distro package manager. Having just bought a brand new Windows laptop this weekend, I found myself spending no less than 2 hours tirelessly updating and rebooting Windows, and searching for, and installing, driver updates manually. It's 2014 and it still sucks. Windows update and OEM updaters are, in my experience, piss-poor and don't pick up half of the updates available to your average system.

Frankly I think your average Linux desktop could easily risk doubling or tripling the number and frequency of reboots demanded, and you'd still not reach a significant fraction of the annoyance of Windows on that particular front.

Re: Broken by design: systemd

#17

Post by pekk »

nly wrote: post #16

> systemd makes it impossible to upgrade without rebooting. This leads to "Linux" becoming the laughing stock of Windows fans, as happened with Ubuntu a long time ago. This irked me. It's just an unnecessary comparison. The ZDnet article linked is, and always was, completely fallacious in comparing an OS critical update channel to a fully-fledged distro package manager. Having just bought a brand new Windows laptop t…

And all the servers? They are supposed to just keep rebooting all the time as if they were Windows desktops?

Re: Broken by design: systemd

#18

Post by pekk »

Fasebook wrote: post #9
ploxiln wrote: post #6

I've used systemd on Arch Linux for about a year now. It wasn't the end of the world, I can deal with it, but it's not fun. I'm bothered by seemingly built-in units that have no corresponding unit files, which all default to enabled, including units for bootsplash stuff ("plymouth") that isn't used on arch linux. I'm very annoyed by mounts and such that don't even have units, files or otherwise, such as the "pstore"…

It seems to me that there is concerted effort to discredit alternative init implementations. Example: https://en.wikipedia.org/w/index.php?title=Daemontools&actio... I can't imagine what agency with a history of undermining technical standards could possibly be involved.

Why don't you just say what you mean.

Re: Broken by design: systemd

#19

Post by mwcampbell »

It seems to me that, in keeping with its long tradition of being conservative, Debian should put off switching its init system for at least another release, since systemd is by no means the clear winner from a strictly technical point of view.

Re: Broken by design: systemd

#20

Post by dalias »

TheCondor wrote: post #14

Why don't the anti-systemd folks publish some actual attacks against that big ol' attack surface? I've been using it for maybe 18 months, it was different and different is some times scary but I have had no problems at all. Migrated some legacy init scripts and it's a piece of cake. It's fast, it works, it does what it claims to do. I've been shipping unix software mostly on linux for 15 years and there are very real…

Folks on #musl found 2 integer overflow bugs in the UTF-8 handling code within seconds of checking out the source to read it. It's not clear to me where the code is called from and what inputs reach it, but that kind of bug does not inspire confidence in the safety of the project as a whole. I also quickly found a case where a potentially-null string pointer is passed to a logging function which might or might not be able to accept null string pointers. (I suspect it uses snprintf and therefore depends on the underlying C library's handling of this usage, which is undefined behavior.)
Post reply on HN