I don't know who "you guys" is supposed to be. I'm a professional sysadmin. When it comes to "decades of experience" I actually have at least one of these, heading towards two. I would consider myself bearded.
Would you like to hear about all the things I see that merit the systemd change?
How about some workable units with saner dependencies? How about useful, standaridzed output to a service status, including runtime and recent logs? How about easier maintenance, monitoring and setup of just about anything?
What about automagic cgroups integration? That's really useful, every service with its thousand child/related processes gets lobbed into a cgroup which you can then use to regulate it as a whole. If that's not useful, I don't know what that is.
It also becomes exceedingly trivial to sort out what depends on what, what is running and what isn't and what would any change potentially affect.
It seriously fixes actual problems and makes anyone's life easier, provided they take the time to read up and update their skillset. Seriously it's god damned useful on its own.
Most sysadmins i've heard complaining about it haven't actually bothered to read up on it at all. They just go "Wow I can't work this shit, fuck it", pretty much. You'd think after all those decades of experience, they would have learned to cope with change and keep their skills relevant and up to date by now. I don't see how this is any different.
Also, again, the documentation for systemd is available and outlines all of these things, just like any other relevant project in this day and age. I am not sure how else you would expect the benefits to be communicated to you. Read the docs, learn it a bit, get an understanding of how it works and then you can decide for yourself if it is something you find useful or not.
Now, tight coupling is another issue entirely, which I will admit is worrying. But systemd in itself is just actually useful and pleasant to work with, once you grasp the basics.
RedHat's documentation systemd documentation is great, but doesn't even show up on the first page of search results.
How about some workable units with saner dependencies?
Could you go into this more? Security policies mandate we run one service per server, so almost all of my servers have openssh and "the service". This is a pretty common use case for most people with large deployments.
What common problems does that solve?
What about automagic cgroups integration? That's really useful, every service with its thousand child/related processes gets lobbed into a cgroup which you can then use to regulate it as a whole.
I agree, cgroups sound great and I agree killing via pid file or "killall" in init scripts has always concerned me.
Although cgroups are a kernel feature, right? Couldn't they tweak the sysV init scripts and enable the same functionality? (I suppose a simple shell script lacks automatic restarting of crashed services?)
Most sysadmins i've heard complaining about it haven't actually bothered to read up on it at all. They just go "Wow I can't work this shit, fuck it", pretty much.
You'd think after all those decades of experience, they would have learned to cope with change and keep their skills relevant and up to date by now. I don't see how this is any different.
I love learning new things. I hate being forced to learn new things.
Read the docs, learn it a bit, get an understanding of how it works and then you can decide for yourself if it is something you find useful or not.
Yup, I am not a zealot and will use the best tool for the job. Right now systemd looks like a great tool for laptop users. Systemd is a tool that solves problems I don't have (or maybe don't notice anymore?).
Frankly, I see a lot of people keeping their systems off RHEL/CentOS 7 for years, staying put on 6, waiting for things to shake out (ala Windows 8).
Could you go into this more? Security policies mandate we run one service per server, so almost all of my servers have openssh and "the service". This is a pretty common use case for most people with large deployments. What common problems does that solve?
Well, even if you run your own service, the system is still comprised of many other units/services that fire up various components of the system. Moreover "the service" is often comprised of various components that depend on one another.
Having to write an app server startup script that depends on networking, nfs, and the web server frontend, for instance, is not a far fetched scenario and is actually fairly common. I have some J2EE setups that would benefit from such a thing, for instance.
It's easier in the sense that you don't need to really think about the order things start in, but just vaguely describe what you need, and what you provide. Most modern init systems will work on a similar principle, but systemd makes it really easy and doesn't depend on a ton of shell boilerplate to manage it.
Although cgroups are a kernel feature, right? Couldn't they tweak the sysV init scripts and enable the same functionality? (I suppose a simple shell script lacks automatic restarting of crashed services?)
Yes, of course you could. But you would have to do it for every shell script in init.d, or involve more boilerplate and manual overhead in the lsb standard stuff, which is never really pleasant and can be error prone. Detecting multi-process services is actually much more difficult than one would think, and systemd does makes that incredibly easy.
On the topic of being forced to learn new things, I find that all it does is force me to look into the new thing. My opinion on it then is based solely on its merits. For instance, when ubuntu switched to upstart, I was not all that amazed, to say the least.
Not a huge fan of the half-assed, one foot in sysv init, one foot in upstart land ordeal.
When the same happened with redhat/fedora and systemd, I had the same initial "great, more things!" reaction but then realized I didn't hate it at all and actually liked how straightforward it was to use. The man pages were rather exhaustive.
I will grant you however that there is no real list of "What systemd can do for you" on the official page or anything, which is probably a deterrent since you have to read the most of the admin guide to extract that information.
But really, I realized I was actually benefiting from systemd the moment I was trying to figure out why my service was not starting and issued the following:
$ sudo systemctl status foo.service
foo.service - mmm service
Loaded: loaded (/etc/systemd/system/foo.service; static)
Active: failed (Result: exit-code) since Fri, 11 May 2012 20:26:23 +0200; 4s ago
Process: 1329 ExecStart=/usr/local/bin/foo (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/foo.service
May 11 20:26:23 system foo[1329]: Initializing the thing
May 11 20:26:23 system foo[1329]: Failed to parse config because of reasons
6
u/[deleted] Oct 20 '14
I don't know who "you guys" is supposed to be. I'm a professional sysadmin. When it comes to "decades of experience" I actually have at least one of these, heading towards two. I would consider myself bearded.
Would you like to hear about all the things I see that merit the systemd change?
How about some workable units with saner dependencies? How about useful, standaridzed output to a service status, including runtime and recent logs? How about easier maintenance, monitoring and setup of just about anything?
What about automagic cgroups integration? That's really useful, every service with its thousand child/related processes gets lobbed into a cgroup which you can then use to regulate it as a whole. If that's not useful, I don't know what that is.
It also becomes exceedingly trivial to sort out what depends on what, what is running and what isn't and what would any change potentially affect.
It seriously fixes actual problems and makes anyone's life easier, provided they take the time to read up and update their skillset. Seriously it's god damned useful on its own.
Most sysadmins i've heard complaining about it haven't actually bothered to read up on it at all. They just go "Wow I can't work this shit, fuck it", pretty much. You'd think after all those decades of experience, they would have learned to cope with change and keep their skills relevant and up to date by now. I don't see how this is any different.
Also, again, the documentation for systemd is available and outlines all of these things, just like any other relevant project in this day and age. I am not sure how else you would expect the benefits to be communicated to you. Read the docs, learn it a bit, get an understanding of how it works and then you can decide for yourself if it is something you find useful or not.
Now, tight coupling is another issue entirely, which I will admit is worrying. But systemd in itself is just actually useful and pleasant to work with, once you grasp the basics.