

systemd's syslogd replacement supports JSON output - moonboots
http://www.freedesktop.org/wiki/Software/systemd/json/

======
gnosis
There some competing trends in the *nix world today.

On the one hand, there are some huge, monolithic packages like Xorg that have
split in to many smaller, more independent packages.

On the other hand, we have something like systemd absorbing ever more
functionality, becoming more monolithic with feature bloat.

I am personally more in favor of having many small, simple tools that each do
one function well and can be easily integrated together, and understood
independently of each other, rather than going the monolithic route.

To me, systemd is one gigantic step backwards from this vision, even if it has
some (or even many) good ideas.

~~~
FooBarWidget
A quick look into systemd reveals that it's comprised of multiple components.
For example the journal service is a separate daemon. What part of this does
not align with your vision?

EDIT: looks like the "monolithic" myth has already been busted:
[http://0pointer.de/blog/projects/the-biggest-
myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html)

I would say the distinction between systemd and older systems is that systemd
follows the "better is better" mantra of design, while older systems follow
the "worse is better" mantra of design. Older systems often feel like quick
hacks. For example SysV init is a collection of init scripts. Yeah it is
"simple" in that the init service itself is simple, but writing the scripts
themselves is anything but simple, and they are brittle as well. How often
have you seen init scripts failing during startup or boot? And why must you
write daemon management code over and over again your init scripts? All this
does is pushing complexity out of the init service and into the scripts.
Systemd is taking complexity upon itself so that the scripts can be simple.

~~~
Tobu
It's monolithic because you can't pick and choose the components.

You have to use all of systemd, or none of it. You can't replace bits of it,
or use just parts of it.

~~~
FooBarWidget
And how exactly does Xorg allow you to use parts of it? More importantly, what
parts of systemd do you not want to use or do you want to replace, and why?

EDIT: what you're saying appears to be untrue. According to
[http://0pointer.de/blog/projects/the-biggest-
myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html), they
provide configure switches for enabling or disabling many things, not unlike
how the Linux kernel allows you to enable or disable features.

You know, there are _so_ many people here bashing on Lennart, I'm wondering
whether any of you have done your homework at all or because you just bash
Lennart for the sake of it. I'm not even using systemd and I found these
things in 5 minutes.

~~~
DASD
I'd like to not use udev. I have a custom Linux that runs both on
standardized(internally defined) servers and also virtualized(known hardware)
servers. As such, I'm well under 900ms boot times that systemd mentions by
using SysV init. But the systemd project does not accept patches
([http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/](http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/))
to disable what is considered a core component.

~~~
FooBarWidget
Alright, point taken. Then systemd is not for you. However I want to argue
that not all software _should_ cater to everybody. While modularity (which in
this discussion is apparently defined as "the ability to disable or swap
components") is often seen as a good thing, there are quite a lot of downsides
as well:

\- Certain guarantees and consistencies disappear. Instead of having a system
that you know you can rely on, it suddenly becomes entirely dependent on the
configuration options. While it sounds nice if any part can be enabled,
disabled, moved or swapped, then the system's predictability goes down.
Furthermore, some combinations may be incompatible because abstractions are
inherently leaky. Good luck finding out whether you're suffering from a
compatibility problem or not. You can compare this to the many complaints
about Android fragmentation. Because everybody can customize Android, writing
an app that works on all Android devices becomes extremely difficult.

\- Installation complexity goes way up. It's much easier to install a system
if it states "I need this, this and this", instead of "I can use this, or
this, or this, if it's configured in X, Y and Z way".

\- Certain features cannot be implemented in a simple manner because you have
to cater to the lowest common denominator. XFree86 was like that. Because it
had to be portable, it cannot assume any kernel capabilities. And as a result
XFree86 came with its own mode setting code, its own ELF binary loader, had to
run as root, etc etc.

~~~
vertex-four
> However I want to argue that not all software should cater to everybody.

The issue here is that the Linux kernel developers are starting to make
decisions that assume systemd is being used. For example, the (proposed?) new
cgroups API is being built with the idea that systemd will manage it, and
anything else that wants to interact with it will go through systemd.

~~~
FooBarWidget
That isn't what I read at all. The cgroups maintainer wants a flat cgroups
list so that the code is easier to maintain, but Lennart said he must have
hierarchical tree so that systemd can take full control over at least a part
of the tree. That's hardly "being built with the idea that systemd will manage
it".

~~~
vertex-four
You've read wrong, unfortunately.
[http://lwn.net/Articles/557082/](http://lwn.net/Articles/557082/) describes
that:

> Unprivileged access to the cgroup hierarchy will be strongly discouraged;
> the hope is to have a single, privileged process handling all of the cgroup
> management tasks. That process will, in turn, provide some sort of higher-
> level interface to the rest of the system.

and that:

> This hierarchy becomes private property of systemd. systemd will set it up.
> Systemd will maintain it. Systemd will rearrange it. Other software that
> wants to make use of cgroups can do so only through systemd's APIs.

That is, systemd will implement a manager on top of the new cgroups API, and
all cgroups users will be assumed to go through systemd.

~~~
teho
systemd manages cgroups on systemd based system. The systems that do not use
systemd can implement their own cgroup managers. The kernel makes no
assumptions on what manager you use on userspace. Other managers could also
reimplement the systemd dbus API for managing the cgroups.

~~~
vertex-four
> The systems that do not use systemd can implement their own cgroup managers.
> [...] Other managers could also reimplement the systemd dbus API for
> managing the cgroups.

True, except that the systemd developers are in charge of defining this API
and have no reason to consult with other cgroups manager developers when
defining it. This is, to make an analogy, equivalent to allowing Microsoft to
unilaterally define all web standards from now on. The competitors are always
going to be playing catch-up, and there's going to be tons of edge cases where
the competitors don't quite work the same.

------
dsr_
This is of course exactly the killer feature that would convert me into a true
systemd believer. The only thing better would be to have an ASN.1
representation of the logs as the native format, for the sake of portability.
After all, if you don't have tools to analyze your logs for you, you might as
well not even have logs.

------
oblio
After hearing both sides of the argument over and over again (for systemd and
against systemd), my only regret is that Ubuntu is not replacing upstart with
systemd, so that Loonix will have a uniform boot system.

To all the systemd naysayers, please read the docs before commenting, 90% of
the comments against systemd look like they've been written by someone who:

a) hasn't used systemd

b) hasn't read anything relevant about systemd

Basically most comments come straight out of the blog post about systemd
myths. That's really, really sad.

------
veeti
Before this thread devolves into the same arguments all over again, maybe
everyone could read the following:

[http://0pointer.de/blog/projects/the-biggest-
myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html)

------
duck_typer
Is this a good time to define Poettering's Law - any simple and useful Unix
service will eventually get rewritten into a monstrous uber service that
requires a supercomputer just to run, what should be, a simple service.

~~~
FooBarWidget
Which is easy for you to state, were it not for the fact that the "simple
service" is broken in various ways.

Let's start with the implementation-specific brokenness. I configured a log
host with rsyslog. Rsyslog's configuration format, as well as documentation,
is completely abysmal. And once in a while, rsyslog would use 100% CPU for no
reason. A quick strace reveals that it keeps reading or writing to a file
descriptor, but getting EAGAIN as error. Looks like a bug to me. And oh yeah,
there's a race condition in rsyslog with regard to privilege lowering, so that
sometimes it would great directories owned as root, and then it would lower
its privilege, and then it would be unable to write to its own created
directory. Just great.

The above are all fixable. But what bothers me more is that __syslog is
entirely unauthenticated __. Any process can write to syslog, claiming that it
is any process. A malicious user can write a syslog entry saying that
"init[1]: the system is unstable. please reboot now!". As an administrator,
you will not be able to tell whether the message actually came from init (or
PID 1) or not. A quick look at systemd's journal mechanism reveals systemd at
least has thought about these problems:
[http://www.freedesktop.org/software/systemd/man/systemd.jour...](http://www.freedesktop.org/software/systemd/man/systemd.journal-
fields.html). It would log the process's PID, UID, GID and more, and the
sender is unable to fake that.

~~~
spc476
systemd can log the PID, UID and GID of a message because its using a Linux-
specific feature of datagram based local sockets; such a feature cannot be
supported on other Unix systems. But there are other reasons to use
syslogd/rsyslogd/syslog-ng besides logging to local files, and that's to
forward the logs to a centralized logging service. Of course, there are issues
with that, as the default syslog protocol also allows any process, anywhere,
to claim it is any other process (and if root, even fake its own source
address) but it's being addressed (I know rsyslogd is, I'm not sure about
other syslogd replacements).

My issue with systemd is that forwarding logs to a central server is an
afterthought, if even that. And the problem with that is that it won't be as
secure or work as well if it's part of the design. And another issue with the
"afterthought support for remote logging" is that I _still need_ to run
syslogd/rsyslogd/syslog-ng because I have a ton of other network equipment
(routers) that can forward their logs via the syslog protocol (which I have
used on networks I've managed---by doing that, I've been able to receive
notifications of OSPF routing changes, for instance). And if I have
syslogd/rsyslogd/syslog-ng already running, what are the benefits of systemd
logging?

~~~
FooBarWidget
Regarding PID/UID/GID logging: if it has to use a Linux-specific feature to be
less broken in that regard, then I'm all for it. In my opinion, authentication
is such an important security feature that other Unices should just implement
similar mechanisms (or, preferably, the same mechanism). Right now I've only
seen the BSD people complaining that systemd uses Linux-specific features, but
doing nothing to solve the problem.

Regarding central logging: indeed, that is a problem. Has Lennart ever spoken
about this issue?

~~~
spc476
The impression I've gotten is that he isn't interested in centralized logging,
as that is outside of what he is trying to do.

I could be wrong though.

------
senko
Lennart, please add the f*ng mail reader in there already and be finished with
it.

------
static_typed
The way this is going, Linux will end up as a single process operating system,
that will do everything at web scale. All outputs in glorious binary format.

Funny, the crowd got distracted over Gnone3, Unity or Mir, or the latest worry
of the day, yet never saw the big threat in their camp.

Linux isn't done until the text processor won't run.

~~~
teho
systemd is hardly monolithic as it is build of over 80 binaries. A normal
system with systemd runs at least four processes: systemd (PID1), systemd-
udev, systemd-journald and systemd-logind. There's various smaller services
that are run on startup and other occasions. Then there are many configration
utilities like timedatectl (systemd-timedated), hostnamectl (systemd-
hostnamed) and localectl (systemd-localed).

------
weitzj
But what if it's used for evil? :0

~~~
tzs
It doesn't look like they are using Douglas Crockford's JSON implementation,
so using it for evil is probably OK.

~~~
weitzj
Thanks for the upvote. I did not know my karma would get busted for my
comment.

