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

151–160 of 263 posts

Re: Why systemd?

#151

Post by allegory »

bigbugbag wrote: post #142
vidarh wrote: post #111

Earlier quoted context omitted.

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 ef…

For me Linux is pretty dead already because I can't entirely trust the direct it's going in having survived the Unix wars of the 1990s. There are so many parallels to that at the moment, it's not funny. There are large vendors pulling it in separate directions (Canonical, Redhat, Google). At the end of the day, much like back then, customers will suffer from terrible support, fragmentation and political battles.

I just want to get shit done and solve problems and anything that risks that gets outed now.

FreeBSD hits the sweet spot, probably followed by NetBSD.

Re: Why systemd?

#152

Post by edwintorok »

na85 wrote: post #10
dsr_ wrote: post #4

The reason people use UNIX-like systems is because they work reliably. In order to make a complex system work reliably, it needs to be easily fixed. In order to fix a system, a person needs to understand it as well as be able to make a change in it. And in order to understand a system, it helps very much if that system is straightforward and lucidly verbose. I hope systemd will live or die on its merits; I fear that…

It already has taken over despite being mediocre at best. Mostly I feel that it got an undue jumpstart thanks to RedHat trying too hard to be bleeding edge, and Upstart/OpenRC not having as high-profile a backer.

The problem is that some projects started depending on systemd behaviour now and the transition hasn't been smooth at all in Debian even if you want to stay with sysvinit. I'm still on sysvinit with systemd-shim, and things started to break in KDE already, mostly related to authentication (can't mount USB devices, can't manage VPN connections, etc.). In the end I'm afraid Debian users might not have much choice: either use systemd as PID1, or use another distribution (like Gentoo, etc.) that work without systemd.

Re: Why systemd?

#153

Post by vidarh »

hueving wrote: post #144
vidarh wrote: post #110

Earlier quoted context omitted.

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

Add enough machines, and "narrow corner cases" happens all the time and at all the wrong moments.

The bigger point is that there are lots of these "narrow corner cases" all over a typical SysV-init setup, not least due to tons of badly written init scripts. The number of times services have failed to start

To produce a systemd alternative, creating something that competes favorably with SysV-init is insufficient. Today you also need to demonstrate how you deal with those corner cases, or why they don't matter - many of us have no intention of going back to the bad old days.

Re: Why systemd?

#154

Post by e12e »

rdtsc wrote: post #76
smutticus wrote: post #41

Earlier quoted context omitted.

It's this kind of crap that scares me away from systemd. I have no problems working with current init structures, so I gain nothing from systemd. It basically just removes options from me, and gives me nothing in return that I actually want. What we ultimately lose with systemd is modularity. If we cannot upgrade systemd without also upgrading the kernel, then systemd might as well be considered part of the kernel.

Modularity and isolation is at the core of reliability. I think it is worthy discussion if a tradeoff beteween 30 sec and 15 sec boot time is worth that sometimes your boot process might lock up. I think there was already at least one visible problem with systemd stepping on kernel developer's toes (so to speak) by re-using one of the debug flags. Heck kernel is monolithic. But thinkign about it, I trust kernel devel…

On the plus side, maybe HURD will get more love and be pushed to production-ready status...

Re: Why systemd?

#155

Post by bigbugbag »

jude- wrote: post #62
drdaeman wrote: post #36

Earlier quoted context omitted.

Well, journald has syslog compatibility layer and can talk syslog, so supporting any existing software is not an issue. It doesn't speak syslog by itself, so it probably can't forward logs to another networked syslog server, but I don't see anything that prevents implementing this, if necessary. The point is, journald also introduces a new protocol that's oriented at logging structured data. This way it not just prov…

Compatibility isn't the problem. The problem is the use of structured binary data itself for logs. Logging binary structures instead of raw text makes it very difficult to recover from crashes or misbehavior, since the logging facility (journald or otherwise) must ensure that the log's structure on disk is consistent at all times. I've seen more than my fair share of journald corrupting its own log due to unclean shu…

Not sure it was built for the task we expect a log facility to fulfill. I mean the corruption issue is a built in feature of journald: https://bugs.freedesktop.org/show_bug.cgi?id=64116

Re: Why systemd?

#156

Post by pdkl95 »

audidude wrote: post #35
nisa wrote: post #31

Earlier quoted context omitted.

> What's opaque about Free and Open Source C code? Everything if you are sysadmin/developer trying to fix an issue. At first you need debugging symbols to pinpoint the problem, then you need to read the source.. it all takes time. E.g. you need to learn about dbus-monitor and dbus calls and need to grasp some internal concepts of systemd if something goes wrong. It takes time and patience you usally don't have or don…

> I don't want to say that one is better than the other but the latter is for most folks far easier to debug and modify than the first. Generally bad form to make claims on behalf of "most folks" since you are in fact a single person. It's totally a valid argument if you say this on your own behalf. And yes, bugs happen. But fixing the C code, is in my experience, much easier than tracking them down in `bash -x`. Esp…

> fixing the C code, is in my experience, much easier

Really?

Did you account for the many very subtle ways you can run into what the C language defines as "undefined behavior"? I have only met a few programmers that truly understand that can of worms. Way too many don';t even know that compilers exploit these parts of the spec despite programming in C for many years.

http://blog.regehr.org/archives/213

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

That's just the cases where it it is totally legal for the compiler to output random noise - or output nothing at all - instead of what the C code says locally. These are some of the nastiest "gotchas" I've seen in any language.[1] Even the best C programmers are occasionally bit by this class of bug.

I still like C (a lot), but it is not easy. It's just so very annoying and time consuming to track down a bug happening in "foo.c" that is actually caused by a variable in "bar.c" didn't get updated waaaaaay earlier because some bit of code in "quux.c" was skipped over due to undefined behavior. Especially it becomes a heisenbug due to that particular optimization being turned off when in in debug builds.[2]

Bourne [Again] shell has its own share of quirks and "gotchas", but they are usually easy to investigate, and they are generally easy to avoid once you've written a couple scripts.

[1] There are other important classes of bug; I'm just using undefined behavior as an example because of how amazingly subtle it can be and how many serious security bugs it has caused.

[2] Before anybody complains that behavior involving 3 files like that is bad design, consider that A) this happens all the time in real world C, and B) I agree. Which is why many of us are against systemd, which adds complicated interactions like this on purpose as a way to force vertical integration.

Re: Why systemd?

#157

Post by edwintorok »

hueving wrote: post #144
vidarh wrote: post #110

Earlier quoted context omitted.

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

Also you depend every-day on another process that is special in some sense just as the process manager: Xorg. If Xorg dies all your desktop applications die. By your line of reasoning Xorg should be moved into PID 1 too, which is definetely not a good idea.

I don't say that Xorg hasn't crashed, it did rarely when running RC code or proprietary drivers. In fact I probably had as many Xorg crashes as kernel panics, which says something about how stable Xorg is. Still I wouldn't want to run it as PID1, where a crash would really bring down everything.

Re: Why systemd?

#158

Post by bigbugbag »

pjmlp wrote: post #118
ultramancool wrote: post #5

Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to. I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single…

> So recently, I just gave up and moved to FreeBSD. Not a single regret so far. It all depends on the use cases. For me, FreeBSD is a no go given my desktop usage requirements.

what about the desktop oriented BSD such as dragonfly or pc-bsd ?

Re: Why systemd?

#159

Post by edwintorok »

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.

The main question is would it work? For me systemd or applications starting to support systemd only break things (something wrong with policykit/consolekit for example with sysvinit+systemd-shim) that used to work.

Also there are some peculiarities in the way the LSB init script compatibility is implemented in systemd: it tries to be 'smart' and remember their state. So you start an init script, and it failed for some reason / perhaps even exited with an error code, perhaps you are still developing that init script. Now fixing the problem and running the init script / systemctl start doesn't even try to run the script because it thinks it has run it yet. You first have to tell it to stop it (which fails), and only then you can run it again.

Re: Why systemd?

#160

Post by e12e »

nn3 wrote: post #82
drdaeman wrote: post #19

Earlier quoted context omitted.

I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So,…

sqlite (or other "real databases") need a fsync for every or at least many transaction to be data safe. Without that it is far more prone to losing data than journald, because with a write ahead log the window for losing data is far bigger. And a journal that has another journal inside it would be somewhat silly. A simple write log can be done better. I don't think fsync on every log commit is a good idea. This would…

I have some difficulty figuring out the use-cases for journald over (some) plainish text log files. Our disks are getting faster and bigger. If you need to consolidate logs you have many options (starting with rsyslogd). If you need to log gigs of data, that can't possibly be kernel/initd logs?! And if it's application logs why not pipe it through something for indexing? By definition if i need kernel/local/init log files it's because something went very wrong: in such cases problems with clean shutdown/startup seems very likely - and in such use - cases plain text to file/serial wins hands down.

I'm not against having a wrapper that magically slurps stderr/stdout to timestamped logs -- but if that can't be written cleanly with the apis we have, then surely what we need is to make the minimal improvement in our (probably kernel) api to make writing such a program a trivial exercise? Nothing I've seen of systemd has me convinced the project cares one whit about finding the simplest, least coupled solution to any problem.

Post reply on HN