SCIENTIFIC-LINUX-USERS Archives

August 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
Date:
Tue, 26 Aug 2014 13:42:17 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (84 lines)
On 26/08/14 01:57, Steven Haigh wrote:
> On 26/08/2014 9:36 AM, Vladimir Mosgalin wrote:
>> Hi Ken Teh!
>>
>>  On 2014.08.25 at 12:58:21 -0500, Ken Teh wrote next:
>>
>>> I read the following article on systemd
>>>
>>> http://ifwnewsletters.newsletters.infoworld.com/t/9625863/474699771/826094/14/
>>>
>>> The comments suggested one could still revert to sysvinit.  Is this just wishful thinking on my part?
>>
>> Yes. As an exercise, why don't you revert EL6's upstart to sysvinit?
>> Note that enabling/disabling some services on EL6 *requires* you to use
>> upstart-specific initctl, you simply won't notice these services if you
>> will only look at chkconfig.
>>
>> systemd offers many benefits for system administrators, like:
> 
> No, no it doesn't.

[...snipped out ranting...]

First of all, systemd is a new way of thinking bootup and system
management.  It requires users to adjust to the a way of doing things.
I used to be a sharp systemd critic, after struggling with it during
testing of Fedora 15.  I've run Fedora 19 and Fedora 20, and accepted
that systemd is not going away.  And I do begin to like it.  And I very
much look forward to it in EL7.  Even my Jolla phone uses systemd, and
it was a breeze to write the needed unit file to make it load my own
firewall rules at boot.

Remember that systemd replaces _more_ than just the init scripts and the
boot process.  It is a full blown system _manager_.  Its task is to
ensure a predictable behaviour as long as the system runs.  If you plug
in or remove hardware, the appropriate actions should happen.  If a
specific network becomes available, network filesystems can
automatically be mounted.  Restarting of processes which dies can be
tackled automatically (and disabled where you don't want it).  Resource
management via cgroups can be tackled in a more consistent way.  And
more.  All this via a more standardised set of tools, which knows about
each other and tries to avoid to trip on each others toes.

I can agree that systemd has a broad footprint.  But the more I play
with it, the more I can understand why it needs to have a broader scope
than just kicking off init scripts at boot.

So for debugging ... you'll get some nice clues here:
<http://freedesktop.org/wiki/Software/systemd/Debugging/>

More on verifying bootups:
<http://0pointer.de/blog/projects/systemd-for-admins-1.html>

More on the journal:
<http://0pointer.de/blog/projects/journalctl.html>

Making unit files from sys-v init scripts:
<http://0pointer.de/blog/projects/systemd-for-admins-3.html>

In fact, there's a lot of good information from the systemd site:
<http://freedesktop.org/wiki/Software/systemd/>

Moving towards a more modern system management is painful when you're
used to "the good ol'tools".  Systemd is tearing up a lot of old stuff
which I begin to see should have been improved ages ago.  Canonical
dared doing a lot with upstart.  And systemd just takes a bigger leap.

A lot can also be said about that the old sys-v approach has worked well
for so long that it can't be wrong. But I'd say that if you take the
best racing driver from the 60s and put him into a racing car of this
century, he probably won't win a race.  Because the technology has
evolved.  We need tools and drivers of the new technology to be in sync.

So I encourage people to give systemd a fair chance.  Accept that it
does things differently, and see how it can be used to reach your goals.
 Hopefully you'll see what I've seen so far, that it actually works
quite well.


-- 
kind regards,

David Sommerseth

ATOM RSS1 RSS2