Systemd Starts Doing NTP/Timezones, Unified Cgroup Hierarchy

[pal666]

I've got nothing against the project itself doing the job of almost everything... - but why not make it a *bit* more modular? Systemd just as a project with submodules that are released in 'one cycle' and developed close together - yet useable without each other?

My 'dream' would be it being similar to the GNU Core Utils:
Different programs that are definitely useable without each other - but still 'one'.

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.

What if there's a security-critical bug in it? Update ALL of systemd?

IT IS NOT THAT BIG!!!1111
how do you update your kernel when there is security-critical bug in it? ALL KERNEL ?????

Again, I don't know much about systemd but there come also problems and doubts with it all being 'one thing' and not 'one project'.

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

Also non-binary logs should be defaults, at least have both activated as sane default... ;-)

your distro developers(they chose default) seem to be smarter than you, but you are free to fuck yourself whatever way you like

[jpp650]

I suspect that the next service of systemd, to be added to its current number of 10^200 services, will be a hidden "phone home" service for uploading personal data to somewhere ....

[interested]

I've got nothing against the project itself doing the job of almost everything... - but why not make it a *bit* more modular? Systemd just as a project with submodules that are released in 'one cycle' and developed close together - yet useable without each other?

Especially when it comes to networking one also needs to think of security and minimal layouts. I'm not really knowing much about systemd-networkd *exactly* works but it seems to be a DHCP server too - likely also other network-related stuff.

The networking stack in systemd, called "libsystemd-network" is build around a library, and that library is supposed to be released for general use, including non-systemd distros, after an API review:

http://www.linuxplumbersconf.org/2014/ocw/proposals/2091

Mind you, the systemd networking stack is pretty bleeding edge with lots of new features for every systemd release. I don't think any distros have turned it on as default for the same reason. It is mainly an OS Container thing at the moment because it can solve problems that no other networking utilities can.

What if there's a security-critical bug in it? Update ALL of systemd?

That depends entirely on the distro and how it package systemd. It is quite possible to split systemd into several packages and then only update the affected sub-package.

Again, I don't know much about systemd but there come also problems and doubts with it all being 'one thing' and not 'one project'.


Also non-binary logs should be defaults, at least have both activated as sane default... ;-)

Legacy text logs as default or not is an distro decision. systemd's logger, journald, is supposed to be 100% compatible with all syslog(3) implementations like Rsyslog or syslog-ng, so if the distro have Rsyslog as default logging daemon, it can produce text logs. Think of "journald" as a syslog helper program that can enhance syslog, or also be used as a stand alone alternative.

What systemd's "journald" can't do is to provide legacy text logs on its own. The reasons for this is are many and complex but if it did this, then it wouldn't be compatible with syslog(3) daemons, nor would it be syslog(3) implementation neutral, since the text log format differs between implementations and differs with what features are turned on. There several deep limitations with the Linux kernel that prescribe how the systemd logger is designed. Among these that only one program can read from /dev/log at a time or else random log messages will disappear. That is also the reason why the Linux kernel logs its boot logs to /dev/kmsg, a binary, syslog-incompatible logging format that are stored in the kernel ring-buffer and that requires a special program to read (dmesg).

systemd's logging system is a major enhancement of the Linux logging system, even if you just use legacy text logs, since it makes it possible to have "metal-to-metal" logging. That means logging from the split second the kernel boots until after the root files system have been unmounted and the system shut down. systemd and journald can do this because they become alive already in initramfs and then pivot to the rootfs, and then pivot back to initramfs after the rest of the system has shut down.

[jacob]

I've got nothing against the project itself doing the job of almost everything... - but why not make it a *bit* more modular? Systemd just as a project with submodules that are released in 'one cycle' and developed close together - yet useable without each other?

This is more or less *exactly* what systemd is. And it is also being used that way: Ubuntu 14.04, for example, is not based on systemd, but it still uses systemd's udev, logind and more. Ubuntu 15.04, on the other hand, is a full systemd distro, but nevertheless it decided not to use systemd's networkd. 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.

[interested]

Jokes apart, they have been doing some things that were needed long ago. My only 2 worries about the project are:

1. Project becomes so large that will be not maintainable or difficult for new devs to get involved in the code base.
2. Systemd development halts and due to dependency on it and it's module became a pain to go back or develop alternatives.

Becoming too large and unwieldy is always a danger for projects like systemd. Luckily they seem very aware of this and regularly trim the project for stuff that isn't needed nor get the developer attention it should. So "systemd-ui" and the readahead daemon got ditched because no-one really cared for them anymore, and the Python bindings also got separated into a independent project.

They are also quite strict when it comes what kind of patches they accept with an explicit "no cover up problems with band aids" policy so they don't end up like OpenSSL that accepted some really drive-by "turd" patches, like the one that circumvented security measures and caused the "Heartbleed" vulnerability just because some old close source Unix couldn't be bothered to modernize its developer tools.

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

If systemd development in general stops, then it would either mean that Linux distros no longer used it, or that Linux in general was becoming a "has been" OS like OS/2 that nobody used. In the first case it would mean that alternatives already existed, in the latter case that alternatives didn't really matter anymore.

[nightmarex]

...
systemd's logging system is a major enhancement of the Linux logging system, even if you just use legacy text logs, since it makes it possible to have "metal-to-metal" logging. That means logging from the split second the kernel boots until after the root files system have been unmounted and the system shut down. systemd and journald can do this because they become alive already in initramfs and then pivot to the rootfs, and then pivot back to initramfs after the rest of the system has shut down.

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's better than having hundreds of logs everywhere (I guess) but instead of a treefile entry system or anything that one can navigate with clicks or directory like commands we get the convoluted journald way. Using time strings is messy and hard to parse by eye, the only sane part is using unit name (assuming you know the offending unit your'e supposed to be looking for), oh and don't forget to prune the insane size of the log file allowed. It will eat your disk space for worthless logs from months ago and never clears itself (until it hits whatever 250 megs + or whatever it was default). Sorry journald sucks.

edit: before anyone points it out yes journald has parsing based on boot as well errors and whatnot... Sometimes these options just fall short for me.

[interested]

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's better than having hundreds of logs everywhere (I guess) but instead of a treefile entry system or anything that one can navigate with clicks or directory like commands we get the convoluted journald way.

Are you talking about some GUI? In that case journald's log structure is the only possible way to get any kind of useful distro agnostic GUI to logs, simply because it is both structured and indexed.

A tree-like structure sounds really limiting to me. I mean, how would you compare section of branches across the tree? An indexed log file is the only sane and flexible option.

Using time strings is messy and hard to parse by eye, the only sane part is using unit name (assuming you know the offending unit your'e supposed to be looking for)

"journalctl --since -5hours" or "journalctl --since -5h" isn't hard hard to parse, especially compared to a similar grep regex. You can also use "journalctl --since -7d --until -3d" to just show logs spanning from 7 days ago to until 3 days ago. You don't have to use full ISO dates.

How do would you grep a similar time span?

, oh and don't forget to prune the insane size of the log file allowed. It will eat your disk space for worthless logs from months ago and never clears itself (until it hits whatever 250 megs + or whatever it was default). Sorry journald sucks.

Come on, it is a simple one-line config option to determine the max size log files, you do exactly the same on Rsyslog. You can even specify a time based log rotation system on top of the max file size so you can automatically remove logs more than eg. 2 month old, even if the log files are way below max size.

edit: before anyone points it out yes journald has parsing based on boot as well errors and whatnot... Sometimes these options just fall short for me.

I don't think there is anything you can do with a text log file that you can't do with systemd's log files. If for nothing else you can just grep the output of journalctl. However, systemd's logfile can do things that aren't really possible to do with legacy syslog text files, including using monotonic timestamps, and boot-timestamps etc.

In my experience very few Linux users can actually use regular expressions with any confidence, so most regular Linux users just pipe the the text logs into "less" (or even open them in VI/nano/LibreOffice) without any attempt of filtering. And then they just browse the entire log-file. At best they make a simple grep.

The reason why you can find 10-20-30 different log files on syslog systems is exactly because it is hard to filter with regex and that few people actually master regex enough to do such basic filtering. This is also the reason why Rsyslog etc. tend to cut log files into several smaller logfiles when log rotating; it is simply too hard for many people to grep log files based on timesequences.

With systemd's "journalctl" there are finally a tool for really powerful filtering that even newbies can use. A single huge log file simply isn't a problem anymore, since it is trivial to only see whatever tiny subset that interest you.

[boltronics]

I tried running systemd on Jessie shortly after Jessie was released, on two different machines - one dist-upgraded from Wheezy (an old AMD E-350-based Sony laptop), and the other a fresh install (a new-ish Asus UX31A Ultrabook). The dist-upgraded one would occasionally freeze during shutdown and could not actually complete shutting down safely. The Asus sometimes seemed to die when resuming from a suspended state. In both cases, the problems were intermittent but reverting back to sysvinit-core solved the issue. Now I just remove systemd on new installations out of habit.

I know the Debian stable builds are probably very old and the issues could also relate to the way packaging was managed, but I would have expected them to be well tested. Since I pretty much use Debian everywhere, at least avoiding systemd hasn't been an issue.

What I would like to see is a focus on systemd improving stability. The the furious pace of development (and regular replacement of standard reliable components) does nothing to boost confidence.

[anda_skoa]

Also non-binary logs should be defaults, at least have both activated as sane default... ;-)

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

[interested]

What I would like to see is a focus on systemd improving stability. The the furious pace of development (and regular replacement of standard reliable components) does nothing to boost confidence.

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.

The core of systemd, the systemd-daemon, udev and journald, rarely gets changed much between releases, It is the new branches like OS container support and the networking stack that are changing a lot because of new features etc.

Besides that, the systemd project uses "Continious Integration (CI)" by using a "Jenkins" back end to ensure build quality, have an impressive array of self-test code to avoid regressions, and have "Coverty" scans for static code analysis. So you can basically always check out the code at the git repo and expect it to compile and work.

I can't really think of any Linux "standard component" besides SysVinit/Upstart that systemd actually replaces. systemd may offer alternative tools like a very basic sNTPv4 client for those with basic time needs, but it doesn't replace chrony or the NTP suite. journald _can_ be used as an alternative to syslog, but even then, it doesn't wholly replaces eg. Rsyslog since it isn't a log sink.

Yeah, I know, some of people are harping on the meme that "systemd eats up other components", but those people generally have zero experience with systemd, nor have they actually read systemd documentation, so they don't really know what they are talking about.