Systemd Starts Doing NTP/Timezones, Unified Cgroup Hierarchy

[rtfazeberdee]

Aren't on-disk logs always binary? I.e. doesn't one always need a program to read them?

Or does "text logs" mean they get printed by a line printer and are thus readable without any software?

Cheers,
_

This "lack of readability" of binary files is a complete red herring. You have to use a system program of some kind to view any file type.

[interested]

This "lack of readability" of binary files is a complete red herring. You have to use a system program of some kind to view any file type.

Not to mention that there are several binary non-text logfiles on standard Linux/Unix systems like "utmp" and "wtmp" that are a Posix requirement. You have to use as special log-viewer like "last" to view the content.

Good old "dmesg" is also a specialized log-viewer that can extract the binary content of the kernel ring-buffer, otherwise there would be no logging information about the boot process until rather late when the rootfs was mounted and Rsyslog was running.

And since the systemd journal fileformat is fully documented, it is also possible to make Linux standard tools like grep, grep directly on the journals, just like zgrep is used to grep gzipped syslog files.

And in any case all then standard Linux/Unix text tools work on systemd journals through the Unix concept of piping. So grep, tee, awk, sed, tac, sort etc. all work with journals when piped through "journalctl" or another journal reader like that.

[larkey]

maybe you should stop spreading bullshit if you have no clue?

Did I spread bullshit? I'm sorry but I only asked from a user-perspective who hears stuff from all around - and that's why I *explicitly stated* that I'm on almost no-knowledge about it and that one should not understand that as pure criticism on a high-level but more of a scepticism - ie. I'm *unsure*.

And due to all the input from here I've changed my opinion on systemd from 'pro but still quite sceptic' to 'pro and not-really-sceptic'. Thanks for the answers!

Would it really be possible to make systemd to split-packages? This would be awesome - or is it 'only' able to change its featureset via recompiling? If real split-packages were possible I would see virtually no reason against systemd anymore.

My own experience with systemd itself though was always positive. I never had any bugs with it or problems. I like the rather clear interface for configuring very much!

Also to pal666:
The Kernel is one of the least exceptions I'd tolerate which is 'allowed' to be monolithic as it still has a good performance impact to have a micro-kernel - sadly, actually.
But the Kernel is not that 'exposed' as a DHCP or networking stack. And my fear was that if you have systemd handle those rather security-critical things like networking ALONGSIDE to su/rightsmanagement could get... hairy.

[interested]

Would it really be possible to make systemd to split-packages? This would be awesome - or is it 'only' able to change its featureset via recompiling? If real split-packages were possible I would see virtually no reason against systemd anymore.

Fedora have split their systemd package into 4 sub-packages (not including compat-libs and devel files). I believe Debian have even more, eg. they have split out the OS container tools into a separate package.
You can easily split systemd into many more packages, but remember there is a administrative overhead for the distro for each package they create, so they need to balance out their workload versus granularity in the packages. So without some very good user cases, most general distros are unlikely to split systemd into +20 different packages, even though it is quite possible to do so.

[Stellarwind]

Anyway, I don't think the core of systemd ever will become too large since embedded Linux is an important target for systemd.

.. they actually care so much about embedded, that only support glibc and refuse to take patches for any other alternative.

[Stellarwind]

This "lack of readability" of binary files is a complete red herring. You have to use a system program of some kind to view any file type.

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.

[interested]

.. they actually care so much about embedded, that only support glibc and refuse to take patches for any other alternative.

They support any glibc compatible library, not just glibc, and they are willing to accept certain kinds of patches in order to support other libs than glibc. That they refused to accept musl patches that actually turned off security features is part of the "no cover up brokeness with band aids" policy of the project. Accepting turd patches that turns off security features was exactly what caused the "Heartbleed" vulnerability in OpenSSL.

In short, it is musl that need patching in order to gain the same features as glibc so it can seamlessly be supported by systemd, not systemd that needs patching.

[dangerousHobo]

They support any glibc compatible library, not just glibc, and they are willing to accept certain kinds of patches in order to support other libs than glibc. That they refused to accept musl patches that actually turned off security features is part of the "no cover up brokeness with band aids" policy of the project. Accepting turd patches that turns off security features was exactly what caused the "Heartbleed" vulnerability in OpenSSL.

In short, it is musl that need patching in order to gain the same features as glibc so it can seamlessly be supported by systemd, not systemd that needs patching.

No, musl libc doesn't need patching. The issue is systemd is dependent on non-standard libc features found in glibc. Which is what hard ties systemd to glibc and Linux.

[interested]

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.

First, if you got some kind of file corruption, then the last thing you want to do is to mess around on the system while the FS is read/write. You want to boot it from some media and chroot and mount the broken system as RO. Maybe the corruption was caused by some ransomeware that encrypted data, maybe it was fatal driver fault the systematically are destroying every 256th bit on the FS. It is trivial to read the journal log files from the boot media.

If it is just journactl that is broken and you know it isn't anything dangerous for the system, then you still got lots of options: just move the log-files to another system and read them there, or log into the machine remotely and use the remote machine as log reader, or use an alternative reader like "Gnome logs", or enable the gateway and browse the logfiles from a browser, either locally or remotely, or query the logs directly using Python (there a Python bindings for doing this), or of course just re-install journalctl.

Another option is to just reboot the system and set a breakpoint in initramfs so the boot process stops before mounting the rootfs. Then you just mount rootfs RO and read the journal logs _from the second copy of journalctl that exist in initramfs_.
Yes, you actually got a working systemd with service management and logging (both journald and journalctl) when using initramfs' like Dracut.

In short, there isn't any non-contrived scenario where it isn't possible to read the systemd binary journal logs.

[interested]

No, musl libc doesn't need patching. The issue is systemd is dependent on non-standard libc features found in glibc. Which is what hard ties systemd to glibc and Linux.

It is hardly surprising that systemd is Linux only. It is also LGPL, so BSD forks can't use it anyway since their paymasters insist on being able to close source the BSD code.

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.