[kwlug-disc] What is all this about systemd?

[Khalid Baheyeldin]

On Fri, Jul 18, 2014 at 3:28 AM, Chris Irwin <chris at chrisirwin.ca> wrote:

> On Ubuntu so far, upstart is the init system. It generally stays out of
> the way. Only one time I needed to deal with it, because MySQL would not
> start, and had to find out that it logged to a different destination
> (/var/log/upstart). Other than that, it is transparent.
>
>
> Upstart had some serious shortcomings as an init system.
>
> It's hard to criticize systemd for not being planned (original article
> said "FLOS" seemed ad-hoc) and yet consider upstart as an alternative. It
> didn't have support for overrides for several in-the-wild releases, which
> means you couldn't disable an init script (or change when it runs) without
> actually modifying the script -- and reconciling the changes during
> upgrades.
>

Why do you say an init script can't be disabled?

On Ubuntu, there is usually an /etc/default/daemon_name file that has an
ENABLED= which the init script checks.

If that does not do it, then you can use the usual update-rc.d to disable a
service.

 Systemd is not like that. Wikipedia says that systemd provides
> replacements for:
>  - SysV Init
>
>
> This is where the bulk of my experience with systemd lays so far. I've
> written several unit files for both personal and work use. Took me less
> than an hour to to write my first one, using nothing but man pages. It's
> plain text, and about a dozen lines, commented. There's no boiler-plate, no
> bash case statements, no environment contamination. It compartmentalizes,
> and is capable of killing mis-behaving services, even their forked,
> orphaned children.
>
> It's the sanest method of configuring startup. Instead of re-inventing a
> start/stop bash script for every service, you write a simple config file.
> Upstart was configured similarly, but handled things far too simplistically
> -- It didn't clean the environment, it allowed services to be started as
> children of your shell (which caused significant issues when testing
> upstart at work).
>

Good to know.

- syslog
>
> This is the weakest point with me, simply due to my lack of exposure to
> it. It has a more detail and some extra metadata associated with each
> logged line. Some program logs are simply their STDOUT, so you might not
> even have timestamps. With systemd's journal, you have that information if
> you want it.
>

Any program outputing to the syslog facility (or its various revisions,
such as syslog-ng, rsyslog, ...etc.) will have timestamps automatically
added by syslog when it receives the message.


>  What I can't get is why Debian, the most community run of them all, and
> one of the oldest, has decided to go with something like systemd.
>
>
> I don't understand why community and systemd must be opposed?
>

This was in response to a comment about corporate influence and such, which
is absent in Debian's case.

-- 
Khalid M. Baheyeldin
2bits.com, Inc.
Fast Reliable Drupal
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
For every complex problem, there is an answer that is clear, simple, and
wrong." -- H.L. Mencken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20140718/973e8833/attachment.htm>