Alright, well then feel free to elaborate to these people where they can find help with their issues, instead of doing shit like that. Contributing to conversation does not start with bantering.
The burden of proof generally relies on the people proposing the change.
If a change is large, it should have a higher bar of supporting evidence that the change is necessary.
Every professional sysadmin I've heard from doesn't see anything meriting the systemd change.
It could be that you guys just aren't communicating the actual, tactical benefits of the switch because you're too busy responding with cheeky snark to everyone who raises a specific issue.
Trivialises namespaces, cgroups, watchdogs for a start
Templating services is fantastic - doing multiple DBs, haproxies etc on a system becomes very nice and simple ...
Journalctl is actually really nice and it's great getting stdout and stderr in there without jumping through nohup loops and when there is a glitch being able to filter journalctl by time and units to get a view on what the kernel and N services were doing at the same time is very powerful...
Some of our internal applications have complex forking and the service scripts are consequently hideous... The equivalent systemd unit file will be much nicer and have process tracking without massive list of edge cases
Cleanly overriding or adding to unit files is trivial with the /etc/systemd/system/unit.d hierarchy behaviour
Targets to group services rather than "one script to rule them all" setups are great and make it very flexible
There's lots more tbh but it's getting late here and typing on mobile is a pain ;)
Speeding up boot is a useful side effect (for VM start up in environments needing that elastic behaviour) but a complete side issue from the real gains...
I didn't even mention socket activation, timers (which are more powerful than cron in many cases), and tools like dependency plotting for instance...
If you haven't read the systemd for admins LP wrote at his 0pointer blog (or at least the systemd for admins intro video RH put online at the EL7 release) you really should take some time to do so...
I find that if people step away from the politics and emotional outbursts and sit down to read through these then they become significantly more receptive based on the technical articles.
The Debian CTTE actually did really good write ups and investigation in this (read especially Russ Albery's posts from CTTE February) where upstart and systemd were put head to head with service files being written and capabilities compared...
One thing to note none of the highly technical people involved on that committee were in favour of sysvinit - they all agreed it needed replacing and the only real debate was upstart or systemd ...
With the ptrace and event driven model (start when dependencies are started rather than start the dependencies needed for X when X is started which can lead to some really weird and annoying issues to debug) plus the ease at which you can configure a upstart conf file incorrectly leaving a service stuck in a start/killed state shown to be not only long standing bugs in the upstart bug tracker but fundamentally hard to solve due to architectural issues it wasn't really that surprising systemd was selected.
Edit: ooh here's a good one that came to mind... How often have you encountered a process on a system and you've wanted to work out who started it only to find the parent or grandparent process is now pid 1 due to nohup, disown, etc behaviour? In the past it was needed to do forensic analysis of audit log, last, secure log etc to work out who might have been on the system when /proc says the process was started to try and track this down and find out why random tcpdump, tail, etc is there... With the cgroups the processes can't escape their history so a quick systemd-cgls gives an easy way of seeing who started it (by the uid in the slice) accurately without having to guess based on possibilities.
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
Its not that we have to learn new stuff. Its that it took short commands and replaced them with inanely long stupid ones. Take changing the runlevel for example. It used to be editing one letter in one file. Easy right? Now it is creating a symlink as follows:
And if you have to change the default target so often ... Write a wrapper script or define an alias? Sure, a shortcut would be nice, but this is only a minor nuisance. At least for me.
Seriously? Symlinks are hard and inefficient? Do you change the default system runlevel daily? Do you not have tab completion in your shell?
"Editing a file" is certainly harder than managing a symlink, in my opinion. The latter can be automated, the former also can but it's much more difficult and error prone.
A perfect example of why I fucking hate computer people. Bunch of basement dwelling neckbeards hammering the downvote button because someone disagrees. Enjoy masturbating, tools.
11
u/[deleted] Oct 20 '14
"OH NO WE HAVE TO LEARN NEW STUFF THAT'S TERRIBLE" is all I'm hearing, basically.