is it the future?

[Kevin Fenzi]

On Fri, 12 Sep 2014 21:00:01 +0200
Anders Wegge Keller <wegge at wegge.dk> 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. 

> > 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 you started a sysvinit service foobar and wanted to look at it's
> > output, you had to hope the needed info was also in a log file or
> > kill the service and restart it in some non standard mode to watch
> > it's output. With systemd/journald, ALL output is saved and easy to
> > query. 
> 
>  At the cost of extra memory usage and/or disk I/O. Do you run into
> that kind of problems often enough, that it warrant that? It's not
> gain for me.

The amount of memory and i/o is trivial, IMHO. 

> > If for some reason you had to modify a complex sysvinit script, you
> > then would have to merge in all changes with package updates over
> > time. With systemd you can use a .d directory to add/change things
> > without overwriting the provided systemd unit file."
> 
>  Overrides are IMHO not an improvement. Having everything in one
> script makes it easy to see what is trying to start. The sh scripting
> language is expressive enough, that you can do all kinds of emergency
> hacks there, and get the system running again, when the customer host
> system drops NFS, or what else is the matter. Messing around with
> several layers of indirection is not something that improves
> maintainability.

I've seen some quite crazy sysvinit scripts in my day. Where it would
take a fair bit of debugging to just figure out what they were trying
to do. The 'emergency hacks' then tend to stay around and when the
package updates, you don't get the changes in the new version of the
init script. 
> 
> > I'll add in no particular order: 
> > 
> > * 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. 

> > * 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? 

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. 
 
> > * Log querying with journalctl is great. I can easily look at the
> >   messages from the previous boot (no matter when it was) or the one
> >   before that. I can look at just output from one service, etc etc. 
> 
>  At the cost of a ridiculously complicated binary format. I'm not
> aware that the WoNTFIX issue with journal corruption still stands,
> but just giving that answer in the first place... What's the worth of
> a whizbang feature, that's unreliable?

I've not found it to be unreliable at all. I don't find the (fully
documented) format that complex. 
> 
> > Anyhow, I could go on, but I think at least some of the folks on
> > this list (Not sure if you are one of them) have made up their
> > minds, and nothing I can say will convince them otherwise. In that
> > case, we should probibly just agree to disagree and move on. 
> 
>  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. 

> > If not, I am happy to help folks track down and report bugs with
> > systemd, or if you have questions on how to do something in
> > particular or if there's some case that could be improved. 
> 
>  I hope it's just the most extreme cases of developer arrogance I've
> seen, when people are referring to Lennart Pöttingers attitude. But
> what I've seen does not make me want to report anything, anywhere. 

You're choice of course. Note however that Lennart is not the sole
systemd developer. There's a bunch of them. 

> >>  As the only alternative is Slackware, one might as well stick
> >> around. Since I'm stuck with RHEL at work, I relly haven't got much
> >> choice in desktop distro.
>  
> > Fair enough, do as you like indeed. However, I don't see that it
> > helps anyone to have a "systemd is horrible" thread every month
> > that consists of bunches of people saying how much they hate it
> > without any positive outcome. ;) 
> 
>  Insanity is doing the same thing over and over, expecting the result
> to be different :) 

I agree. Thats why I say I don't understand these threads. ;) 

> And in the meantime, we all get a bit of katarsis.

I suppose. Possibly at the cost of other people looking at the list and
running away due to all the negativity and yelling. 
 
>  But seriuously, IF someone can convince me that there has been an
> actual analysis behind the descision, based on something else than
> gut feelings and NIH, I'd very much like to see that. That might
> convince me the switch is sane, even though it's a net loss in
> maintainability in my situation.

Well, I'm not sure how to do that really... I'm happy to answer
specific questions, but I may bow out of this thread soon, as it's
sucking up time I should be spending more productively. 

Thanks,

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140912/66fcb5f3/attachment.sig>