On Fri, 12 Sep 2014 13:12:28 -0600 Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Fri, 12 Sep 2014 21:00:01 +0200 > Anders Wegge Keller <wegge@xxxxxxxx> wrote: > > > Funny how two different career paths can bring us to two radically > > different stances. May I ask what field you work in? My own > > background is upper level machine controls where we generally end up > > requiring as stupid a box as possible. > > I worked in programming/system development, then for the last many > years system administration. What kind of systems? Apparently ones that needs much more tinkering than those I've been DevOps'ing for the last 17 years. > > > If you did a 'service stop foobar' it would try and stop foobar, > > > but if the pid file was stale, foobar started other stuff that > > > wasn't tied to foobar as a parent, or any other of a number of > > > situations I have run into, parts of foobar would still be running. > > > With systemd, if you stop a unit, it's really stopped. All of it. > > > > I've yet to see this as a real life issue. > > I'm surprised. Perhaps you did hit it but didn't notice it? > You tend to notice things like this when managing large numbers of > systems... If a failure went unnoticed, the service was unneeded in the first place, so your guess is as good as mine there. ... > > > * unit files are vastly simple to write. I created some unit files > > > for some irc bots I run in about 5minutes. This would have taken > > > copy and pasting bunches of stuff to make a sysvinit script that > > > wouldn't have worked as well. > > > > Do you write init scripts often enough that it's an issue? See > > Randall Monroes wonderful chart at http://xkcd.com/1205/ > > Yes. As a sysadmin you have to write scripts somewhat often. Your kind of sysadmin. My kind doesn't. > > > * Setting some buggy service to restart on failure is trivial to > > > do. > > > > Again, I've never run into a service that could be allowed to fail. > > Either it's critical, and must run, or it's been disabled. > > So, you tell the customer: While we are debugging why this service is > crashing, it may be down for a long periods at a time until someone > complains that it's down so we manually restart it? No, that service isn't on our systems in the first place. I'm not kidding, when I say we need as stupid a machine as it comes. The codebase I manage have been ported from SCO Openserver, and it really is most happy running on an electrical abacus. Most of my system administration is finding out how to disable things. Like udev, which is a PITA for us. > I agree you need to fix the underlying problem, but issues that are > not easy to track down can very much be helped by being able to > restart services without human intervention. We do rarely rely on any traditional system service, so really. The code is self-contained, to the point where we have our own implementation of ftp. > I've not found it to be unreliable at all. I don't find the (fully > documented) format that complex. I guess you have seen the bug reports, proving otherwise? One of them are linked from the boycott site. > > I would like to be convinced. But I'm not swayed by fluffy claims, > > that haven't been thought through. There are a lot of theoretical > > nice to haves, that are useful once in a decade, at least for me. But > > they come at such a great price, in complexity and risk, that they > > are not worth it. > > I find the nice to haves usefull all the time. Sorry you don't. That's it? I'm sorry you turned out to be such an arrogant prick in a single sentence. What's the point of people even trying to ppoint out why systemd isn't the bee's knees in all cases, when this is the reaction? > You're choice of course. Note however that Lennart is not the sole > systemd developer. There's a bunch of them. Put Lennart into a retirement home, and wait until he's been forgotten. He brings enough bad karma for all involved to share. -- //Wegge -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
