On 26/08/14 14:01, Steven Haigh wrote:
> On 26/08/2014 9:42 PM, David Sommerseth wrote:
[...snip...]
> 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.

Install rsyslogd, and you're good to go.  You do not have to use the
journal.  And AFAIK, rsyslogd is installed by default on EL7.

Also see these resources:
<http://blog.delouw.ch/2013/07/24/why-journalctl-is-cool-and-syslog-will-survive-for-another-decade/>
<https://fedoraproject.org/wiki/Changes/NoDefaultSyslog>
(Especially notice the "Dependencies" section)


> 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).

You do not have to write your own unit file for systemd.  In most cases
existing init.d scripts will work perfectly fine.  There list of
incompatibilities is rather specific and not that long:

<http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/>

> 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.

Agreed, that is critical.  Did you debug this?  Was this on EL7?  Any BZs?

> 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.

Again, use rsyslog if you want human readable log files.

> 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.

And this is some of the factors systemd can control even better than
sysv init scripts.  Using 'Wants', 'Requires', 'After' and 'Before' in
the unit file you can more fine grained control the order of execution.
 It's all described in the systemd.unit man page

<http://www.freedesktop.org/software/systemd/man/systemd.unit.html>


> 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.

It *can* provide similar functionality to those services if you want it
to.  Install rsyslog or cron, and you'll get the old behaviour.

For monitoring tools, if they use 'ps', 'pidof', 'netstat', pid-files or
similar approaches, nothing changes.  If it depends on the output of
'service $SRV status', I would say the tool is doing it wrong (it would
be very tight connected to specific distro releases).  If the monitoring
depends on log files, install rsyslog.

> 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.

I've never said systemd is perfect.  But from my point of view, it
solves a lot of issues related to the more modern age of computing, with
virtualization, containers and resource management.  I don't say that
sysv didn't work well, in fact it worked very well for a long time.  But
during that time, virtualization and containers was not the typical use
cases.  And you had a bunch of other tools to do the resource
management.  Systemd unifies these areas and provides tools which makes
it easier to the sys-admin task when you're using the computer
technology of this century.

> 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.

The core problems haven't changed, but they've become far more complex.
 The hardware and the technology in general have evolved so much of the
last 30 years that not all concepts are equally well suited today as it
was in the mid-80s or 90s.  The requirements of today's services are far
more complex.  And you need a framework around that which is up to the
task of today's computer environment.

I've been a Linux user since the late 90s, and have run Slackware,
RootLinux, Crux, Gentoo, SuSE, Ubuntu, Fedora, RHEL/CentOS/SL, and
probably even more.  I've also played with *BSD distros.  Running on
servers, desktops and laptops, going from only wired networks and
dial-up to wifi and mobile networking.  I've had a fair deal of
scepticism towards HAL, devfs/udev, d-bus, NetworkManager, systemd as
these where introduced.  Finding they make things more complicated.  But
as these projects have evolved and matured, I've found them more often
solving my issues more elegantly than the alternatives.  Systemd is a
paradigm shift in system management on Linux, but I believe it is
required to be able build a sustainable computing platform for the future.

Also bear in mind that Solaris 10 has the SMF, which is quite
differently from sys-v.  The same with OSX, which uses launchd.  So
moving away from the good old sys-v isn't something only happening only
in Linux.  Which again tells me that there is a need for a more modern
alternative to sys-v.


-- 
kind regards,

David Sommerseth