"shit" does happen. What is interesting about the whole systemd thing is that there are a class of people, all posting AC, why lie about what happens.
I'd love to know why. I can understand that people don't like some software, but why would they flat out lie about what that software does?
How do I know these claims are lies? Because they are all posted AC, because nobody has ever claimed to have reported these defective behaviours as bugs, because I can't reproduce them even when using exactly the same environments and commands as the claimant.
I did try it, and reproduced the his results on Fedora 21.
That's very interesting, you're the first non-ac to report this.
Care to show me exactly what you did?
If you took the recipe given by the ac:
It is trivial to reproduce this serious problem with systemd. Pick any script in/usr/lib/systemd/*.service:
# append --broken to ExecStart line vi/usr/lib/systemd/system/named.service systemctl stop named systemctl start named
Then maybe you missed the fact that systemd doesn't re-read unit files for existing services, you have to do a "systemctl reload" after stopping the service and before restarting it. (You should have got a message warning you of this, but many people seem to misunderstand the message).
I can find the bug in an overly complex init script, yes. If they had a simple systemd unit there would be no bug to find.
(I found the bug in the init script in 10 minutes, the GP claims it took his crew of elite developers and Redhat support a whole day. Either he is an idiot or he is lying -- I suspect both).
Now, personally, I'm willing to try it out on my laptop for awhile, and maybe, just maybe, I will consider deploying this in servers, in like 6 months after daily use by myself and my alternate. Otherwise we'll keep using 14.10 for now.
Another moderation that demonstrates the insanity of the anti-systemd trolls.
Even if you hate systemd for valid reasons, what kind of moron is going to mod up a comment that is a straight out lie just because it is anti-systemd?
I think this is the same problem that stumped Red Hat's support for a while when we first upgraded to 7. MongoDB refuses to start after an unclean shutdown. It detects that by placing its PID in a file named mongod.lock on start and then clearing the PID on clean shutdown. When you start MongoDB with the lock file in place, it gives you an immediate and clear error message on stderr that this is the problem. When starting with systemd, because it swallows stderr and syslog messages, there is no indication whatsoever what is causing it to not start. There is nothing in the journal or the console.
Slashdot Mirror
"shit" does happen. What is interesting about the whole systemd thing is that there are a class of people, all posting AC, why lie about what happens.
I'd love to know why. I can understand that people don't like some software, but why would they flat out lie about what that software does?
How do I know these claims are lies? Because they are all posted AC, because nobody has ever claimed to have reported these defective behaviours as bugs, because I can't reproduce them even when using exactly the same environments and commands as the claimant.
I did try it, and reproduced the his results on Fedora 21.
That's very interesting, you're the first non-ac to report this.
Care to show me exactly what you did?
If you took the recipe given by the ac:
It is trivial to reproduce this serious problem with systemd. Pick any script in /usr/lib/systemd/*.service:
Then maybe you missed the fact that systemd doesn't re-read unit files for existing services, you have to do a "systemctl reload" after stopping the service and before restarting it. (You should have got a message warning you of this, but many people seem to misunderstand the message).
crickets
Which of:
Bdale Garbee
Russ Allbery
Steve Langasek
Don Armstrong
Keith Packard
Colin Watson
Ian Jackson
Andreas Barth
Is an "ex-RH element"?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729
Bug report:
* What led up to the situation?
I tried to talk to a troll
* What exactly did you do (or not do) that was effective (or
ineffective)?
I asked a question, hoping for an informative answer
* What was the outcome of this action?
The troll gibbered at me
* What outcome did you expect instead?
The same thing.
Oh, drat, it's not a bug, the troll is working as expected.
I asked for the bug report number, not the resolution.
Nobody will provide one because no such bug has never been opened.
Which tells you all you need to know about the reality of these wierd claims.
I can find the bug in an overly complex init script, yes. If they had a simple systemd unit there would be no bug to find.
(I found the bug in the init script in 10 minutes, the GP claims it took his crew of elite developers and Redhat support a whole day. Either he is an idiot or he is lying -- I suspect both).
Comment needs funny+insightful, slashidiots give troll...
Hundreds of DOS ini files, having to compile things instead of just modding a script,
"having to compile things"? Like what for example?
Now, personally, I'm willing to try it out on my laptop for awhile, and maybe, just maybe, I will consider deploying this in servers, in like 6 months after daily use by myself and my alternate. Otherwise we'll keep using 14.10 for now.
You use Ubuntu on servers?
Neither. Why would you imagine it would?
Why not just use Debian?
So you suffered through Unity, but systemd is what turns you away? Huh.
No, he suffered through upstart and systemd is what turns him away?
Maybe mr smug, you can tell me where on earth the ACPI events from the sleep key are going and why SystemD refuses to pass them on anywhere sensible.
Works for me. Maybe you could describe your environment in more detail?
Another moderation that demonstrates the insanity of the anti-systemd trolls.
Even if you hate systemd for valid reasons, what kind of moron is going to mod up a comment that is a straight out lie just because it is anti-systemd?
Well, that was a failure then, in comparison to sysvinit systemd is limpid.
I think this is the same problem that stumped Red Hat's support for a while when we first upgraded to 7. MongoDB refuses to start after an unclean shutdown. It detects that by placing its PID in a file named mongod.lock on start and then clearing the PID on clean shutdown. When you start MongoDB with the lock file in place, it gives you an immediate and clear error message on stderr that this is the problem. When starting with systemd, because it swallows stderr and syslog messages, there is no indication whatsoever what is causing it to not start. There is nothing in the journal or the console.
And, as I've already pointed out: http://slashdot.org/comments.pl?sid=6953777&cid=49050025
This is a bug in the mongodb init script, it directs stderr to /dev/null.
If the mongodb init script sends stderr to /dev/null how can systemd log it to the journal?
was of course deleted and ignored:
And that is the even bigger problem with systemd.
No, it's a big problem with your insanity.
This bug, since it doesn't exist, was never reported.
So where is the bug report?
It is quite well known in Debian the decision was politically motivated and backed by several ex-RH elements of the board.
Name them?
You lie, troll. That works as documented in all versions of systemd in use.
Lying troll detected -- systemd does, unlike sysvinit, save stderr to the journal.
If you don't want to use systemd with jessie then use init, or even upstart if you want.
If I had mod points ...
PERHAPS someone could define what was broken so badly in init that the whole lot was replaced. I so dearly would like to know.
Ubuntu doesn't use init you moron, they abandoned it years ago.
It even says that in the summary.
Don't forget to tell us the story of that famous western lawman, Marshal Law.
Why not? Clowns like you get to vote.