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

Why systemd?

blog.jorgenschaefer.de

Post reply on HN
Print view View original

141–150 of 263 posts

Re: Why systemd?

#141

Post by exDM69 »

dmix wrote: post #88
uselessdguy wrote: post #51

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…

I appreciate your work on uselessd. Nothing demonstrates a counterpoint quite like written code. The last thing we need is another ranting systemd blog post. We always need strong alternatives, even if they face the risk of being taken as simply a political statement, the effects of the statement will be seen in the decision-making down the road.

Yes! What the systemd "discussion" has been missing is viable alternatives that are somewhat comparable in features. Most of the flamewar is focused on people who consider the problems that systemd tries to solve non-issues.

There are some real issues being pointed out (particularly regarding monolithic design) but no-one has attempted to actually fix that in any way (in code, that is).

While it is unlikely that I will end up using uselessd (unless it "wins" in some way, e.g. in embedded space with uclibc and musl), I very much welcome the effort to bring out alternatives that address the same problems as systemd, yet trying to fix some of the issues there are.

Re: Why systemd?

#142

Post by bigbugbag »

vidarh wrote: post #111
aerique wrote: post #107

Earlier quoted context omitted.

Are there reasons why Linux couldn't just adopt it?

Feel free. Most people won't, as systemd solves very real problems that people care a great deal about, whether or not you like the way it has solved them.

15 years linux user here, systemd is pushing me hard towards leaving linux. Please tell me what very real problems people care a great dead bout systemd solved by turning log files from text to binary.

Also I care about being able to use my computer and for the first in 15 years a systemd update caused my computer to needlessly dropping into systemd emergency mode at boot and this emergency mode being broken I was effectively locked out of my computer because an optional external usb drive that was defined in fstab with no issue for a couple years now required a nofail option. Now consider that this computer is located in a remote location 1000 km away from where I live.

To me systemd already caused way more very real problems I do care a great deal about than it has solved reducing boot time by a few seconds is not something I care that much about.

Re: Why systemd?

#143

Post by allegory »

_delirium wrote: post #124
allegory wrote: post #103

Earlier quoted context omitted.

This. The FreeBSD rc system just works, is well documented and is small enough to understand by one person without too much effort.

As an init system it works fine, but you do end up having to find or invent a bunch of additional stuff if you want similar functionality to what's driving some of the systemd use-cases. The result might still be better (I haven't done a detailed architectural comparison), but you do need something . For example one of the things I find useful about the "systemd way" of things is that it provides, finally, a story ab…

RCTL is a stateful database. It's not there yet, but the right solution for managing this declaratively as with anything else on a Unix platform is Ansible/salt/cfengine or something like that, not building those tools into a superset service that manages everything.

I will also add that managing disparate platforms is never a reality from experience. There are perhaps two core platforms at a company and they are migrated together in blocks, all together. For us, we have a couple of legacy Ubuntu machines that are being canned this month. Everything else is Windows 2012 R2 and FreeBSD 10.

The "systemd way" is to provide a monolithic abstraction over many things with a DBus API. It's the equivalent of adding WMI and a registry to a Unix platform i.e. it's against the fundamental tenets of the operating system. Having managed windows systems for years, this is really not something I want to see. Time will tell, but if I'm not right about that then I'll eat all three of my hats.

And yes I have experience with systemd as well through evaluation of RHEL7. Within two hours, I'd hit a wall with timedatectl enabling NTP on the machine. The steps to debug the mess were horrible and the issue eventually just spontaneously disappeared.

That's reminiscent of the stateful nature of windows which brings back many years of pain in the 1990's and 00's for me.

Re: Why systemd?

#144

Post by hueving »

vidarh wrote: post #110
uselessdguy wrote: post #51

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…

> The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set the session and process group IDs, and optionally exec the process manager. The process manager gets killed. How do you recover? If you have respawn logic for it in PID 1, how do you log information about a failure to respawn the process manager? Perhaps you build in some basic logic for logging. Whe…

Isn't that a pretty narrow corner case? I can count the number of times the process manager has been killed on one hand.

Re: Why systemd?

#145

Post by clarry »

e12e wrote: post #139
jsnell wrote: post #49

Earlier quoted context omitted.

My machine with systemd (FC20) doesn't boot up at all unless systemd loglevel is set to debug on the command line. Even with it it takes about 5 minutes to boot. Luckily I don't need to reboot often, but every single time there's a small fear that some upgrade has made systemd crap up even worse, and the system won't boot at all. How do you debug a complete black box, where turning on debugging partly fixes the probl…

Reminds me of the joyful early days of moving from grub to lilo. Grub was (is) more fragile due to being more complex -- but at least the grub shell gives more information than lilo failing at "LI"... Grub always seemed like the improved features made up for the added complexity; I'm not convinced about systemd.

Even Grub isn't all flowery. I have a background of using what I think is now called grub-legacy. Then I ended up running Debian, with newfangled Grub. I needed to change some kernel parameter (IIRC) but all I could find was a mess of undocumented scripts which say "don't touch this". I don't know where the documentation went, and it seemed needlessly complicated to configure. Why couldn't I say man grub and learn all I need about it? I had other issues with Debian, but the last straw was when during a routine package update it decided to install a new version of Grub.. and the next time, it wouldn't boot anymore. Why was it so complicated in the first place? Why did Debian have to fix it if it's not broken? Why did it fail to do it right? I don't know, I don't really care... all I know is that needless complexity and churn caused trouble, again.

So I'm no longer using Grub or Debian. And my bootloader is simple. I've installed it once, and never touched it afterwards. It's possible to configure it a little, but there's no need for it. So what if it has fewer features. It only needs to load the damn kernel... and it works. I'm happy.

Re: Why systemd?

#146

Post by allegory »

Andys wrote: post #108
aerique wrote: post #107

Earlier quoted context omitted.

Are there reasons why Linux couldn't just adopt it?

There's nothing stopping a Linux distro doing this.... but It would be a step backwards: it is simpler, and does less stuff, so booting would be slower and some features are missing.

How often do you reboot your kit? Boot time is such a stupid metric even on laptops and stuff where you just suspend/hibernate.

My BSD systems (not front-facing and therefore on a lesser patch cycle) rarely get rebooted and neither do the processes so this is indeed moot for me.

Proof:

http://i.imgur.com/tZsM82Q.png

Yes that's a memcached uptime on a host that has had 10,185,367,932 cache hits...

Re: Why systemd?

#147

Post by allegory »

chousuke wrote: post #127
rjsw wrote: post #119

Earlier quoted context omitted.

Why would booting be slower ? My BSD systems boot quickly enough for me.

My FreeBSD system has a 30-second timeout during which the entire boot process is halted because it waits for a default route to the internet... which it won't get, because I haven't configured one. It's pretty dumb, and not enough of a problem for me that I'd figure out how to work around it, but it's a pretty good example.

Just set in rc.conf:

   defaultrouter="NO"
It shouldn't hang.

Re: Why systemd?

#148

Post by vidarh »

chousuke wrote: post #129
vidarh wrote: post #115

Earlier quoted context omitted.

From experience with Linux init scripts, I'm far less concerned about systemd than SysV-init style boot processes, to be honest. I lost track of the number of boot issues related to poorly written init scripts I've dealt with many years ago.

I have an anecdote that occurred a short while while ago. We had a server with several database instances (with their own init scripts) running on it. The scripts were buggy in such a way that starting the database would bring it up okay, but prevent the rest of the instances from starting. Also, using the "stop" directive would successfully stop the database... and all the others, as well. The bug probably occurred…

Sounds familiar..

One of my "favourite" problems with init scripts for service stop/start is that way too many of them basically throws their hands up if the contents of the pid-file doesn't match what it expects. Never mind that 90% of the time when I want to actually run stop/start/restart, it is because something has crashed or is misbehaving, and there's a high likelihood the pid file does not reflect reality.

So a far too common scenario is: Process dies. Tries to run "start". Nothing happens, because the pid-file exists and the script doesn't verify that the pid actually matches a running process (or it checks that it matches a running process, but not that the process with that pid is actually what we want).

Ok, so we try "restart" or "stop". Gets an error, because the pid-file content does not match a running process, and rather than then cleaning out the pid file and starting the process, it just bails.

Basically I don't trust init scripts from anyone but distro maintainers themselves, and even then there are often plenty of edge cases that cause problems.

Regardless of systemd, I really like the systemd solution to this of using cgroups to ensure it can keep proper track of exactly which processes belongs to a service without resorting to brittle pid-files which seem to rarely be properly implemented. Of course that cgroups approach could be implemented as a separate tool, but pid-files badly needs to die.

Re: Why systemd?

#149

Post by edwintorok »

vidarh wrote: post #110
uselessdguy wrote: post #51

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…

> The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set the session and process group IDs, and optionally exec the process manager. The process manager gets killed. How do you recover? If you have respawn logic for it in PID 1, how do you log information about a failure to respawn the process manager? Perhaps you build in some basic logic for logging. Whe…

I think the ideas presented in the 's6' init system address most of these issues, I don't know why none of the distributions picked it up as an alternative: http://skarnet.org/software/s6/why.html http://skarnet.org/software/s6/s6-svscan-1.html

Re: Why systemd?

#150

Post by e12e »

rdtsc wrote: post #75
navait wrote: post #42

Earlier quoted context omitted.

This init process debate has brought out one of the worst elements of people in the FOSS community: treating some FOSS technology as an extension of their identity. Let's keep some perspective here. We are literally just talking about an init system. There are many others you can use. systemd is not taking away your freedom in any meaningful sense of the word "freedom". Debates should be about the technical merits of…

> There are many others you can use. I understand your good motivations but just saying "it will be ok" doesn't make the problem go away. Yes I can write my own init system, that's good. Can I uninstall systemd from most system that install and depend on it by default. Write my own distro? You can't just easily plug and play it. It is a big like the kernel. Just swapping out Linux kernel with a FreeBSD one doesn't qu…

> It is a big like the kernel. Just swapping out Linux kernel with a FreeBSD one doesn't quite work.

Well, actually that's the heart of the problem right there. Systemd mangles and complects things. You can replace the kernel (see Debian/kfreebsd and to a lesser extent Illumos). Or you can make a "distro" like cygwin/mingw et al for windows and homebrew for os x. Because there are some more or less well defined interfaces between userland and kernel space. Not just "shit that systemd does that makes sense on recent linux kernels" (afaik there's no plans for supporting something like linux 2.4 on small embedded systems for example).

Post reply on HN