Slashdot Mirror
Linux Mint Will Continue To Provide Both Systemd and Upstart
jones_supa writes: After Debian adopted systemd, many other Linux distributions based on that operating system made the switch as well. Ubuntu has already rolled out systemd in 15.04, but Linux Mint is providing dual options for users. The Ubuntu transition was surprisingly painless, and no one really put up a fight, but the Linux Mint team chose the middle ground. The Mint developers consider that the project needs to still wait for systemd to become more stable and mature, before it will be the default and only option.
Sounds like Apache is forking and running as a daemon, and you haven't told systemd to expect that behaviour.
Take note modern shitposters. This is what a good troll looks like.
If everyone who wants to derail a discussion would put in as much effort as this the Internet would be saved.
It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html It's a fact that systemd will only sometimes recover any part of its bullshit binary logs, and only any part after any error. So if journald truncates a file because it shits itself, which it has been known to do, then you lose the whole log.
Moderators, you might want to familiarize yourself with the festering pile of shit which is Lennart Poettering, as well as the pile of crap which is systemd, before you moderate any systemd discussions. Because you clearly have no idea what you're doing.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
dconf uses binary configuration files. As I've said many times, while systemd catches a lot of flak for messing with long standing conventions, it is far from alone in modifying the experience (dbus, dconf, systemd, udev all do interesting things, each component bringing interesting capability with varying degrees of drawbacks).
I think udev generally does a great job of delivering useful capability with minimal downside. Then dconf (most people don't even realize the binary dconf files exist, even when they poke dconf extensively). dbus starts going off the rails (many things that once were simple enough to explore/grep around for are now only possible through internet search of obscure dbus-send commands). systemd I actually consider less bad than having to do more and more dbus stuff.
XML is like violence. If it doesn't solve the problem, use more.
The mint team is doing a right thing. I'm writing this from a CentOS 7 machine that I'm using to test systemd. One day, when the XFS partition was corrupted I realized that the system can't do usual self check and self repair. Why? Because systemd.fsck module runs fsck.xfs which according to the manual "simply exits with a zero exit status". You can boot with init=/bin/bash, but can't correct system scripts to change the behavior, everything is in binaries now.
Ubuntu 14.04 uses Upstart.
The reason so many distros have adopted systemd is because it fills a need: it does something useful for them. This topic has been exposited. In the second link, note how much shorter the unit file is than the init script. That is why distro maintainers have adopted systemd, because they have to write less code.
So Lennart found something people needed, and built it. That's why people adopted it. You don't have to like systemd, but you should at least understand why it's been adopted.
"First they came for the slanderers and i said nothing."
IIRC these "binary" logs you speak of are simply text files with indexing information attached. They're not encrypted or compressed, you can, at worst, use the "strings" command to pull the information, and if you're doing raw sector dumps from a hard drive then you'll be able to read them there too.
Of course, if the log files are zero'd out, like the bug report you quote, then it doesn't matter whether they're "binary" or text, you're screwed. That has nothing to do with systemd.
You are not alone. This is not normal. None of this is normal.
SysD's binary logs have another, serious flaw: they are not designed to be sent over a network. This has been an intrinsic part of syslog for a looong time.
There are a few tools to send journald logs remotely, but they rely on tailing the binary log, then reformatting it and transmitting it over HTTPS to another tool on the destination system.
I found a feature request for journald/sysd/whatever to enable network logging, and the solution they are adding is to... tail the binary logs with basically the same tools.
Putting the disk in the middle and depending on file tailing is such a bad solution. Many things can cause this to fail; it's a total kludge.
I discovered this when investigating how to send journald logs to Splunk. The solution there is to... tail the binary logs with journald to a text file and have Splunk monitor the text file.
Now, this is not a fatal flaw. Journald could (I assume) be enhanced to natively send logs over a network. But, this shows that systemd is not enterprise-grade or production-grade, and was not designed with that kind of reliability in mind.