Slashdot Mirror

Systemd will forward to syslogd if you want it to so you can still use your standard tools to view the logs if you want.

Liar

Really, if you are going to post your ideology-blinkered screeds, do your research first. This makes you look ridiculous.

This is an improvement and makes it possible to use standard monitoring tools. If one of those is a unique identifier, thats even handy.

The cursor is a unique ID for the entry I believe (and you can use it to request updated logs starting where you left off).

The boot ID changes on each boot, so you can associate log entries from the same boot cycle. The machine ID identifies the unique machine, and if you start 47 clones of the same container they will get different ones (I think that if you only run one instance of a container it will keep the same one). Systemd actually has a bunch of logic around hostnames that I haven't looked too closely at but it is aimed at things like clusters, containers, pxe-boots, and the like. It usually just does the "right thing" and it is trivial to just tell it to stick with one name.

What makes this even better is that it allows me to easily create a script to re-format the logs into something everything and everybody can easily read just as they used to.

Well, journalctl does that already. The default output for that one line is:
Oct 30 18:59:18 rich64 mythbackend[2361]: 2014-10-30 22:59:18.990471 C mythbackend version: tag: v0.27.4 [e4f65c8] www.mythtv.org

http://www.freedesktop.org/sof...

> It's not like the journal format is some state secret. It's documented
> and there are already several journal parsers to choose from.

Please explain http://lwn.net/Articles/468049...

> From the FAQ:

That LWN article is 3 years old and very outdated. The systemd developers was still developing the journald in those days, so they didn't want to freeze the API etc. it until they thought it was ready.

The journald log file format have been stable for a very long time now. Here is the developer info and documentation:
http://www.freedesktop.org/wik...

There are already independent journald readers and several log watch programs that query the journald directly.
Most tellingly; rsyslog can now read systemd journals directly. No need to forward syslog messages to it anymore if you use it as a log sink. It can read and write journald log files directly.

Here is a list over stable API's in systemd:
http://www.freedesktop.org/wik...

> It's not like the journal format is some state secret. It's documented
> and there are already several journal parsers to choose from.

Please explain http://lwn.net/Articles/468049...

> From the FAQ:

That LWN article is 3 years old and very outdated. The systemd developers was still developing the journald in those days, so they didn't want to freeze the API etc. it until they thought it was ready.

The journald log file format have been stable for a very long time now. Here is the developer info and documentation:
http://www.freedesktop.org/wik...

There are already independent journald readers and several log watch programs that query the journald directly.
Most tellingly; rsyslog can now read systemd journals directly. No need to forward syslog messages to it anymore if you use it as a log sink. It can read and write journald log files directly.

Here is a list over stable API's in systemd:
http://www.freedesktop.org/wik...

Wrong, services are considered "booted" when they are ready to process requests. For most services, the kernel kan be made to "buffer" request, so we don't care in which order they are started. For those rare cases when we do wan't to hold off a service, the unit-files can specify exactly what to wait for.

Oh, and by the way Sys-V init scripts never solved this. They depended on the daemons to solve this, which they virtually never did. Or sprinkle the init-scripts with strategically placed sleeps. This resulted in either the boot taking to long, or fail.

Try to do a 'grep sleep /etc/init.d/*' Every sleep you find is a potential boot failure.

You can read more about it in the systemd-documentation. You'll find it on the systemd homepage: http://www.freedesktop.org/wik...

You don't have any knowledge about how systemd restarts services. You haven't read the systemd documentation, but instead seem to rely on some random systemd haters wrong info about how systemd restarts services. Think about that.

systemd doesn't restart services unless told so. And it can be quite intelligent about restarts, distinguishing between several different ways the service was terminated and making conditionally restarts depending on the service's exit signal and combining it with rate limiters.

Try reading the "Restart=" section here to get a glimpse of the many options:
http://www.freedesktop.org/sof...

I like the fact that systemd's wholesale acceptance by all major Linux distros means much less fragmentation in both the way the Linux OS is managed and the easy that upstream projects are now able to support advanced features in a distro agnostic way.

I also like the fact that it exposes advanced kernel features like "cgroups" and "Capabilities" and make them easy to use; just add a keyword in a text config file and restart the service.

Add ProtectSystem=full in a service config file, and the service and all processes it makes can only "read" /usr and /etc enforced by capabilities. So even if the service is compromised, the hacker can't modify these directories, even if the hacker are able to execute code with root privileges.
http://www.freedesktop.org/sof...

Also "ProtectHome=" makes the service unable to read /home, so that no information stealing can take place.

Perhaps the best thing about these features and the many other systemd features like those, are that they can be enabled by either upstream or the distro makers, so that the end user doesn't have to anything in order to improve the system security. It will simply mean improved security and "defense-in-depth" as deafault on systemd distros.

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/

And apparently neither have you. Logs? Heh...one of those crucial things you need to figure out what fucked up on your PC or server, right?

You can't rely on Systemd to reliably provide those for you. A corruption in the DB will deny you an entire block of log entries. PERIOD.

It's also quite a large SPOF within the system. Something get boggled in just the right way, your system's wedged up...about like what happens with Windows.

Yes, we need something like you're talking to. You can't assure yourself with systemd that it WILL actually DO that because it's being designed and written by a group of people just like the bunch that did PulseAudio- and the same "designer" that came up with PulseAudio is presiding over this and applying the same level of care, concern, and skills (which is disturbing if you know anything about the history of PulseAudio...) to systemd.

Systemd was forced down my throat by Arch Linux. I didn't know anything about the controversy back then, so I just thought: "There's probably a good reason for this, let's get to work".

I read some docs and I liked the security features a lot! You can tighten services easily with a declarative syntax.

Here's a snippet from my ntpdate.service file. You don't need much systemd knowledge to guess at what each line does:

PrivateTmp=true
ReadOnlyDirectories=/
InaccessibleDirectories=/boot
InaccessibleDirectories=/root
InaccessibleDirectories=/etc/ssh
LimitNPROC=1
DeviceAllow=/dev/null rw
DeviceAllow=/dev/urandom r
User=nobody
Group=nobody
CapabilityBoundingSet=CAP_SYS_TIME
NoNewPrivileges=true

I ended up enjoying that work and tightened things so much that I hit a bug, which was resolved in just a few days: https://bugs.freedesktop.org/s...

But I still don't know how to configure the network properly T_T

so yeah in total i'd save 1 minute per year

Well boot times are not the only reason for systemd, so if they don't matter to you just consider them an added benefit then.

doesn't justify all the rest of the problems systemd gives me

Care to elaborate? Are you actually running into problems? I haven't encountered any yet so I would genuinely like to know what kind of issues to expect other than the fud that seems to get passed around about systemd.

i don't want my apache to be restarted if it's crashed i want to go and solve the problem, that is my job and by doing that systemd is actually not helping at all

Haven you even tried systemd? are you aware of the defaults in this matter? http://www.freedesktop.org/sof... The restart option is disabled by default unless your service description calls for it. If you have a problem with the option of having a service restart maybe you should rip init out of your system because it has a respawn option as well?

grep "^Restart" /usr/lib/systemd/system/httpd.service

Nothing. So as you can see at least in Red Hat apache will not restart itself. Other distros may change that, but either way it is an option and not mandatory in any way, so how is this a systemd problem to you? I for one like having the option to turn on auto restart even if I don't have a use for it, because maybe someday I will.

As I understand it:

1) If a daemon keeps failing, systemd just keeps restarting it. Admins prefer to be notified so that they can fix the root problem.

systemd doesn't restart crashed daemon unless configured to do. It is also really smart about restarting daemons with rate limiting and timers and what not. systemd can distinguish between manually stopped daemons, and those who have been SIGHUP'ed or those with a unclean exit code.

Look here under the "Restart=" option for more details:
http://www.freedesktop.org/sof...

2) If there is a problem with /etc/fstab, systemd will not allow the system to boot, and gives no reason for the failure. Admins prefer the system boot, and send a message. That way they have a running system, and can fix the problem.

Yes, systemd stops and goes into emergency mode if some hard disk in fstab doesn't show up. This is the right behavior. You can really mess up a system if you allow it to boot with missing mount points. SysVinit and similar init systems may allow booting of a broken system without any notification, but that is simply buggy behavior.

systemd does complain loudly about missing entries in fstab, a quick "journalctl -b -p err" would show that.

Mounting devices with "nofail" in fstab will allow systemd to continue to boot even if the devices are missing, since that implies the admin knows the system will be all right despite missing discs.

Get this Zip and open the MS Word doc inside, both with LibreOffice and MSO. Compare and report.

There's hundreds of other snags, either related to compatibility, missing functionality, usability or plain correctness that make LO too unreliable for certain purposes. Yes, the last one was eventually fixed, in version 4.2.

Get this Zip and open the MS Word doc inside, both with LibreOffice and MSO. Compare and report.

There's hundreds of other snags, either related to compatibility, missing functionality, usability or plain correctness that make LO too unreliable for certain purposes. Yes, the last one was eventually fixed, in version 4.2.

Get this Zip and open the MS Word doc inside, both with LibreOffice and MSO. Compare and report.

There's hundreds of other snags, either related to compatibility, missing functionality, usability or plain correctness that make LO too unreliable for certain purposes. Yes, the last one was eventually fixed, in version 4.2.

Get this Zip and open the MS Word doc inside, both with LibreOffice and MSO. Compare and report.

There's hundreds of other snags, either related to compatibility, missing functionality, usability or plain correctness that make LO too unreliable for certain purposes. Yes, the last one was eventually fixed, in version 4.2.

1) If a daemon keeps failing, systemd just keeps restarting it. Admins prefer to be notified so that they can fix the root problem.

Sure I can see that. Looks like systemd has that covered for you http://www.freedesktop.org/sof... Check the restart option

Takes one of no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted.

Looks like restarting the service automatically is not the default. As far as notifications I assume that has nothing to do with your init because with all the bickering about ntp being in systemd I assume no one wants a SMTP service in systemd as well. Journald should of course log any stderr/stdout from the process that failed.

2) If there is a problem with /etc/fstab, systemd will not allow the system to boot, and gives no reason for the failure. Admins prefer the system boot, and send a message. That way they have a running system, and can fix the problem.

Well I guess I have no comment on the reason for the failure. Presumably if your fstab issue wasn't a critical one you should be able to at least login on the console and a simple systemctl command will show which services have failed (fstab entries show up in that list) and you will see which fstab entry failed, and which services didn't start up as a result.

And you don't have to modify vi to edit their config files. That's one of the things that worries me - systemd needs modifications to all manner of other things..

Why do you think you need to modify vi to edit systemd config files? All systemd config files are just text files.

The basic lack of knowledge about systemd among those who dislike it is simply embarrassing for the Linux community; it is like people have forgot what a "man" page is, that sometimes you actually have to read up on stuff in order to understand it.

Seriously, try reading up on systemd: It is cool new Linux tech with lots of exceptionally fine features:
http://www.freedesktop.org/wik...

"As I understand it, it bundles a large number of services into a single process" - looks like you have only been reading slashdot comments rather than documentation at sites like http://www.freedesktop.org/wik... ?

a lot of it is down to configuration as to how many services are run by systemd. I'm using opensuse 13.1 and the only systemd services that appear to be running on my system are journald, logind and udevd.

As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon.

That is just wrong. Please read up upon the systemd project before having strong opinions on its design. Don't rely on people foaming at their mouth with rage for information on how systemd actually works. In the future, all major Linux distros will use systemd, so it is prudent to actually read and understand it. This is a good starting point:
http://www.freedesktop.org/wik...

What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. (...)

What's even more surprising is that someone with some sense hasn't done exactly that:

First, systemd is of course split up in multiple processes each running with their own PID.

Second, in those case where there is e.g. kernel feature integration, systemd follows the most logical way to design a system. The reason why you don't see a systemd re-implementation done in hundreds of little independent modules, is that is a bad design with a huge overhead, when a module needs to talk with 3 other modules, that again needs to talk to 3 other modules every time a daemon request whether it eg. have more cgroup slices available.

So systemd is designed the way it is because it is meant to solve real world problems better than anything else out there, not be a show case of some dogmatic design philosophy.

365 days without a security patch. Does uptime make you more money than protecting your customer data?

FFS. What makes you think a server needs to reboot for patches? Your extensive Windows administration experience?

UNIX/Linux servers need to reboot for a kernel patch. Very rarely (maybe never?) should a system need to reboot for anything other than a kernel patch. The number of recent packages aside from the kernel that require this is growing and a stunningly distrubing trend (mostly related to systemd).

Now, when must a kernel patch be applied? When a security patch is applied that affects something exploitable from one of your publicly accessible services.

An example, bind running inside a chroot jail and an exploit that requires access to a file or handle outside the jail != kernel patch and reboot.

A kernel patch for a local privilege escalation exploitable as www user with apache listening publicly = patch the kernel and reboot.

See the difference? There have been probably hundreds of local privesc exploits since I started working with Linux that just did not apply, and we very safely ignored the patch. When one matters, it is applied and we reboot. I've had specialty boxes that went multiple years without the need to reboot. We are on two commercial grids with battery and generator power available. I reboot when necessary, but have 6 9's of uptime (discounting planned outages) and the reason it's only 6 is hardware failure. It's 5 9's *INCLUDING* the planned outages across about 150 servers.

Now, I actually support systemd. But a few things seriously turn me off about it.

1) It is almost viral in what it demands, incorporates, and forces to be installed.
2) It doesn't appear to be well planned, documented, or tested.
3) There's a lot of scary shit in the bugtracker that is still unresolved or even assigned (some more than a year old).

Now, I accept that systemd and the 1000 required subpackages (udev, dbus, avahi, the QRcode enabled http server, journactl, etc.) are under development and alpha software. I don't understand why my production servers are supposed to migrate there now. Fix the broken crap and we'll talk, but again - my fucking notebook stopped resolving without a reboot after a non-kernel patch. Fuck that in production. Message clear?

Most of the complaints against journald are unfounded. it can be configured to spit out text logs to rsyslog at he same time so all the scripts relying on text logs will still work as normal

http://www.freedesktop.org/sof... - here's the option from the link.

ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=
Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is enabled but no syslog daemon is running, the respective option has no effect. By default, only forwarding wall is enabled. These settings may be overridden at boot time with the kernel command line options "systemd.journald.forward_to_syslog=", "systemd.journald.forward_to_kmsg=", "systemd.journald.forward_to_console=" and "systemd.journald.forward_to_wall=". When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below.

The distributions should be wary of putting all their eggs in the freedesktop.org basket. Not all systems are desktops, and they shouldn't rely on desktop features at the expense of their own roles.

Dude, freedesktop.org is just a code repo like github, so they also host e.g. an OpenCL compiler. Sure, the site is also used for inter distro discussions and informal work groups, but implying that systemd is a desktop thing only since it hosted on freedesktop.org is just laughable.

When you got the time, please read up on the systemd project to see what it is all about:
This is an excellent starting point: http://www.freedesktop.org/wik...

I can use ls without having to use info, but I can't use systemd-networkd without using systemd. Conversely, there is no logging system other than systemd-journald that works with systemd. ... In other words, each individual program that makes up the "systemd brand" must all be installed and running or else none of them work.

Having looked over the source for systemd-networkd, I see no particular reason why it couldn't be used outside of systemd provided dbus was up and running. I'll grant that systemd depends on systemd-journald, or at least something implementing the same interface. That's one of the few "hard" dependencies; most of the remaining services (like networkd, hostnamed, localed, and timedated) are optional. I assume you were exaggerating, but just to be clear: it is not necessary to run all of the programs which make up the systemd "brand". With the exception of a few core dependencies like journald, you are free to pick the components you wish to run.

I was using XTerms (the real thing not emulators) starting in 1988, and was using as my primary computer by late 1992. I know what XTerms are. The LTSP was just a way in the early 1990s to get Linux boxes, primarily cheap old PCs that couldn't run Windows 3.1 / 95 anymore to run XTerms. I've been familiar with that project for two decades. I'm not failing to understand you. But you were being a bit unclear about what you wanted before.

Check out the Linux Terminal Server Project ltsp.org. Can something like that be implemented in Wayland?

If by that you mean a dumb system giving you near real time performance, no it can't. That's what network transparency means, and that's what Wayland doesn't support.

X-terminal can be a truly cut down device with little more than a kernel and X. Boot time is super fast because all you are loading is a kernel plus X.

It doesn't even really need anything as complex as a Windows kernel. You can cut it way below that. X11 ran on DOS. You can easily create a dumb X-term which would be done booting before you could move your arm from the power switch to the keyboard. The NCR used an 88100 @ 20MHz and could boot in under 5 seconds.

By X11 having that do you mean PulseAudio?

There are lots of solutions. The X11 protocol is extendable one extensions that's been implemented multiple times is sound. Anyway to setup Pulse Audio: http://www.freedesktop.org/wik...

I want a terminal that is basically a dedicated second head to the main machine.

That Wayland doesn't do. You have your choice: smart networking or application and video card on the same bus. Someone might figure out some way to get that to work by running virtual machines on either side and hacking together a virtual bus that is running over the network but what you want is what X11 is optimized for. Keep running X11 as long as you can and see where the world is in 2030 or so.

Huh, that IS interesting! Maybe it's about time that they update their own website then.

http://wayland.freedesktop.org...

Is Wayland network transparent / does it support remote rendering?

No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.

This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model. Which is a feature when you think about it; layering X.org on top of Wayland has very little overhead, but the other types of remote rendering servers no longer requires X.org, and experimenting with new protocols is easier.

It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server and run an application back on your desktop. Building the forwarding into the desktop compositor could let you export or share a window on the fly with a remote wayland compositor, for example, a friend's desktop.

So he hacked X to make it work in wayland - among many other things he does with X. This does not imply he gave up working on X in favour of Wayland. A better indications about doing the development activity and who is doing what are the mailing lists:

http://lists.x.org/archives/xo...
http://lists.freedesktop.org/a...

The idea that all/most X hackers gave up on X and are now working on Wayland as its successor is far from the truth.

Also - maybe I gave a false impression - but I am not opposed to Wayland. It is rather nicely designed and well written piece of software. What makes me angry is the idea that it is declared the future of Linux we all have to switch to when it clearly also has some downside, e.g. broken compatibility and network transparency. But those things are not openly discussed, instead they are "adressed" by FUD such as "network transparency is already broken". Oh, you are using it? You must be a lier because Daniel Stone told us it is already broken.

Look at the journald.conf man file: http://www.freedesktop.org/software/systemd/man/journald.conf.html.

Set ForwardToSyslog=true in /etc/systemd/journald.conf under the [Journal] section. Make sure you have a syslog daemon running. Done.

As a user I want my remote display. I've been to the Wayland website. I've read the FAQ. I don't see ANYTHING that gives me the idea that I will be able to keep using remote login sessions when Wayland has replaced X.

Well I think you should take that to David Fort. Kristian Høgsberg made him responsible (in May) for integrating an RDP solution directly into the system: http://lists.freedesktop.org/a...

More detailed explanations: "X11 is network capable", Daniel Stone on The Real Story Behind Wayland and X (slides, on page 74: "SHM and DRI2 don't work over the network").

Honestly, if you've been a lurker of this community for the last 10 years, you've seen Daniel Stone and Keith Packard as two of the most usual faces in conferences, mailing lists, etc. about X. If they both think that moving to Wayland is wise, I'm in.

is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.

The systemd developer have explained, and explained why they did what they did; they have made stable interfaces;
http://www.freedesktop.org/wik...

They have explained what interfaces that can easily be made on non-systemd distros or even other OS's:
http://www.freedesktop.org/wik...

There are systemd libraries and what not, and lots of documentation.

That systemd is a Linux only thing, is because it uses kernel features that are only available to Linux like cgroups, "namespaces" and "kernel capabilities" and soon, kdbus. If eg. Hurd or OpenBSD or Mac OSX implemented such features, systemd could be ported. Of course, *BSD would never allow LGPL licensed software to become a critical part of their core OS, so the point is rather moot though.

Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.

The systemd developer have explained, and explained why they did what they did; they have made stable interfaces;
http://www.freedesktop.org/wik...

They have explained what interfaces that can easily be made on non-systemd distros or even other OS's:
http://www.freedesktop.org/wik...

There are systemd libraries and what not, and lots of documentation.

That systemd is a Linux only thing, is because it uses kernel features that are only available to Linux like cgroups, "namespaces" and "kernel capabilities" and soon, kdbus. If eg. Hurd or OpenBSD or Mac OSX implemented such features, systemd could be ported. Of course, *BSD would never allow LGPL licensed software to become a critical part of their core OS, so the point is rather moot though.

Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

that an OS architecture that dated from the 1970's was actually totally elite

Well, humans needed to breathe in 1970s, and they need to breathe now. So just because something is from the 1970s clearly cannot be held against that. In fact, we have 44 years (ignoring pre-1970 of course) of evidence that stopping to breathe is a bad idea, and 44 years of evidence about which parts of UNIX philosophy are applicable when and why.

Now your long post didn't address any single problem with the UNIX philosophy. Apple clearly showed that integration for desktop users is not impossible with UNIX, and UNIX philosophy is not even against a user exposed integrated interface.

I will be the first to admit that at times UNIX philosophy is not applicable - e.g. ZFS combining LVM, raid and filesystem in one single monolithic feature is against the UNIX philosophy. But it solves many real problems, without introducing new ones. And it wasn't considered stable for just under a decade after release.

Systemd was considered "stable" within an year or 2. The parts where it breaks UNIX philosophy are clearly where it is NOT good to break it, with a nice bug to show for it.

About as well as you can remove the preprocessor from gcc

And with respect to preprocessor , no one calls gcc non-monolithic.

In the case of journald you can operate it in non-persistent mode, so that it doesn't actually write any logs to disk.

But not giving direct access to syslog, only forwarding to syslog. So with respect to log system - it is monolithic. Say an operating system where you could have vi (or other editor) but only after emacs forwards editing commands to vi. That operating system would be called monolithic with respect to text editors.

Kde is modular, but good luck deleting kdelibs.

KDE is modular in many respects, but not with respect to not needing kdelibs. It is modular in being able to replace window manager, network-manager. At code level it might be modular in replacing some libraries, UI widgets, I am not too sure.

Systemd is NOT modular where it matters. If journald could be completely replaced with syslogd, without the forwarding business, it could have been called modular with respect to log system. Why should one lose the ability to view non-corrupted text logs from bootloader just to get an init replacement?

https://bugs.freedesktop.org/s...

Indeed, I misremembered that. They don't say delete, they say the file gets rotated out immediately. And this bug report is famously linked as a demonstration of why systemd is hated for its developer attitude to the point that Lennart repsonded to it (today oddly enough). Corrupted files are not considered a bug and not getting fixed.

One of the defects constantly levelled against systemd is its propensity to corrupt its own system logs, and how the official response to this defect is to ignore it. The uselessd page has a link to the bug report in question, which was reported in May 2013 and, over a year later closed and marked NOTABUG. However, it seems Mr. Poettering is getting annoyed by people using his own bug reports against him, and added a comment to the bug report today purporting to clarify his position.

Unfortunately, his "clarifications" serve only to reinforce my suspicion that systemd is a thing to be avoided. To wit:

Since this bugyilla [sic] report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:

Well, yeah, corrupt logs would be regarded by many as a major bug...

...Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.

Okay, so freeze the corrupted data set so things don't get worse, and start a new data set. A reasonable defensive practice. You still haven't addressed how the corruption happened, or how to fix it.

Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.

Okay, so journalctl tries to be robust, assumes the journal data might be crap, and works around it. So we can assume journalctl is probably pretty solid and won't make things worse.

Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!

....Uhhhhh-huh. So, yeah, newer tools will do a better job of working around the corruption, and we'll be able to recover more data, assuming we kept known-corrupt logs around. But what I still don't understand is WHY THE LOGS ARE CORRUPT. And why aren't there log diagnostic and analysis tools? If you already know your logs can turn to crap, surely there are structure analysis tools around that let you pick through the debris and recover data that your automated heuristics can't.

And why do I get the feeling that implied in the above is, "You don't need to know the log structure or how to repair it. We'll write the tools for that. We'll release better tools when we get around to it?"

File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.

....AAAAnd you lost me. Seriously, this is your defense: "Filesystems are more important than system logs, so they have to try harder?" I find this insinuation... surpr

Why do you like systemD? What's so great about it?

I could probably write pages on how great systemd is, but the bottom line is, that systemd is "Linux-done-right!" in all aspects it covers:
It is by far the most advanced, feature rich init-system available for Linux (and probably Unix too).

There are several reasons that make systemd a great project;
Its developers (Poettering et al) have really studied all parts extremely well before they started coding, so all the systemd functionality is really well thought out, and implemented in a superb way; everything is an improvement, often by a huge distance. They have dealt with all the hard problems like backwards compatibility, no flag day, service dependencies etc, by solving them in the most correct manner instead of just patching things up, so systemd pc's have a fast boot, not because systemd is optimized for speed, but because by doing system and service initialization in the most predictable and correct way, leads to a boot speedups as a side effect.

Ubuntu's Upstart was an important, well coded, pioneering effort for improving Linux init systems and a serious improvement over SysVinit, but it also demonstrated, that by staying too close to traditional init systems, you didn't get rid of their inherit problems.

Just the logging alone is worth everything; it provides superb and powerful log filter capabilities that enhances the standard Linux text tools like "grep", but since it is structured, indexed and have a programmatic API, it will also mean that GUI developer now can make a functional GUI for viewing logs on Linux. So there is great stuff for the hardcore sysadmin, and the new Linux user at the same time.

systemd makes using advanced kernel feature like cgroup a breeze; no need to read advanced tutorials or cooking up bash scripts, just ad a single keyword like "CPUShares=20%" in the service config file, and systemd will use cgroup to ensure that that process will never get more than 20% CPU time on one CPU. It is so easy, and no coding required.

I could go on, but I recommend that you study systemd yourself:
http://www.freedesktop.org/wik...
Lots of great documentation there, that will make you think; this is great stuff!

Exactly. You hit the nail on its head.

Looking for system logs of PAST events, and expecting them to be not corrupted? Can someone be less forward looking than that? Talk about obsession with the past. Forward looking guys need no logs of the past. Next feature in systemd is a log file from future.

So, this is a stupid reason in a mission-critical piece of software?

Mods, you upticked this as "insightful"- it's only "insightful" if you're taking drags on a crack pipe.

He also won't fix a critical bug, and here's a dozen more reasons to hate this crapware.
Lennart, pack your things and go, or start playing nice finally!

I think you're out of luck. According to the OpenMandriva wiki, they have switched to systemd and built it into their initramfs. Furthermore, "Due to the adoption of systemd the use of a separate /usr partition is no longer possible." The explanation for why this is the case is at freedesktop.org.

It's all irrelevant anyway, AMDs Open Source support sucks, and hasn't been stable. Nouveau's Open Source support is actually better. Go look at the Mesa Matrix http://www.mesamatrix.net/ Nouveau supports more OpenGL features on their open source cards than AMD does. The only thing that's been holding the Nouveau cards back has been power management and even that's not a huge issue, http://nouveau.freedesktop.org... notice that power management is almost complete on all current gen cards going right back to the Geforce 3/4 series! (admittedly Geforce 3/4 has stalled in part, but the other cards are all close to completion) So the legacy support level is fantastic as is the current card support. Nouveau has been also very rapid at making all features available to the newest generation of cards very quickly. I expect that by this time next year, they will have working OpenGL 4.2-4.3 support, and power management will be completed. Whether Nvidia has posted meaningful contributions to the project or not is almost irrelevant. The reality is that open source Nvidia is coming and it's going to be great.

"But when the systemd developers started trying to embrace, extend and extinguish other things like syslog, core dumps, etc." - how are they doing that? you still get all those with systemd - http://www.freedesktop.org/sof...

or am i missing something

Dammit, I was going to go with "Popplers"

Already taken.

None of which requires that logging be moved into PID 1. Instead, all you need is the ability to support a new log format in some syslogd. Unless you were some kind of moron, you'd design the new program to be able to log to both text and binary formats at the same time so that you could enjoy the benefits of both formats. Systemd may or may not do this, I don't care; there's no reason whatsoever why logging should not be a separate daemon.

Logging isn't done by or in PID1. It is done by the "journald" daemon that have its own pid. I must say, that whoever telling you about how systemd is designed and works, doesn't have a clue what they are talking about. I strongly suggest you check out the systemd homepage for some basic information about systemd.
http://www.freedesktop.org/wik...

People are hard to satisfy: some complain that systemd replaces daemons, and now you complain about it _doesn't_ replace syslog for writing text logs?

People who wants simple text-logs can still use rsyslog or whatever they have always used, and have "journald" forward all the messages to it. That way rsyslog can gain some of the systemd benefits like early boot logging, though not them all (rich meta data like monotonic stamps and whatnot). All in all you would be better off than simply using SysVinit and pure rsyslog.

Even without syslog, it is trivial to convert systemd's journal to text. You can even export it as JSON to preserve the rich meta data.

I really think the systemd developers did their homework very well with the design of the logging system. The more I use it, the more I like it. There is no going back for me to plain text logs.

Your claims that systemD is well engineered are a little eye-raising. We're talking about a replacement for the init system here, and you say the main feature is logind. That's not really part of what I expect Init to do......

logind isn't a feature with "systemd" (the daemon), but with systemd (the project). "logind" is a consumer of the systemd-daemon's internal API however. That means you can use cgroups and other kernel and systemd features in user sessions. This is how eg. secure root-less X.org is possible with systemd.

I think many peoples idea what init is, have been clouded by the fact that traditional Linux init systems were so primitive. Certified Unix'en like Solaris and Mac OSX have abandoned crude Linux like init systems years ago.

Booting and initialization of a system is quite complex on modern OS's, so doing it by modules that aren't coordinated and aren't developed with the other modules in mind, really limits what the OS can do. Having modules like systemd's, that are designed to talk to each other, all other processes and the kernel, and is developed in a coherent manner, really can remove some old limits on how Linux works. Basic things like conferring "namespaces" and "capabilities" from the kernel to a service, just by adding a simple keyword in the service config file, shows the potential. But multi-seat computing, stateless booting and "zero config" boots are either realized already or being worked upon. With kdbus in the kernel, secure OS containers from basically unmodified Linux distros, will become a reality.

I also think it is good, that systemd now will reduce Linux fragmentation at some level at least, and freeing distro maintainers and developers from a lot of non-fun work like maintaining and debugging init-scripts, while making cross distro collaboration on e.g. extra hardened "Unit" files (service configs) possible.

Here is a youtube video where Lennart Poettering talks about why systemd goes beyond a simple init system:
https://www.youtube.com/watch?...

In any case, in a few months, I'll have time to read the systemD source code, and I will have a better idea if it's well designed or not.

I strongly recommend reading as many relevant sections from this site:
http://www.freedesktop.org/wik...

There are also some design documents (like this old one about the journal)
https://docs.google.com/docume...

And of course more youtube talks from Fosdem etc:
https://www.youtube.com/watch?...

I've been a sysadmin for 20 years, and I've seen systems break in lots of interesting ways. What I want is a log mechanism which is as simple as possible so that it as least has a chance of giving me the info I need even if the rest of the system is in the process of going to hell.

What I don't want is an unnecessarily (you aren't even able to explain the advantages, actually some of your "advantages" are disadvantages like the corruption detection) complex system which will take ages to debug, IF it will ever be - most software is already too complex and too fast moving to be ever debugged sufficiently. It violates the KISS principle. And the advantage of Linux over Windows used to be the KISS principle...

systemd's logging facilities are superior to old syslog in several ways. Fx. systemd and journald lives in initramfs while the system is booting, so it can collect logging info from before the root fs is even mounted. Since systemd actually have knowledge about mount points and files systems, it can also delay to the very last moment the things needed for journald to write to the log.

There is also kernel guarantee that the daemons/pid's/programs that appear in the log are the real ones since systemd have total control and supervision of all processes. So if "lp0: printer on fire" appears in the log, you will know whether it is a prank or a real message.

The structure and index makes it possible to store lots of interesting meta-data, like monotonic time-stamps, GUI, PID, command line, marks from where every boot started and ended ("journalctl -b -p err" shows all loglevel "error" messages generated last boot only). Using monotonic timestamps to compare two boot sequences on perhaps two similar machines, is quite interesting and very easy to do.

It also allows for multi-language log support, supplementary help files that can explain what the error message means, suggest how to solve the problem, etc.

Here is a list of fields in the journal. Because of the index, the journal have real time knowledge about what is written in the fields, so there is tab completion and extremely powerful sorting available:
http://www.freedesktop.org/sof...

If you care about logging with systemd, take a look a the original design document behind journal
https://docs.google.com/docume...
Notice how simplicity is design goal number 1.

If you intend to remain (a paid) Linux sysadmin in the future now where all major distro are starting to convert to systemd, you should really study systemd's journal.
It is much easier to "get" the power of a indexed and structured log file by trying it, than describing it. Fedora 20/CentOS 7 are reasonable choices to learn it on.

check out systemd's "nspawn" too: OS containers really are the future.

1) You can still use rsyslog (or syslog-ng or ...) with journald if you want and I believe all the major distros still do: http://blog.gerhards.net/2013/...
2) journald supports "Forward Secure Sealing" to prevent tampering of its logs: http://lwn.net/Articles/512895... See the "Seal" option in journald.conf: http://www.freedesktop.org/sof...

One of them, logind Manage user sessions with all the tools used with server processes. I for one welcome this.