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

systemd's syslogd replacement supports JSON output

freedesktop.org

Post reply on HN
Print view View original

31–40 of 54 posts

Re: systemd's syslogd replacement supports JSON output

#31

Post by Tobu »

FooBarWidget wrote: post #17
Tobu wrote: post #14

Earlier quoted context omitted.

I can't disable the journal, for example. If I run something more full-featured, I'll still be streaming things through the journal. It's not at all like the kernel does it. With Linux, there are multiple competing implementations of most features, pushed by people with competing interests. There is a lot more room for debate and experimentation.

According to 'man journald.conf', you can set "Storage=none". If by "monolithic" you mean the lack of multiple competing implementations, then lots and lots of things are monolithic. Apache and Nginx would be monolithic by your definition.

(Storage=none is streaming things through the journal, which I have no use for)

Apache2 and Nginx are modular. Let me tell you the story of a small web application.

Once upon a time, requests were hitting an Apache server, dispatched to mod_python, and an embedded interpreter was keeping itself warm running Python code to answer the requests.

As the site grew, and the state of the art evolved, a programmer wrapped the application in a wsgi container, and gave it to a mod_wsgi container so that it would run at its own pace.

One day, the programmer brought home an nginx server it had found freezing in the tundra, and gave it a job serving static content in front of Apache. Nginx brought his uwsgi friend and they took turns running the site, nginx serving images and scripts, uwsgi replacing mod_wsgi.

This is what a competitive space looks like. Apache has competing modules, there are http servers and wsgi servers, some of them embedded, some of them external, http servers can collaborate or replace each other when a better thing comes along.

You don't see an http server deciding it will be the sole http server on the system, swallowing a wsgi server and waging war to all others.

Re: systemd's syslogd replacement supports JSON output

#32

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

Re: systemd's syslogd replacement supports JSON output

#33

Post by Tobu »

zanny wrote: post #25
Tobu wrote: post #9

Earlier quoted context omitted.

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.

Ubuntu just started using logind in 13.04, but haven't adopted the rest of systemd. Some parts (journal, systemd core, udev) can't be detached, but a lot of the peripheral software outside the init -> maintain services -> log events process are optional.

Ubuntu is splitting logind from systemd with no help from the systemd maintainers, because some gnome projects have started requiring logind. That effort is spent undoing Lennart's work swallowing most of the consolekit code base into systemd. The systemd maintainers won't accept patches that make logind a separate project again.

Re: systemd's syslogd replacement supports JSON output

#34

Post by spc476 »

FooBarWidget wrote: post #30
spc476 wrote: post #23

Earlier quoted context omitted.

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

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

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.

Re: systemd's syslogd replacement supports JSON output

#35

Post by spc476 »

asveikau wrote: post #29
FooBarWidget wrote: post #8

Earlier quoted context omitted.

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

Reading this I thought: how does one authenticate a pid or uid in a daemon? I am assuming Unix domain sockets, which don't provide you with the caller's pid or uid. Doing some googling I found there are indeed nonportable interfaces for this. First I found getpeerucred which is a Sun thing. Then I found Linux has a SO_PEERCRED socket option. [Edit: and there seems to exist getpeereid and LOCAL_CRED on some BSDs] Stil…

Unix domain sockets are the way to pass open file descriptors between processes, though (why? I don't know, it just is). I think that because of that, the mechanism was extended to also pass along the PID, UID and GID. I did use the open file descriptor with SO_PEERCRED options to implement a Linux-only daemon to open privileged sockets on behalf of a process: https://github.com/spc476/ipacld (something I'm surprised has never been written before).

Re: systemd's syslogd replacement supports JSON output

#36

Post by fosap »

mordae wrote: post #21
duck_typer wrote: post #3

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.

No, what happened was init scripts. Something completely alien to the original init tab concept. It was an extremely ugly hack that worked only because of extensive documentation and effort by much larger amount of people than systemd has now. Both systemd and journal are an actual solution. Try journalctl on your system, it actually makes sense! The silly thing even has bash completion of filtering criteria! And the…

something that was not necessary. Init scripts can be nice and clean [1]. And yes, I'm all for a init replacement. Something new, nice and clean. But I take the shell script hackery over a dbus dependency. But that's just my personal opinion.

I have neither used it nor looked at the code, but [2] seems to be what I want. It's by the libdietc author, so i expect the code to be small, elegant and not maintained very well.

[1] http://www.freebsd.org/doc/en/articles/rc-scripting/rcng-dum...

[2] http://www.fefe.de/minit/

Re: systemd's syslogd replacement supports JSON output

#37

Post by vertex-four »

FooBarWidget wrote: post #20
DASD wrote: post #13

Earlier quoted context omitted.

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/ ) to disable what is considered a core component.

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

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

Re: systemd's syslogd replacement supports JSON output

#38

Post by asveikau »

spc476 wrote: post #35
asveikau wrote: post #29

Earlier quoted context omitted.

Reading this I thought: how does one authenticate a pid or uid in a daemon? I am assuming Unix domain sockets, which don't provide you with the caller's pid or uid. Doing some googling I found there are indeed nonportable interfaces for this. First I found getpeerucred which is a Sun thing. Then I found Linux has a SO_PEERCRED socket option. [Edit: and there seems to exist getpeereid and LOCAL_CRED on some BSDs] Stil…

Unix domain sockets are the way to pass open file descriptors between processes, though (why? I don't know, it just is). I think that because of that, the mechanism was extended to also pass along the PID, UID and GID. I did use the open file descriptor with SO_PEERCRED options to implement a Linux-only daemon to open privileged sockets on behalf of a process: https://github.com/spc476/ipacld (something I'm surprised…

I think the easier way is to create the socket with high privileges, then drop down to lower privilege.

Re: systemd's syslogd replacement supports JSON output

#39

Post by wereHamster »

gnosis wrote: post #4

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…

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

You should note that this is generally looked at as a bad move. Creating two separate packages for each protocol (one headers, one implementation), separate packages for each individual app etc. lead to a lot of unnecessary overhead for everybody (developers, release managers, package maintainers etc). Over the last couple years people have suggested to merge some of the packages back into the main xserver repository.

Re: systemd's syslogd replacement supports JSON output

#40

Post by FooBarWidget »

vertex-four wrote: post #37
FooBarWidget wrote: post #20

Earlier quoted context omitted.

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

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

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".
Post reply on HN