Systemd Starts Doing NTP/Timezones, Unified Cgroup Hierarchy

[boltronics]

I have been using systemd since 2011 and it has been rock solid all the time. The point is that systemd follows the same developer pattern as the Linux kernel that also has a "furious pace of development". That means frequent small releases with the occasional release being a LTS release (long term support). You will find those LTS releases in the systemd git repo.

Okay, so I tried systemd again. Figured it's been long enough for them to iron out the bugs.

Then just now I got an upgrade:

Setting up libdns-export100 (1:9.9.5.dfsg-9+deb8u3) ...
Setting up libisccfg-export90 (1:9.9.5.dfsg-9+deb8u3) ...
Setting up libirs-export91 (1:9.9.5.dfsg-9+deb8u3) ...
Setting up apt-utils (1.0.9.8.1) ...
Setting up rsyslog (8.4.2-1+deb8u1) ...
Job for rsyslog.service failed. See 'systemctl status rsyslog.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript rsyslog, action "restart" failed.
dpkg: error processing package rsyslog (--configure):
subprocess installed post-installation script returned error exit status 1
Setting up locales (2.19-18+deb8u1) ...
Generating locales (this might take a while)...
en_AU.UTF-8... done
Generation complete.
Processing triggers for libc-bin (2.19-18+deb8u1) ...
Errors were encountered while processing:
rsyslog
E: Sub-process /usr/bin/dpkg returned an error code (1)

Amazing. This is a clean install, and getting errors on the first dist-upgrade of jessie "stable". *Never* have such issues without it.

[finalzone]

Okay, so I tried systemd again. Figured it's been long enough for them to iron out the bugs.

Then just now I got an upgrade:

Setting up libdns-export100 (1:9.9.5.dfsg-9+deb8u3) ...
Setting up libisccfg-export90 (1:9.9.5.dfsg-9+deb8u3) ...
Setting up libirs-export91 (1:9.9.5.dfsg-9+deb8u3) ...
Setting up apt-utils (1.0.9.8.1) ...
Setting up rsyslog (8.4.2-1+deb8u1) ...
Job for rsyslog.service failed. See 'systemctl status rsyslog.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript rsyslog, action "restart" failed.
dpkg: error processing package rsyslog (--configure):
subprocess installed post-installation script returned error exit status 1
Setting up locales (2.19-18+deb8u1) ...
Generating locales (this might take a while)...
en_AU.UTF-8... done
Generation complete.
Processing triggers for libc-bin (2.19-18+deb8u1) ...
Errors were encountered while processing:
rsyslog
E: Sub-process /usr/bin/dpkg returned an error code (1)

Amazing. This is a clean install, and getting errors on the first dist-upgrade of jessie "stable". *Never* have such issues without it.

Look up at what caused the failure as described by journald.

systemctl status rsyslog.services

It seems to be a bad written rsyslog service on Debian or merely a bug. It is good thing such problems got detected and silent crash did not happen.

[ncopa]

And yes, it is exactly musl that needs patching so it support the features, including security features that systemd uses from glibc. Whether these features are "non-standard" or not a totally irrelevant.

Why do we even bother having standards at all if they are totally irrelevant anyway?

This all sounds like Internet Explorer 6. "If you want this web browser to work on those web pages you need to implement all the same features, including security features, that IE6 uses". Even Microsoft realizes that this was a bad idea.

[ncopa]

As an Arch user I got systemd pushed on me early and after the initial grunt and learning it I actually really like it with the exception of journald.

It has always been possible to mix and match components by you own taste in linux land so it should be simple to just replace it with something that you like and that fits your specific needs.

I don't use systemd myself but from what I read in this thread, it should be fully possible:

System-d is very modular and made of many different components, updated independently.

systemd programs are usable without each other, they depend not on programs, but on interfaces. make different implepentation of used interface and be happy. just like coreutils programs need some implementation of used interfaces like posix.

There is a misconception that systemd is a huge, bloated binary that encompasses everything. That is not the case, it is a collection of independent but integrated modules designed to work together that can be built, used, mixed and matched in various ways.

systemd's logger, journald, is supposed to be 100% compatible with all syslog(3) implementations like Rsyslog or syslog-ng

I have never tried replace journald in real life so I don't know if the above quotes are only empty words but it does sound trivial.

In worst case, it should be simple to rebuild it yourself without journald:

You can do that right now, they're called compile time switches, and you can cut systemd down to almost just the service manager (it's not an init system even though it replaces the init system) itself

However, I once tried to only build the udev component with musl libc and it insisted in building much much more than just udev and since many of those other components depend on non-standard GNU features, I gave up in the end. I suppose its easier to exclude a single component than it is to only build a specific tool.

[rtfazeberdee]

Sometimes you need to find logs in a binary mess on disk if something happened to your filesystem or disk itself, in that case journalctl is not going to help you at all, while you can still find and read normal text logs.

So if the sectors of your hard disk where your text log files reside has been splattered with binary zeroes due to a "failure", tell me how those files being text will make any difference. Do you also advocate that Oracle, MySql, postgres etc replace their files with plain old text because they'd be subject to the same criticism?

[interested]

Why do we even bother having standards at all if they are totally irrelevant anyway?

This all sounds like Internet Explorer 6. "If you want this web browser to work on those web pages you need to implement all the same features, including security features, that IE6 uses". Even Microsoft realizes that this was a bad idea.

Because there are many standards covering libc like Posix and ISO. So musl is far away from being standard compliant and in fact support non-standard features too. They call them "common extensions", which are grand words for non-standard features. So if you think that glibc is bad and non-standard, and musl is pure, think again. Glibc is _the_ libc standard on Linux, and musl lacks many features in order to become as standard compliant as glibc. There is actually a reason why musl is small, and that is because it doesn't cover as much as glibc does.

It is also important to understand, that some of these "common extensions" that glibc support, are in fact upcoming standard features. Both compilers and libc libs often integrate parts of a new upcoming standard before the standard is formally ratified. This is how development takes place, simply because standards change and gets expanded, and may take years to get ratified.

To sum up, musl needs to get with the program and implement similar "common extensions" as glibc in order to stay relevant in the future.

[interested]

It has always been possible to mix and match components by you own taste in linux land so it should be simple to just replace it with something that you like and that fits your specific needs.

Perhaps in the userland side on Linux, but not really when it comes to the more low level part of the OS. Then there have always been parts there was impossible to change for end users, and sometimes distro builders too. And often it is far from simple to replace eg. "su" from "shadow-utils" with the "su" from "util-linux" without experience feature regressions and subtle bugs. And sometimes alternatives simply don't exist.
Almost nothing of the low-level Linux stuff is actually "simple" to exchange without lots of work. This is why distros exist in the first place, and why they tend to be rather conservative about exchanging core components.

I have never tried replace journald in real life so I don't know if the above quotes are only empty words but it does sound trivial.
In worst case, it should be simple to rebuild it yourself without journald:

The core of systemd is quite small; systemd (the daemon), udev, journald. But removing "udev", "journald", and "systemd" (the daemon) isn't possible with a compile time option. They are possible to remove for those who knows what they are doing (minimal build), and "udev" can also be build as as stand alone program, see "eudev" which is just such a shadow fork of "udev". But this is strictly for embedded projects, not general use distros, since removing journald breaks a lot of functionality and tools.

The point is that you can use journald in such a way that Rsyslog works exactly as before so all legacy setups regarding log analyzing still works exactly as before. The only difference being that Rsyslog text logs now contains more and richer logging information. So it is always an improvement to use "journald" instead of using just Rsyslog. So why remove it all?

It is doable to make a "journald" replacement since the API is practically frozen (it is a "maybe" on the stability interface chart), but it had to be functionally equivalent to "journald", so the only reason to bother making such a replacement would be to have non-standard extensions that the systemd developers wouldn't accept. So probably a small or non-existing user case for doing it.

[PyroDevil]

This might be a bit off topic, but since the linux kernel supports live patching and the feature list of systemd continues to grow, does anyone know if it is currently possible to live update the pid1 part of systemd?
Is that even necessary or is it already possible with some existing linux tools?

[interested]

This might be a bit off topic, but since the linux kernel supports live patching and the feature list of systemd continues to grow, does anyone know if it is currently possible to live update the pid1 part of systemd?
Is that even necessary or is it already possible with some existing linux tools?

To quote the systemctl man page:
"daemon-reexec

Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible."

So yes, it is quite possible to do and even without losing any client connections to eg. http, cupsd and similar.

That said, remember that the kernel live patching are meant for minor security patches, not for major kernel revisions.

[PyroDevil]

To quote the systemctl man page:
"daemon-reexec

Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible."

So yes, it is quite possible to do and even without losing any client connections to eg. http, cupsd and similar.

That said, remember that the kernel live patching are meant for minor security patches, not for major kernel revisions.

Nice, thanks!