systemd's syslogd replacement supports JSON output

Re:systemd's syslogd replacement supports JSON output by FooBarWidget on Saturday July 20, 2013 @05:53PM (#6076706)

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

[ Parent | on HN ]

Re:systemd's syslogd replacement supports JSON output by vertex-four on Saturday July 20, 2013 @06:04PM (#6076729)

You've read wrong, unfortunately. 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.

[ Parent | on HN ]

Re:systemd's syslogd replacement supports JSON output by teho on Saturday July 20, 2013 @08:55PM (#6077282)

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.

[ Parent | on HN ]

Re:systemd's syslogd replacement supports JSON output by vertex-four on Saturday July 20, 2013 @10:13PM (#6077503)

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

[ Parent | on HN ]