If you are gray beard with 20 years of Unix admin experience you are probably reading this with cherry red face with anger as IT DOES NOT WORK WITH MY SCRIPTS!!
But it does. systemd runs sysvinit scripts just fine.
Of course that's a minor issue compared to the one that systemd throws away log messages so there is nothing to find in the first place. It is a security nightmare. From dealing with Red Hat's (expensive) support, it sounds like they're also fed-up with systemd-created problems. We had a simple problem that should have taken thirty seconds to fix if systemd hadn't swallowed the stderr output and thrown away the syslog messages. Instead, I had two guys waste half a day on it, and it took Red Hat about three hours to figure it out.
And you managed to do that while leaving no visible trace of the bug report.
What about the loudmouths that created the systemd mess that throws away stderr, ignores higher priority syslog messages, and doesn't honor exit statuses?
On any system I've been able to try (CentOS 7, Debian Sid/Jessie) systemd does not throw away high priority syslog message and systemd correctly logs stderr to the journal.
Nobody has ever reported any of these strange behaviours as bugs (that I can find). If anyone does have a bug report that they could point me at, please do.
The complaint about "honoring exit codes" is simply user error. If the same startup task is run on sysvinit then the exit code is also ignored.
#!/bin/sh
case $1 in
start)
# launch broken_sysvinit
broken_sysvinit &
*)
#... esac
Systemd and libsystemd0 are not bad in itself, although there is some sloppy programming, but it's the depedency chain that is bad. A lot of things need systemd in the next release and it will soon be impossible to run debian without it.
No. One Debian package needs systemd -- gummiboot.
libsystemd0 does nothing if systemd is not pid1.
lkcl "actually worked hard and risked destroying [his] business by losing access to all data on a critical business laptop" for nothing. (And he seriously needs to learn to mount a scratch monkey).
You might have even gone the extra mile and subscribed to their mailing list where you would see actual progress being made.
I read the DNG archives. Can't exactly say I see a lot of "actual progress". But since the task they have taken on is more or less trivial (Luke seems to have done it on his own) I don't know what I'd expect to see.
This article isn't even about systemd. You can fairly easily use Debian without systemd. This is about libsystemd which is a small library for interfacing with systemd if it is installed. It doesn't depend on systemd so you can have it installed without having systemd itself installed.
lkcl (Luke) also goes about it the hard way -- why didn't he just make a dummy libsystemd0 that satisfies the dependencies but does nothing?
Of course even that is more work than is really needed -- as you point out libsystemd0 is pretty much a dummy package if systemd isn't installed.
There seems to be some strange fear of systemd cooties going on.
There are CONSTANT statements that if you do not use systemd you will not be able to use primary Linux distros in the future, because all software will supposedly be gobbled up by it as a dependency... To try and now make out like those dont exist is pretty silly.
There certainly are.
And they mostly come from people on the anti-systemd side.
Now indeed, for an init system, it's a bit more complicated to leave complete choice to the end user. Some specialist distro like Gentoo are able to offer you to switch between their default OpenRC and whatever you want. But the amount of work and risk of bugs in untested paths is rather high. So don't expect other distros to offer instant switch between systemd and upstart.
Which version of RHEL? I've tried all the things that are supposed to be a problem on CentOS 7, and they all work without a problem.
I've searched for bug reports or mailing list messages about these problema and can't find any.
The whole "systemd throws away log messages" idea is endlessly repeated by AC's who never reply to honest questions and http://slashdot.org/~greenwow who is some kind of insane troll (check his comment history if you don't beieve me)..
Tomorrow I'm having my best developer look at the source to systemd from https://github.com/systemd/systemd.git and I'm going to see if he can track down the problem.
Please ask your best developer to look at/etc/init.d/mongod and/etc/rc.d/init.d/functions.
I think you'll find that it's the mongod init script and the CentOS/RedHat svsvinit functions that are redirecting stderr, systemd is never getting the message.
Why? What will stop it working?
"Once Debian switches over to systemd" -- It already has for Jessie, and that command does work in Jessie.
Here's a little hint.
If you don't want systemd on your Debian servers then install sysvinit.
That was hard, wasn't it?
If you are gray beard with 20 years of Unix admin experience you are probably reading this with cherry red face with anger as IT DOES NOT WORK WITH MY SCRIPTS!!
But it does. systemd runs sysvinit scripts just fine.
Of course that's a minor issue compared to the one that systemd throws away log messages so there is nothing to find in the first place. It is a security nightmare. From dealing with Red Hat's (expensive) support, it sounds like they're also fed-up with systemd-created problems. We had a simple problem that should have taken thirty seconds to fix if systemd hadn't swallowed the stderr output and thrown away the syslog messages. Instead, I had two guys waste half a day on it, and it took Red Hat about three hours to figure it out.
And you managed to do that while leaving no visible trace of the bug report.
Interesting.
Except be tiny (seriously, systemd is over an order of magnitude larger than initd!), be portable to non-x86 systems
Uh, systemd runs on my phone. That's arm based, not x86.
systemD, constantly restarts all three services. filling up log files, and grinding the system to a halt.
If the user didn't want systemd to restart the services he shouldn't have told systemd to restart the services. It's not the default.
Slackware is a Linux distribution created by Patrick Volkerding in 1993
Nope, not 30 years.
The problem also doesn't exist in CentOS 7 (installed Friday).
And nobody seems to have reported it as a bug (which it clearly is).
On the laptop I'm posting from (Debian Sid):
On the CentOS 7 I set up to see if I could duplicate these problems:
There is obviously something wrong with your system. Have you reported a bug?
What about the loudmouths that created the systemd mess that throws away stderr, ignores higher priority syslog messages, and doesn't honor exit statuses?
On any system I've been able to try (CentOS 7, Debian Sid/Jessie) systemd does not throw away high priority syslog message and systemd correctly logs stderr to the journal.
Nobody has ever reported any of these strange behaviours as bugs (that I can find). If anyone does have a bug report that they could point me at, please do.
The complaint about "honoring exit codes" is simply user error. If the same startup task is run on sysvinit then the exit code is also ignored.
Systemd and libsystemd0 are not bad in itself, although there is some sloppy programming, but it's the depedency chain that is bad. A lot of things need systemd in the next release and it will soon be impossible to run debian without it.
No. One Debian package needs systemd -- gummiboot.
libsystemd0 does nothing if systemd is not pid1.
lkcl "actually worked hard and risked destroying [his] business by losing access to all data on a critical business laptop" for nothing. (And he seriously needs to learn to mount a scratch monkey).
You might have even gone the extra mile and subscribed to their mailing list where you would see actual progress being made.
I read the DNG archives. Can't exactly say I see a lot of "actual progress". But since the task they have taken on is more or less trivial (Luke seems to have done it on his own) I don't know what I'd expect to see.
It clearly is about systemd. Here's another hint: what is libsystemd about? That's right: systemd.
No. libsystemd0 is about interfacing to systemd if systemd is pid 1. If systemd is not pid 1 then libsystemd0 is a no-op.
Luke has put himself to a lot of hard work to remove a no-op.
This article isn't even about systemd. You can fairly easily use Debian without systemd. This is about libsystemd which is a small library for interfacing with systemd if it is installed. It doesn't depend on systemd so you can have it installed without having systemd itself installed.
lkcl (Luke) also goes about it the hard way -- why didn't he just make a dummy libsystemd0 that satisfies the dependencies but does nothing?
Of course even that is more work than is really needed -- as you point out libsystemd0 is pretty much a dummy package if systemd isn't installed.
There seems to be some strange fear of systemd cooties going on.
I'm pretty sure some of the "pro-systemd" stuff from AC's is actually trolls. (You know, the crazy "stderr is for losers" rubbish).
I bet a lot the the "Fuck Lennart" stuff is trolls too.
There are CONSTANT statements that if you do not use systemd you will not be able to use primary Linux distros in the future, because all software will supposedly be gobbled up by it as a dependency... To try and now make out like those dont exist is pretty silly.
There certainly are.
And they mostly come from people on the anti-systemd side.
I know the bug I filed was ignored, and I included good reproduction steps.
What bug was that? If you don't provide a link we can't see what the problem was.
I don't know why I bother posting this. I doubt the AC posted a bug report.
I bet if there is any answer it will be some paranoid claim about the bug being deleted from Bugzilla (which would mean hacking the database by hand).
Now indeed, for an init system, it's a bit more complicated to leave complete choice to the end user. Some specialist distro like Gentoo are able to offer you to switch between their default OpenRC and whatever you want.
But the amount of work and risk of bugs in untested paths is rather high. So don't expect other distros to offer instant switch between systemd and upstart.
What is Debian? Chopped liver?
Or...
http://crunchbang.org/forums/viewtopic.php?id=37871
Which version of RHEL? I've tried all the things that are supposed to be a problem on CentOS 7, and they all work without a problem.
I've searched for bug reports or mailing list messages about these problema and can't find any.
The whole "systemd throws away log messages" idea is endlessly repeated by AC's who never reply to honest questions and http://slashdot.org/~greenwow who is some kind of insane troll (check his comment history if you don't beieve me)..
the number.
what was the bug number.
One of the huge problems I have is that when others try the examples given they find:
systemd does log high priority messages
systemd does not ignore stderr
systemd does not ignore exit codes.
What was the bug#
This is fun -- a troll is pretending to be me.
It was me that made the [incorrect] suggestion about Type=forking.
Kids? I'm 55 years old you cretin.
Tomorrow I'm having my best developer look at the source to systemd from https://github.com/systemd/systemd.git and I'm going to see if he can track down the problem.
Please ask your best developer to look at /etc/init.d/mongod and /etc/rc.d/init.d/functions.
I think you'll find that it's the mongod init script and the CentOS/RedHat svsvinit functions that are redirecting stderr, systemd is never getting the message.