Cockpit presentation [WAS: Re: systemd (again)]

[David Sommerseth]

On 15/02/15 13:11, David Sommerseth wrote:
> 
> I was recently at devconf.cz where Cockpit was presented.  That
> provides a really neat way of system management via a
> web-browser and makes use of several systemd features.  It is
> now shipped by default in Fedora 21, but I'd be surprised if it
> won't run on EL7.  (I haven't had time to do some test builds yet)

Just found the Cockpit presentation from devconf.cz, for those of you
interested.




-- 
kind regards,

David Sommerseth

Re: systemd (again)

[Nico Kadel-Garcia]

On Sat, Feb 14, 2015 at 12:25 AM, Orion Poplawski  wrote:
> On 02/13/2015 09:06 PM, Nico Kadel-Garcia wrote:
>>
>> On Fri, Feb 13, 2015 at 9:59 PM, Keith Lofstrom  wrote:
>>>
>>> If systemd is a major resource hog, then our high-performance-
>>> machine comrades will come up with something that leaves more
>>> CPU cycles for doing computation over the next decade.  I hope.
>>> Zillion-CPU computing is intolerant of expensive waste.  If RH
>>> someday insists on intolerable resource misuse, we are in the
>>> right community for a mutiny and a new direction.
>>
>>
>> The difficulty is that it's creeping into levels and components that
>> didn't ask for it and don't need it, and thus becoming even more
>> bloated, With extraneous binary logging, and the tools to decode the
>> binary logging into something useful, with dbus integration and the
>> latest round of multiple ring integration for Fedora applications,
>> it's wedging it's bulky way into places that had no need of it.
>
>
> I'll be clear that there are things about systemd that do bug me, and it has
> taken a while to grow on me, but I think too much of the discussion gets
> emotional or subjective with terms like "bloated".  Someone's bloat could be
> someone else's greatly useful feature.
>
> In particular, while perhaps the use of a binary format is debatable, the
> existence of the journal is incredibly useful.  It allows for the capture of
> so much more output from system processes that wasn't possible before.  And
> it presents it in a structured and consolidated way.  Running "journalctl -f
> -p warning" is a great way to quickly monitor issues on a machine.
\
Which is great, when you need it, which is only a tiny fraction of
normal operating time. And it has a tendency to *spew* when you least
expect it. The results are fascinating and require yet another layer
of development insight and systems management. Those layers add up, in
the long run, to more resources for normal operation.

> In general I believe systemd takes system management, control, and
> monitoring to the next level.  There are growing pains, implementation
> issues, and other problems, but overall a great step forward.

And that next level will require significantly more system resources.
The "how much of the CPU is used by systemd" is misleading: how much
of the *kernel itself* is now involved in supporting systemd itself,
and how much of every new component that is dealing with the new
binary logging?

It's not the sole contributor to feature creep and bloat, but it's now
a component of it. And it's nowhere near a stage where the excess can
and will be stripped away: I see no sign of anyyone successfully
putting breaks on it and saying "whoah, partner, let's keep this
smaller and more stable!!!"

> Can't speak to dbus integration and I don't know what is meant by "latest
> round of multiple ring integration for Fedora applications".

You can see one of the proposals here:

https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html


>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 303-415-9702
> 3380 Mitchell Lane  or...@cora.nwra.com
> Boulder, CO 80301  http://www.cora.nwra.com

Re: systemd (again)

[Orion Poplawski]

On 02/15/2015 12:32 PM, Steven Haigh wrote:

On 16/02/2015 5:19 AM, Orion Poplawski wrote:

On 02/15/2015 08:53 AM, Steven Haigh wrote:

On 16/02/2015 2:29 AM, David Sommerseth wrote:
In the end, it doesn't do anything more functional than the old init
system did - just now that instead of throwing stuff in /etc/init.d, you
now have to write another file to then call the init script.

Web interfaces and other junk aside, systemd doesn't seem to do much in
the way of improvement - in fact, most features of priorities and
parallel start exist in sysvinit - but were never implemented properly
by distributions... So instead, we reinvent the wheel again...


It does a whole lot more that the old init system did, which an internet
search and a few minutes of reading would have made abundantly clear.
Just a couple points:


Oh I know - I don't know exactly if its a good thing or not.


Okay, but that's not what you wrote.


- It monitors the processes that is starts and can restart them if they
die.


This is not always good. I can think of many reasons why you don't want
to automatically restart processes. There are some good as well, but not
as many imho.


Certainly, which is why it's configurable on a per-service basis.  But I 
think it's very useful.



- It can log the output in the journal that would have otherwise been lost.


Which is a binary logfile that most people ignore and end up with syslog
anyway. There is a reason syslog is found just about everywhere.


People may be ignoring it now as syslog is familiar standard, I know I 
did for a while.  But I'm finding it more and more useful as I use it.



Please people, let's do some research before just putting out our first
impressions as facts.


I'd hardly say its first impressions. Not being impressed at all isn't a
good feature - and 'but but but you don't know it!' is like that saying
"He's a good bloke when you get to know him"... What that really means
is that he's an asshole until you learn to put up with it - and that's
what we're really dealing with here ;)


I think I'm done at this point.  I just wanted to respond to "it doesn't 
do anything more functional than the old init system", which I believe 
is demonstrably false.  Whether or not you find that useful is certainly 
subjective.  I clearly do, and you clearly don't, and I'm fine with that.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com

Re: systemd (again)

[Steven Haigh]

On 16/02/2015 5:19 AM, Orion Poplawski wrote:
> On 02/15/2015 08:53 AM, Steven Haigh wrote:
>> On 16/02/2015 2:29 AM, David Sommerseth wrote:
>>>> From: "John Lauro" 
>>>> To: "David Sommerseth" 
>>>> Cc: "scientific-linux-users" ,
>>>> kei...@kl-ic.com
>>>> Sent: 15. februar 2015 14:33:25
>>>> Subject: Re: systemd (again)
>>>>
>>>> Sounds just what hackers would like.  A nice web interface that
>>>> doesn't even show up as a resource after it's been idle for 10
>>>> minutes so admins might not even realize if it's wide open...
>>>
>>> Gee ... if you look at netstat, I'm sure you'd notice that systemd
>>> is listening to that port.  I'm sure any responsible sysadmin will
>>> always double check which ports are truly open.  In addition, there
>>> is firewalling which any responsible sysadmin would not ignore to
>>> ensure is properly configured.
>>
>> netstat isn't the default way anymore... In fact, on some systems it
>> isn't even available anymore unless you include the net-tools package.
> 
> ?  This has always been the case.  Perhaps the improvement is the
> reduction of dependencies that may have brought in net-tools by default
> before.  But this is a good thing.  If you need/want net-tools (or
> anything else for that matter) you install it.
> 
>>> The advantage is that no system resources are spent on processes
>>> not being actively in use.  Yes, it requires another mindset.  But
>>> those who depend on evaluating system security primarily based on
>>> the output of 'ps' does a fairly poor job.
>>
>> So its xinetd? :)
> 
> Yes, it replaces that as well.
> 
>> I've done a little bit of work with Xen packages using SystemD - and to
>> be honest, it isn't *that* bad. If systemd is needed at all is a
>> different question - although we're just adding another wrapper layer
>> around an initscript that now gets called via systemd.
> 
> You're actually removing a bunch of shell scripting layers.

You're not removing anything. Its a binary daemon replacing a shell
script. And because it has its fingers in everything about your system,
it opens up amazing problems the minute you get a buffer overflow bug.

>> In the end, it doesn't do anything more functional than the old init
>> system did - just now that instead of throwing stuff in /etc/init.d, you
>> now have to write another file to then call the init script.
>>
>> Web interfaces and other junk aside, systemd doesn't seem to do much in
>> the way of improvement - in fact, most features of priorities and
>> parallel start exist in sysvinit - but were never implemented properly
>> by distributions... So instead, we reinvent the wheel again...
> 
> It does a whole lot more that the old init system did, which an internet
> search and a few minutes of reading would have made abundantly clear.
> Just a couple points:

Oh I know - I don't know exactly if its a good thing or not.

> - It monitors the processes that is starts and can restart them if they
> die.

This is not always good. I can think of many reasons why you don't want
to automatically restart processes. There are some good as well, but not
as many imho.

> - It can configure the environment of the processes it starts in a
> number of ways: cgroups, namespaces, etc.

and none of this can be done via shell scripts?

> - It can log the output in the journal that would have otherwise been lost.

Which is a binary logfile that most people ignore and end up with syslog
anyway. There is a reason syslog is found just about everywhere.

> Please people, let's do some research before just putting out our first
> impressions as facts.

I'd hardly say its first impressions. Not being impressed at all isn't a
good feature - and 'but but but you don't know it!' is like that saying
"He's a good bloke when you get to know him"... What that really means
is that he's an asshole until you learn to put up with it - and that's
what we're really dealing with here ;)

-- 
Steven Haigh

Email: net...@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



signature.asc
Description: OpenPGP digital signature

Re: systemd (again)

[Orion Poplawski]

On 02/15/2015 08:53 AM, Steven Haigh wrote:

On 16/02/2015 2:29 AM, David Sommerseth wrote:

From: "John Lauro" 
To: "David Sommerseth" 
Cc: "scientific-linux-users" , kei...@kl-ic.com
Sent: 15. februar 2015 14:33:25
Subject: Re: systemd (again)

Sounds just what hackers would like.  A nice web interface that
doesn't even show up as a resource after it's been idle for 10
minutes so admins might not even realize if it's wide open...


Gee ... if you look at netstat, I'm sure you'd notice that systemd
is listening to that port.  I'm sure any responsible sysadmin will
always double check which ports are truly open.  In addition, there
is firewalling which any responsible sysadmin would not ignore to
ensure is properly configured.


netstat isn't the default way anymore... In fact, on some systems it
isn't even available anymore unless you include the net-tools package.


?  This has always been the case.  Perhaps the improvement is the 
reduction of dependencies that may have brought in net-tools by default 
before.  But this is a good thing.  If you need/want net-tools (or 
anything else for that matter) you install it.



The advantage is that no system resources are spent on processes
not being actively in use.  Yes, it requires another mindset.  But
those who depend on evaluating system security primarily based on
the output of 'ps' does a fairly poor job.


So its xinetd? :)


Yes, it replaces that as well.


I've done a little bit of work with Xen packages using SystemD - and to
be honest, it isn't *that* bad. If systemd is needed at all is a
different question - although we're just adding another wrapper layer
around an initscript that now gets called via systemd.


You're actually removing a bunch of shell scripting layers.


In the end, it doesn't do anything more functional than the old init
system did - just now that instead of throwing stuff in /etc/init.d, you
now have to write another file to then call the init script.

Web interfaces and other junk aside, systemd doesn't seem to do much in
the way of improvement - in fact, most features of priorities and
parallel start exist in sysvinit - but were never implemented properly
by distributions... So instead, we reinvent the wheel again...


It does a whole lot more that the old init system did, which an internet 
search and a few minutes of reading would have made abundantly clear. 
Just a couple points:


- It monitors the processes that is starts and can restart them if they die.
- It can configure the environment of the processes it starts in a 
number of ways: cgroups, namespaces, etc.

- It can log the output in the journal that would have otherwise been lost.

Please people, let's do some research before just putting out our first 
impressions as facts.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com

Re: systemd (again)

[Steven Haigh]

On 16/02/2015 2:29 AM, David Sommerseth wrote:
>> From: "John Lauro" 
>> To: "David Sommerseth" 
>> Cc: "scientific-linux-users" , 
>> kei...@kl-ic.com
>> Sent: 15. februar 2015 14:33:25
>> Subject: Re: systemd (again)
>>
>> Sounds just what hackers would like.  A nice web interface that 
>> doesn't even show up as a resource after it's been idle for 10
>> minutes so admins might not even realize if it's wide open...
> 
> Gee ... if you look at netstat, I'm sure you'd notice that systemd
> is listening to that port.  I'm sure any responsible sysadmin will
> always double check which ports are truly open.  In addition, there
> is firewalling which any responsible sysadmin would not ignore to
> ensure is properly configured.

netstat isn't the default way anymore... In fact, on some systems it
isn't even available anymore unless you include the net-tools package.

> The advantage is that no system resources are spent on processes
> not being actively in use.  Yes, it requires another mindset.  But
> those who depend on evaluating system security primarily based on
> the output of 'ps' does a fairly poor job.

So its xinetd? :)

I've done a little bit of work with Xen packages using SystemD - and to
be honest, it isn't *that* bad. If systemd is needed at all is a
different question - although we're just adding another wrapper layer
around an initscript that now gets called via systemd.

In the end, it doesn't do anything more functional than the old init
system did - just now that instead of throwing stuff in /etc/init.d, you
now have to write another file to then call the init script.

Web interfaces and other junk aside, systemd doesn't seem to do much in
the way of improvement - in fact, most features of priorities and
parallel start exist in sysvinit - but were never implemented properly
by distributions... So instead, we reinvent the wheel again...

-- 
Steven Haigh

Email: net...@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



signature.asc
Description: OpenPGP digital signature

Re: systemd (again)

[David Sommerseth]

> From: "John Lauro" 
> To: "David Sommerseth" 
> Cc: "scientific-linux-users" , 
> kei...@kl-ic.com
> Sent: 15. februar 2015 14:33:25
> Subject: Re: systemd (again)
>
> Sounds just what hackers would like.  A nice web interface that 
> doesn't even show up as a resource after it's been idle for 10
> minutes so admins might not even realize if it's wide open...

Gee ... if you look at netstat, I'm sure you'd notice that systemd
is listening to that port.  I'm sure any responsible sysadmin will
always double check which ports are truly open.  In addition, there
is firewalling which any responsible sysadmin would not ignore to
ensure is properly configured.

The advantage is that no system resources are spent on processes
not being actively in use.  Yes, it requires another mindset.  But
those who depend on evaluating system security primarily based on
the output of 'ps' does a fairly poor job.


--
kind regards,

David Sommerseth


> - Original Message -
>> From: "David Sommerseth" 
>> To: kei...@kl-ic.com
>> Cc: "scientific-linux-users" 
>> Sent: Sunday, February 15, 2015 7:11:52 AM
>> Subject: Re: systemd (again)
>> 
>> Cockpit is not running by default, but if you go to
>> https://$IPADDRESS_OF_SERVER:9090/ systemd starts it
>> on-the-fly (through socket activation).  In the moment it's been
>> lingering idle for approx. 10 minutes, it is shut down again.
>> So there's basically zero-footprint when it is not being used.
> > This is one of the nice things about systemd.

Re: systemd (again)

[Tom H]

On Sat, Feb 14, 2015 at 6:23 AM, Vladimir Mosgalin
 wrote:
> On 2015.02.13 at 23:06:02 -0800, Keith Lofstrom wrote next:
>>
>> 3) Will systemd require Gnome 3/4/5/..N to manage properly?
>
> I don't even know what do you mean, systemd has nothing to do with
> graphics environment, you can manage every aspect of it on server
> without X, from text mode. In fact, I'm unaware of any graphical
> instruments to manage it, documentation only explains console commands
> and config files.
>
> (only backward dependency exists - some gnome 3 features require systemd
> to work)

Exactly. The OP seems to have reversed the dependency. It's some Gnome
components that depend on systemd.

Re: systemd (again)

[John Lauro]

Sounds just what hackers would like.  A nice web interface that
doesn't even show up as a resource after it's been idle for 10
minutes so admins might not even realize if it's wide open...



- Original Message -
> From: "David Sommerseth" 
> To: kei...@kl-ic.com
> Cc: "scientific-linux-users" 
> Sent: Sunday, February 15, 2015 7:11:52 AM
> Subject: Re: systemd (again)
> 
> Cockpit is not running by default, but if you go to
> https://$IPADDRESS_OF_SERVER:9090/ systemd starts it
> on-the-fly (through socket activation).  In the moment it's been
> lingering idle for approx. 10 minutes, it is shut down again.
> So there's basically zero-footprint when it is not being used.
> This is one of the nice things about systemd.

Re: systemd (again)

[David Sommerseth]

> From: "Keith Lofstrom" 
> To: "scientific-linux-users" 
> Sent: 14. februar 2015 08:06:02
> Subject: Re: systemd (again)
>
> 3) Will systemd require Gnome 3/4/5/..N to manage properly?
> 4) Can systemd /var/log files (or equivalent) be logrotated?
>
> Systemd is Red Hat's brainfart.  Their user base is institutions,
> not consumer tablets.  If systemd cripples Red Hat customers,
> Red Hat will either fix the behavior, or go bankrupt and stop
> pushing it.  I will count on the last two correctives to keep
> systemd from becoming a worst-case nightmare. 

Before I got to know systemd better, I'd call it a brainfart too.
But I've learnt to know better over the last year.  Systemd is so
much more than a initd process and I've gotten to know it as a
tool which fills a gap which has been open too long in the Linux
world. Systemd can really fill the gap related to system
/management/.

Systemd does not depend on GNOME at all.  But systemd does make
massive use of dbus and PolicyKit.  Which may sound odd, but when
starting looking at projects like Cockpit [1], it demonstrates
the power of the dbus integration.

I was recently at devconf.cz where Cockpit was presented.  That
provides a really neat way of system management via a
web-browser and makes use of several systemd features.  It is
now shipped by default in Fedora 21, but I'd be surprised if it
won't run on EL7.  (I haven't had time to do some test builds yet)

Cockpit is not running by default, but if you go to
https://$IPADDRESS_OF_SERVER:9090/ systemd starts it
on-the-fly (through socket activation).  In the moment it's been
lingering idle for approx. 10 minutes, it is shut down again.
So there's basically zero-footprint when it is not being used.
This is one of the nice things about systemd.

The next thing is that all the authentication is done properly
against system accounts (even Kerberos authentication with
GSSAPI/SPNEGO will work out-of-the-box, even though they're
ironing out an improved IPA integration).  If you log into
Cockpit as a non-sysadmin, you can look around but not change
much at all.  If you log in as a sysadmin, you can change
hostname, join IPA domains, start/stop services, tackle Docker
containers, inspect the journal, etc. In the git version of
Cockpit there's even a web based terminal And all this is
possible only because of the dbus interface. In fact, it can
only interact with dbus and nothing else.

During the demonstration we got at devconf.cz, a very simple
add-on was added.  They realized they had forgotten to add a
"Change time zone" feature.  This was very little of HTML code
(approx one screen page, 20-30 lines of code or so).  Once
Cockpit was refreshed, it was available and changing the time
zone from the command line, instantly updated the web-interface.
Changing it in the web-interface was again happening instantly
on the system.  In fact, the web interface was a live view of
what was really happening on the system (looking at the journal
from Cockpit demonstrated that very nicely).

I recognise that a web-admin isn't what everyone wants or
need.  But it lowers the management barrier for those used to
a more graphical environment.  And even though I do consider
myself as a power user (I've used Linux since mid-90s) and
really like the command line, I can also see myself using
Cockpit to get a quick overview over what is going on on a
system.  And especially since you can from one Cockpit
interface manage other systemd systems with Cockpit too
(Cockpit uses SSH for remote controlling systems).

Regardless of if you want or need Cockpit, it is a good
demonstration of what is possible to do on an systemd enabled
system. The Cockpit maintainer said loud and clear that
Cockpit doesn't do any rocket science.  It builds on what is
already present on the system (dbus, PolicyKit, systemd) and
presents and interacts with that information in an easy-to-use
web interface.  So I believe systemd can open up for better
system management tools in the future; how they will be only
depends on the imagination of developers and users.

If in doubt, I recommend you to try it out on a Fedora 21
test box.  And once that is running, try to pull down the
latest Cockpit version from git and compile it. And you'll see
some nice enhancements.

And one last comment.  Systemd is probably one of the few
projects which will be able to unite system management across
Linux distributions.  Something I have felt has been needed
a long time.  And thus with projects like Cockpit, it will be
possible to build one tool which can manage several
distributions basically out-of-the-box.  Combine easy-of-use
with powerful tools, and suddenly pure Windows-admins might
not be that afraid of to start getting familiar with Linux
systems.

[1] <http://cockpit-project.org/>


--
kind regards,

David Sommerseth

Re: systemd (again)

[Vladimir Mosgalin]

Hi Keith Lofstrom!

 On 2015.02.13 at 23:06:02 -0800, Keith Lofstrom wrote next:

> Well, hm.  My questions about systemd (some may be hard to measure):

Why hard?

> 
> 1) Does systemd use a LOT more RAM, like > 200MB, that cannot swap out?

# ps_mem |grep systemd
516.0 KiB +  60.0 KiB = 576.0 KiB   systemd-logind
  2.3 MiB +  65.5 KiB =   2.3 MiB   systemd-udevd
  3.6 MiB + 402.0 KiB =   4.0 MiB   systemd
 10.1 MiB +   3.7 MiB =  13.8 MiB   systemd-journald

# cat /proc/meminfo |grep Mlocked
Mlocked:   0 kB

systemd uses about 7 MB of RAM. journal uses about 14 MB of RAM. None of
it is memlocked, so it can be swapped out.

> 2) Does systemd use a LOT more CPU cycles, slowing down user performance? 

$ ps aux|grep -e systemd -e journal|grep -v dbus|grep -v grep
root 1  0.0  0.0  53244  5712 ?Ss   янв29   0:56 
/usr/lib/systemd/systemd --switched-root --system --deserialize 23
root   496  0.0  0.2  97172 19052 ?Ss   янв29   0:32 
/usr/lib/systemd/systemd-journald
root   508  0.0  0.0  45184  3272 ?Ss   янв29   0:05 
/usr/lib/systemd/systemd-udevd
root   943  0.0  0.0  34684  1556 ?Ss   янв29   0:15 
/usr/lib/systemd/systemd-logind

Over the course of time (15 days uptime), all parts of systemd and
journal use 0.0% of CPU on average.

One might claim that "systemd uses 0.04% CPU which is ten times more
than upstart which uses 0.004% CPU" or something but it certainly can't
slow down user performance at all. It speeds up service start and makes
reboot VERY fast. In fact, before systemd I had no idea my servers can
reboot that fast. Unless they have VMs to stop, they actually reboot like
1-2 seconds after "reboot" command - despite tons of services running.
They also boot within 30-50 seconds after grub, something that took 2
minutes before. Certainly, boot times aren't significant on server but
when whole reboot takes 2 minutes instead of former 5 minutes, it IS
very pleasant for people who have to interrupt all that they were doing
for just 2 minutes instead of 5.

> 3) Will systemd require Gnome 3/4/5/..N to manage properly?

I don't even know what do you mean, systemd has nothing to do with
graphics environment, you can manage every aspect of it on server
without X, from text mode. In fact, I'm unaware of any graphical
instruments to manage it, documentation only explains console commands
and config files.

(only backward dependency exists - some gnome 3 features require systemd
to work)

> 4) Can systemd /var/log files (or equivalent) be logrotated?

Not quite.
It rotates automatically based on settings in /etc/systemd/journald.conf
(size-based rotation or time-based rotation, by default it's
size-rotated since journal has built-in date filter, and entries are
compressed, so time-based rotation might create very uneven files).

If you desire, you can change settings and restart
systemd-journald.service - it will read new settings on start and rotate
according to them, if they say so.

You could force rotation from logrotate, of course, but it seems pointless.

-- 

Vladimir

Re: systemd (again)

[Konstantin Olchanski]

On Fri, Feb 13, 2015 at 11:06:02PM -0800, Keith Lofstrom wrote:
> 
> Well, hm.  My questions about systemd (some may be hard to measure):
> 
> 1) Does systemd use a LOT more RAM, like > 200MB, that cannot swap out?
> 2) Does systemd use a LOT more CPU cycles, slowing down user performance? 
> 3) Will systemd require Gnome 3/4/5/..N to manage properly?
> 4) Can systemd /var/log files (or equivalent) be logrotated?
> 
> If the answers are ...
>

Why are you asking us?!?

Install SL7 or a recent Fedora and make your own measurement, draw your own 
conclusions.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: systemd (again)

[Keith Lofstrom]

On Fri, Feb 13, 2015 at 9:59 PM, Keith Lofstrom  wrote:
> If systemd is a major resource hog, ...
...

On 02/13/2015 09:06 PM, Nico Kadel-Garcia wrote:
> The difficulty is that it's creeping into levels and components that
> didn't ask for it and don't need it, and thus becoming even more
...

On Fri, Feb 13, 2015 at 10:25:23PM -0700, Orion Poplawski wrote:
> I'll be clear that there are things about systemd that do bug me, and it 
> has taken a while to grow on me, but I think too much of the discussion 
...

Well, hm.  My questions about systemd (some may be hard to measure):

1) Does systemd use a LOT more RAM, like > 200MB, that cannot swap out?
2) Does systemd use a LOT more CPU cycles, slowing down user performance? 
3) Will systemd require Gnome 3/4/5/..N to manage properly?
4) Can systemd /var/log files (or equivalent) be logrotated?

If the answers are yes/yes/yes/no, then I will dread it.  If systemd
is "merely" hard to understand and use, oh well.  If it (eventually)
grows on you, or permits significant system tuning and leads to
runtime improvements that were not easy before, I hope that usable
interfaces and understandable documentation will someday emerge.

Systemd is Red Hat's brainfart.  Their user base is institutions,
not consumer tablets.  If systemd cripples Red Hat customers,
Red Hat will either fix the behavior, or go bankrupt and stop
pushing it.  I will count on the last two correctives to keep
systemd from becoming a worst-case nightmare.  ("Red Hat?  The
Netflix Goggles software team?  Didn't they do Linux, long ago?")

Keith

-- 
Keith Lofstrom  kei...@keithl.com

Re: systemd (again)

[Orion Poplawski]

On 02/13/2015 09:06 PM, Nico Kadel-Garcia wrote:

On Fri, Feb 13, 2015 at 9:59 PM, Keith Lofstrom  wrote:

If systemd is a major resource hog, then our high-performance-
machine comrades will come up with something that leaves more
CPU cycles for doing computation over the next decade.  I hope.
Zillion-CPU computing is intolerant of expensive waste.  If RH
someday insists on intolerable resource misuse, we are in the
right community for a mutiny and a new direction.


The difficulty is that it's creeping into levels and components that
didn't ask for it and don't need it, and thus becoming even more
bloated, With extraneous binary logging, and the tools to decode the
binary logging into something useful, with dbus integration and the
latest round of multiple ring integration for Fedora applications,
it's wedging it's bulky way into places that had no need of it.


I'll be clear that there are things about systemd that do bug me, and it 
has taken a while to grow on me, but I think too much of the discussion 
gets emotional or subjective with terms like "bloated".  Someone's bloat 
could be someone else's greatly useful feature.


In particular, while perhaps the use of a binary format is debatable, 
the existence of the journal is incredibly useful.  It allows for the 
capture of so much more output from system processes that wasn't 
possible before.  And it presents it in a structured and consolidated 
way.  Running "journalctl -f -p warning" is a great way to quickly 
monitor issues on a machine.


In general I believe systemd takes system management, control, and 
monitoring to the next level.  There are growing pains, implementation 
issues, and other problems, but overall a great step forward.


Can't speak to dbus integration and I don't know what is meant by 
"latest round of multiple ring integration for Fedora applications".


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com