Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 10, 2013 2:13 UTC (Tue) by cas (guest, #52554)
In reply to: Another daemon for managing control groups by anselm
Parent article: Another daemon for managing control groups

you say that as if it makes any practical difference at all. it doesn't.

can i run systemd as an init system *without* journald? no. systemd requires journald. it does not matter whether it forks a separate process or not.

and it does not help at all that systemd pushers say "just run *another* log daemon *as well as* (NOT instead of) journald if you don't like it". here's a free clue: someone saying "i don't want to run journald" is NOT saying "i want to run journald PLUS something else".

at best, if i play with the config, i can tell it not to store any log data on disk - but it's still running.

ditto with logind - WTF is the init system messing with logins? this is not something that an init system needs to do. it's just more systemd borg assimilation of everything.

and it's already got a half-arsed systemd/cron - systemd is the borg, it will assimilate everything.

so yeah, i fully expect systemd to have a mandatory web server within a few years (and if you're some kind of idiot that doesn't like it, just run something else on a high port and configure systemd-web to port-forward). and an irc server or text editor and whatever else lennartix feels like borging.

systemd probably wont have a C compiler because Pottering will no doubt invent his own super special language that is so much better than every other language ever that he'll just have to force everyone else to use it by making it mandatory for systemd. after all, he knows better than everyone else, so it's only fair that he gets to make that choice.

to post comments

Another daemon for managing control groups

Posted Dec 10, 2013 2:33 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> and it does not help at all that systemd pushers say "just run *another* log daemon *as well as* (NOT instead of) journald if you don't like it". here's a free clue: someone saying "i don't want to run journald" is NOT saying "i want to run journald PLUS something else".
And here's another free clue: journald can be considered an implementation detail as long as /var/log/journal doesn't exist. And complaining about implementation details usually doesn't make you look smart.

> ditto with logind - WTF is the init system messing with logins? this is not something that an init system needs to do. it's just more systemd borg assimilation of everything.
logind is completely optional.

The rest of your comment is so utterly stupid trolling that it doesn't deserve an answer.

Another daemon for managing control groups

Posted Dec 10, 2013 2:34 UTC (Tue) by dashesy (guest, #74652) [Link] (11 responses)

someone saying "i don't want to run journald"

Is analogous to "i don't want to eat my apple". It is like whining about kernel threads being running without being manually spawned, even though they do not hurt the performance or anything. Only if one has OCD, should care to control every single process running on a system.
Try it, it is one of the great things that happened to Linux and it is good for you.

Another daemon for managing control groups

Posted Dec 10, 2013 2:47 UTC (Tue) by cas (guest, #52554) [Link] (2 responses)

and here, along with the "response" by HelloWorld is a major part of the problem with systemd advocates.

*EVERY* *SINGLE* *OBJECTION* *TO* *ANYTHING* *ABOUT* *SYSTEMD* is dismissed with exactly the same unjustifiably arrogant 'we know better than you so just shut the fuck up and get with the program' response.

oddly enough, this is not likely to inspire any kind of trust or confidence.

worse, you lie. you say "oh, that's optional". except that it isn't optional. you can't disable journald. and if you try to disable logind or any of the other parts of systemd, you will break something - with a good chance of fucking up systemd so completely that it will fail to boot.

that does not meet the definition of "optional".

Another daemon for managing control groups

Posted Dec 10, 2013 3:10 UTC (Tue) by pizza (subscriber, #46) [Link]

> oddly enough, this is not likely to inspire any kind of trust or confidence.

Oddly enough, neither are raising objections that are plainly not supported by facts and have been debunked ad-nauseum.

Another daemon for managing control groups

Posted Jan 3, 2014 20:41 UTC (Fri) by rodgerd (guest, #58896) [Link]

I think before you go off on another sweary rant about the quality of discussion you might want to consider raising your own.

Another daemon for managing control groups

Posted Dec 10, 2013 7:33 UTC (Tue) by anselm (subscriber, #2796) [Link] (7 responses)

Try it, it is one of the great things that happened to Linux and it is good for you.

Doesn't matter. What matters is that it (a) was developed by Lennart Poettering, and (b) is not like syslogd, so must be bad – who cares if it comes with all sorts of compatibility features?

It's not as if these people could come up with a technical argument why systemd's journal (or indeed systemd in general) isn't a reasonable idea overall if their life depended on it. Bashing the very concept on general principles is their thing, and it is probably best to ignore them until they manage to find something to say that has actual substance.

Another daemon for managing control groups

Posted Dec 10, 2013 7:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

There is an argument to be made about too tight dependency on journald.

Systemd overall is a great idea, devil is in the details. As usual. And one of these small details is boneheaded attitude towards cgroups sharing with other actors.

Another daemon for managing control groups

Posted Jan 3, 2014 20:43 UTC (Fri) by rodgerd (guest, #58896) [Link] (5 responses)

There's a reasonable objection to be made about binary logging formats - system recovery and general analysis can be vastly more painful with such. It's a toss-up, because in many day-to-day cases journald's filtering is a win. But it's hardly an invalid complaint, unless you're considering "how we use logs to do our job" to be a non-technical complain, which would seem to be stretching.

Another daemon for managing control groups

Posted Jan 3, 2014 20:50 UTC (Fri) by raven667 (guest, #5198) [Link] (2 responses)

This is a reasonable place to do a risk analysis, how difficult is it to run the tool that can handle the file format of journald on a system that may not be working 100%, how often are the local logs not going to be sent via syslog to a central location? I don't think the designers of this would have done it this way unless they were convinced this was still a win but it's a discussion that can be had.

Another daemon for managing control groups

Posted Jan 3, 2014 21:53 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

rsyslog can get the logs from journald very rapidly, pretty close to real-time.

the designers of journald didn't have any idea what rsyslog, syslog-ng and similar logging daemons were able to do at the time they started journald, their justification of journald is full of "syslog can't do this" arguments that were true of traditional syslog, but not true on any of the modern syslog daemons.

journald works pretty well for a single machine personal system, but it was built in ignorance of how logging works in larger environments.

Another daemon for managing control groups

Posted Jan 3, 2014 22:06 UTC (Fri) by raven667 (guest, #5198) [Link]

> journald works pretty well for a single machine personal system, but it was built in ignorance of how logging works in larger environments.

Maybe you are right but it seems that when the systemd developers do something they do a ton of research before hand before committing resources. In any event it is pretty plain and stated that the journal isn't even trying to deal with networked logging or larger environments, it's main use case is the single personal machine, and capturing logs from early-boot which are normally lost. You don't judge a fish by how well it can climb trees.

Another daemon for managing control groups

Posted Jan 3, 2014 21:50 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

I would believe this more if there hadn't been a bug that prevented you from accessing the journald binary logs that went undetected for several months until it made it into a Fedora release that included rsyslog reading the files and going into a endless loop doing so (the journald tools also went into an endless loop, so you can't just call this a rsyslog bug)

This tells me that the people working on this are not actually using these tools enough.

Another daemon for managing control groups

Posted Jan 3, 2014 21:54 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> This tells me that the people working on this are not actually using these tools enough.

That is as ludicrous as saying any long-standing bug in the kernel shows that the kernel developers don't use Linux enough.

Bugs happen. People fix them (or at least, *should* fix them) when they discover them, not before.

Another daemon for managing control groups

Posted Dec 10, 2013 13:35 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

I think you're missing some things. Whether willfully or because you inspire knee-jerk reactions which snowball away from the original assertions or whatever, I'll avoid passing judgement for now, but we'll see how your reply goes.

First, yes, systemd provides a PID 1 binary which acts as init. It's not like there aren't other alternatives to sysv init out there (OpenRC, upstart, SMF, and more), so this is nothing particularly new.

Second, systemd has a goal of bringing a single *interface* (if you want to replace components, feel free[1]) to managing a Linux *system*. They also bring an implementation of the interface, but that's easily understood as using an interface before freezing it is rarely a bad thing. Managing a system includes a lot of things these days, like it or not. From hardware (udev) to users (multiseat is supported only in logind/systemd AFAIK and requires hardware awareness), these things all need to be coordinated by *something*. So where do you propose that be done? Systemd developers have laid out interfaces for you to adhere to if you want to replace individual components at will. They choose to do it in (or near, more often) PID 1. You would probably want it to be some service, but then you have to tie it with PID 1 anyways for dealing with services which trigger on hardware or network events anyways. Not to mention some FD passing to PID 1 to pass to the service. That's a lot of code that can be avoided if your aim is to minimize what PID 1 does (and still meet the use cases).

Third, for the (limited) cron features, PID 1 knows these things already (when a service started, when it last finished, etc.) and best. You're introducing more code by writing a daemon which does the same thing because now you have to reach from to watch services dying and showing up as well. Either way is more code, but now I can say "check email every 5 minutes" (as a user-level .timer unit) based on when I log in, not the clock values. What would a crontab entry which does that look like?

Last, you do like strawmen (e.g., I see no indication of systemd gaining an IRC server, but a link could help here) and name calling (Borg). If you could keep your arguments technical in nature, maybe you'd have a clearer discussion with others about your issues.

What it sounds like you want to do is remove components entirely, ignoring the use cases they cover because you don't care for them or can't see why they might be important. Try reading the rationales behind the components. Lennart is very clear when it comes to that. As an example, journald is there because syslog *is not available* at early boot. Would you rather PID 1 to start caching log messages (meaning more code), then swamp syslog as soon as it gets to that point? Or stick with the "no logs before syslog" behavior of today (or maybe that should be yesterday; systemd solved this over a year ago)? I guess you could delay everything until after syslog starts, but then you are sticking a delay in where nothing can be parallelized.

[1]Go ahead and implement the journald interface which just forwards stuff to syslog if you want. The interface has to be there, not systemd's implementation. But of course, journald already does that and by default usually I might add (journald persistence wasn't default in Fedora for a while, but probably will if/when rsyslog is kicked out of @base).

Another daemon for managing control groups

Posted Dec 11, 2013 22:18 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Would you rather PID 1 to start caching log messages (meaning more code), then swamp syslog as soon as it gets to that point?

If your syslogd cannot cope with a splurge of on-boot-time log messages, your syslogd is unbelievably awful (and would never be used).

Straw man.

Another daemon for managing control groups

Posted Dec 11, 2013 22:59 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I'll grant that a decent syslog should be able handle the initial logs, but that still means PID 1 is caching things.