Once upon a time (in 1977 actualy) I learned to program (in Fortran on an ICL 1903T). When introduced to the concept of files I was intrigued by the idea of "binary" files: "cool" I thought, "I can hide things in there and nobody can read them, 'cos it's binary". Image my disgust when I found that a simple "cat" to the terminal recalled all my "hidden" text.
Yes, the contents of a binary file are a bunch of ones and zeroes, but so are the contents of a "text" file.
Pity. If you had meant sysvinit you could have just carried on using your init scripts, systemd runs init scripts for backwards compatibilty. I don't know what it does with upstart -- I've been able to avoid that steaming mess.
on't know who in their right mind thought it was okay to move critical system infrastructure systems (init, time, logging, etc) into the hands of an untested piece of software which clearly has very deep issues,
systemd complains that starting Apache fails and shows the service as stopped but the process actually starts and Apache is working just fine, systemd apparently just doesn't know it?
You were using the standard Debian sysvinit scripts before, and they worked, you're using the standard Debian apache2 service, it should just work. If it doesn't that's a bug. (Actualy, looking at it, apache2 is still using the init script -- there is no apache2.service).
In this case, the systemd detractor claims that systemd's log files become unreadable when they're corrupted. But the systemd supporter claims that the log files are readable with journalctl. Unfortunately, the supporter does not mention whether journalctl still works when the binary log file is corrupted. So, the systemd supporter may not be addressing the original concern of the detractor. Can somebody fill in the missing details?
The theory is:
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.
Bug report: Logs keep getting corrupted and cannot read them at all Rejected with reason: Delete the corrupted logs and move on SystemD - works well when it works, fails spectacularly when it fails.
It was closed "RESOLVED NOTABUG" because you don't need to fix journal corruptions -- journalctl can read the corrupt files and journald rotates the file it's writing if corruption is detected. Nobody suggested you delete the logs.
How the fuck do you do a meaningful Google search on "systemd complains that starting Apache fails and shows the service as stopped but the process actually starts and Apache is working just fine, systemd apparently just doesn't know it?"
TI-83 is a scam run on Schools, Students and Teachers. There are books written on how to do math on THIS calculator. They don't teach math, they teach math on this Calculator.
True.
Here in France a huge effort was made to break the TI monopoly, and now we are allowed to use one crappy, expensive Casio as an alternative to the crappy, expensive TI.
Meanwhile all kids have a phone with more compute power than a Cray-1.
Slashdot Mirror
Amazing. Science is now defined as "far left political hackery".
What would you suggest? For the US to completely stop using fossil fuels?
So, seriously, what do you suggest?
Negligable?
You think 16.16% of total CO2 emissions is "negligable"?
Uh, if you can pick something other than systemd, and you can, then systemd can be "swapped out".
So, by your criteria, systemd is a valid choice.
So don't ask it to do that, then.
You do know that the default is not to restart?
And that even if you do and for that then the restart attempts are rate-limited, just like with traditional init(1).
(Which is one of the biggest problems with the whole sysvinit horror -- it hardly uses the existing possibilities of init(1)).
Uh, that's "journalctl -f", no code needs ti be written.
Or just run rsyslogd.
Once upon a time (in 1977 actualy) I learned to program (in Fortran on an ICL 1903T). When introduced to the concept of files I was intrigued by the idea of "binary" files: "cool" I thought, "I can hide things in there and nobody can read them, 'cos it's binary". Image my disgust when I found that a simple "cat" to the terminal recalled all my "hidden" text.
Yes, the contents of a binary file are a bunch of ones and zeroes, but so are the contents of a "text" file.
Debian isn't a "good, complete server distro"?
You may be looking in the wrong place -- there is a lib for reading the journal, journalctl is just a simple client.
Hang on a second -- "chain these command line tools together", I've heard of that before -- don't we usually call that "the Unix way"?
I'd get right on working on that, except that the way journald has been designed makes that pretty hard.
Obviously another oversight by the systemd team.
Pity. If you had meant sysvinit you could have just carried on using your init scripts, systemd runs init scripts for backwards compatibilty. I don't know what it does with upstart -- I've been able to avoid that steaming mess.
on't know who in their right mind thought it was okay to move critical system infrastructure systems (init, time, logging, etc) into the hands of an untested piece of software which clearly has very deep issues,
Yes, upstart is pretty crappy, isn't it.
What's to configure?
You were using the standard Debian sysvinit scripts before, and they worked, you're using the standard Debian apache2 service, it should just work. If it doesn't that's a bug. (Actualy, looking at it, apache2 is still using the init script -- there is no apache2.service).
What does systemctl status apache2 show?
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
No, it's not a fact. If the log file is corrupt journald rotates it. It doesn't "delete it and throw it away".
In this case, the systemd detractor claims that systemd's log files become unreadable when they're corrupted . But the systemd supporter claims that the log files are readable with journalctl. Unfortunately, the supporter does not mention whether journalctl still works when the binary log file is corrupted . So, the systemd supporter may not be addressing the original concern of the detractor. Can somebody fill in the missing details?
The theory is:
https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3
Bug report: Logs keep getting corrupted and cannot read them at all
Rejected with reason: Delete the corrupted logs and move on
SystemD - works well when it works, fails spectacularly when it fails.
Except that isn't the bug report at all.
The real one was Bug 64116 - How does one fix journal corruptions?.
It was closed "RESOLVED NOTABUG" because you don't need to fix journal corruptions -- journalctl can read the corrupt files and journald rotates the file it's writing if corruption is detected. Nobody suggested you delete the logs.
How the fuck do you do a meaningful Google search on "systemd complains that starting Apache fails and shows the service as stopped but the process actually starts and Apache is working just fine, systemd apparently just doesn't know it?"
I don't know. I can't even find your bug report.
Racists would love that.
So they probably used paracetemol.
So you get hard when you swallow cocks?
TI-83 is a scam run on Schools, Students and Teachers. There are books written on how to do math on THIS calculator. They don't teach math, they teach math on this Calculator.
True.
Here in France a huge effort was made to break the TI monopoly, and now we are allowed to use one crappy, expensive Casio as an alternative to the crappy, expensive TI.
Meanwhile all kids have a phone with more compute power than a Cray-1.
Where does mint get it's KDE?
Or, maybe, try Debian?
Yipee! The lunatic troll is back!
Uh, you do know that systemd is largely backwards compatible with sysvinit, runs the same init.d files and so on.