On 26/08/2014 9:42 PM, David Sommerseth wrote:
> 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...]
Today I learnt that if you don't fit a standard model for usage, you
become a ranter....
>
> 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.
<snip>
> 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.
I've given it a fair go - but there is a BIG problem if you don't fit
the standard model that systemd forces you into.
Ok, so off the top of my head, the following is broken with systemd as
of right now:
1) Logwatch doesn't work at all with journals.
2) You can't pipe the journal to a different machine as per remote
syslogging (which is a standard for decades). You can run syslog *as
well* as systemd logging, but output is limited compared to journals.
3) SNMP monitors that monitor log files are broken because of point #2.
4) A heap of very basic changes require you to write your own service
file for systemd. While it isn't hard, I found that roughly half of
services I required to run needed me to write my own service file
(remember, you can't just edit the one in /usr/...../ etc).
5) Network stability was faulty in my tests - you could not guarantee
that networking would start (this is a static IP case) on every boot.
This alone is critical.
6) The concept of a binary log file is flawed from the start. IBM used
to do it, but afaik, abandoned the idea in most products.
7) Parallel service start introduces a range of issues that do not
happen in serial boot order. In enterprise land, we care about stability
- not speed. As a comparison, the BIOS on the RAID card takes longer
(usually 45-50 seconds) than booting the system no matter what OS / init
system.
8) SystemD isn't just about system boot. It replaces logging, cron,
monitoring, service init and more. It gets its claws into everything -
but not everything it replaces gets done well. I'm half expecting it to
grow an email client in there as well.
I have no problems with change when it is done well. The problem is,
SystemD has not been done well and introduces more problems than it
fixes. To say that it is perfect more indicates that you fit the SystemD
mold rather than SystemD actually doing its job properly.
In other news, there was a recent slashdot article on this exact subject:
http://linux.slashdot.org/story/14/08/25/1730245/choose-your-side-on-the-linux-divide
There is certainly a new trend of linux developers around - and the
problems that are being introduced now are the same ones that were fixed
decades ago by the previous generation of developers. The problems
haven't changed - only the way they are approached.
--
Steven Haigh
Email: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
|
