Friday, May 10, 2013

cgroups: A BIG WIN for Systemd

by Dietrich Schmitz


Oh dear.  What have I done?  :/


I am afraid I have stirred up a hornets nest.  With several related articles under my belt regarding systemd, I continue to pursue this subject matter because of its great importance.

As an advocate, it is important to be critical.  It is also important to turn things over and see things in as objective thinking as is possible, looking for the merit. (Image credit: Red Hat)

Today, I focus on some of the merit that has many so enthusiastic about systemd.

In particular, cgroups, a new technology in the Linux Kernel has been integrated into systemd.

What Matters to System Administrators and Users?


The truth is, most users won't even see or give a hoot about cgroups or systemd, nor will they care anything about their Distro other than how they use it for every day things.  And that is to be expected.

But to the Linux System Administrator who must keep servers numbering in the hundreds or more stable and running without interruption, the devil is in the details and necessarily they must know and understand systemd to accomplish routine configuration changes and to respond to situations that require attention such as when a daemon service becomes unresponsive and must be bounced (stop/start).  These kinds of things are what System Administrators do and the process of learning new technology is a necessary ingredient to staying on the cutting edge and maintaining proficiency.

So, I've spent considerable time poking at systemd, yes?  This time I look at why, just why, maybe there is merit in employing systemd.  Now, many of you are ready to take issue with me, but please remember my role here.  Advocacy is 'for' and 'against' so I've been most often against certain things.  Putting aside how systemd was designed (merging udev) and what that did to the larger Distro community, cgroups does indeed offer something quite good.


The Return of the Zombies


You see it often.  A 'Zombie' child process or an unresponsive daemon service requires your attention.  It is a source of continual maintenance when a service goes silent or one of its child processes does and the whole daemon service shuts down randomly with no explanation.  System Administrators say: "It just happens now and then, that's why we run Nagios to stay on top of it."

That's fine and tools like Big Brother and Nagios are what is needed in this context.  But does systemd offer a finer degree of control given that it has croups embedded?

The answer is yes.

cgroups and Why They are Important

To the extent that Red Hat has a vested interest in the furtherance of systemd and plan to deploy such technology in their next iteration of Red Hat Enterprise Linux 7, much, if not all, of the work being done thus far on systemd has been undertaken by one of their employees +Lennart Poettering.  To his credit, Lennart has been around the corner, so to speak, and has a track record for writing many complicated projects, including PulseAudio.   

So, where can one find more about cgroups?  It just so happens that Red Hat have been doing their own homework, per usual, and have many on-line resource materials that help educate the System Administrator, including some good information about cgroups here.

In the course of discussion in the comment section of my website, one article, stirred the hearts of many to come forward and respond.  One individual has done a good job of giving good constructive replies and demonstrates a better understanding of systemd than perhaps any other respondent I have read.  In my story: Systemd: An Accident Waiting to Happen, Peter Dolding writes:












Shell scripts don't trace processes. This is the problem scripts and items like it work as long as everything is well behaved.

As soon as you get malfuncting service. Solaris zones or linux cgroups around it keeping track of every process it starts. Becomes a good send. 
The problem for over 30 years the same thing:
1) init starts a service process.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) service started falls over in a heap because sub process is still alive. 
That 1 to 5 (rundown) to your normal init systems includes (Ubuntu's) upstart. 
Solaris and systemd due to usage of zones and cgroups (respectively): 
1) init starts a service process wrapped.
2) The service process starts some other sub process it needs.
3) The service process gets terminated to restart
4) The sub process stays running.
5) Init system checks if anything is left in the cgroup or zone that should have been terminated.
6) service restarted stable.
This is why the old system is broken Dietrich.
Is systemd the right fix needs to be the question--not putting your head in sand and pretending problem does not exist. 
Dietrich the other big thing you have missed is that udev is going into the Linux kernel. As a kernel feature. BSD and other operating systems really have to catch up. 
There are major performance issues running udev userspace. There is also security issues runnign udev userspace. There will be no need for systemd to look after udev long term. Because udev will not exist.
Instead kernel udev will be used.
It's the same kicking and screaming over moving video card memory management into kernel space.
This is nicely put.  I have yet to see anyone explain it better and in such concise terms.  Well done Peter Dolding.


Conclusion


If more people will step back from the issue and wrap their minds around the above, I think it will help them to grasp what is happening to Linux in the long term.  Does breaking compatibility with things related to BSD matter?  I am not sure on that.  Debian chose to make systemd an opt-in choice for their just released Debian 7 Wheezy project, specifically because it does break GNU/kFreeBSD.

I want to believe their is merit in systemd and so, in this round, I am looking at the glass 'half-full' as opposed to being 'half-empty'.  

I pledge to l continue, in investigatory fashion, to examine all things which effect Linux, turning them over to see them from different perspectives.  That is necessary to being a good advocate.

With that, I hope this post has done some good.  What are your thoughts?

-- Dietrich




Enhanced by Zemanta

0 comments:

Post a Comment