[svlug] Desktop software and systems management

Rick Moen rick at svlug.org
Thu Nov 20 06:41:23 PST 2014

On Mon, Nov 17, 2014 at 12:24 PM, Paul Zander <paulz at ieee.org> wrote:

[You were unable to use shutdown controls, and the problem appeared to
involve systemd in some way.]

> Regarding the power-off / systemd issue.   After a couple of months
> without hibernate / sleep modes, I used aptitude to search for
> power-manager packages.   Three were listed: gnome, mate and xfce. I
> installed xfce4-power-manager.  After configuring the power-manager, the
> screen blanks and the disk drives shut down automatically.  Also the
> previously discussed "buttons" on the logout panel now work.  
> For the record, a different computer, which has not been upgraded in a
> long time, executed all of the power management with just ACPI and LXDE.

Congratulations on that success.

Very interesting - and revealing.  You see, I'm attempting to assess the
recent evolution of desktop software on Linux and the hullaballoo raised by
the sudden importance of systemd.  

(The following is somewhat excessive as comment on your power management
solution, but -- I hope you don't mind -- I started considering posting it
elsewhere as I wrote it.)

I encounter a lot of anti-systemd ranters (see, for example, the Web archive
of a new-ish mailing list called modular-debian), and, while being
sympathetic to their problems, keep thinking their analysis is incorrect:

They're wrong about the identity of the problem, and they're wrong about
what's a rational response.

My leading hypothesis is that the problem is a big code-hairball of system
software that has emerged from the desktop-Linux world of GNOME and is
produced by a group of coders one might call the Freedesktop.org cabal.
This includes systemd (and its development team), but _also_ includes quite
a few other software pieces that have become increasingly common and have
been making inroads into the internals of Linux-based systems.  In the years
when these guys were working on GNOME, they developed some characteristic
practices and habits:

o  The codebases are baroquely over-featured and have big, ever-changing
dependency lists.
o  The codebases get frequently thrown away (often lasting no more than six
months) and replaced by successor projects.
o  The developers have little concern about forward or backward
compatibility over time.
o  The developers have little concern over bloat or code quality.
o  The developers dismiss all complaints from users in either one of two
ways:  If you're a veteran Unix user, you are not their target market.  If
you're not a veteran, then they know better than you what is good for you.
o  The developers have no respect for keeping layers of functionality
separate (e.g., Linux sound example below) and traditional avoidance of tight
coupling of software layers (and instead rushing to commit that error).
E.g., they see absolutely nothing wrong with systems breaking completely if
you don't upgrade the kernel, the udev subsystem, and the init package in
strict lockstep, and think it's fine to tell someone who needs to run an
older kernel for whatever reason (e.g., one driver or a desire to use the
grsecurity patches) that he/she is SOL.

[Foregoing characterisation is admittedly a broad generalisation, and is
obviously IMO.]

Jamie Zawinski (jwz, coder for xemacs, xscreensaver and many other good
things, and key Netscape coder) dubbed this the Cascade of Attention-Deficit
Teenagers (CADT) model of software development in 2003 when they ignored for
years important bugs he'd filed against GNOME 2.x and 1.x, and then closed
them as WONTFIX the moment GNOME devs orphaned those branches to commence
work on GNOME3:


I myself didn't see the beginnings of this problem because I considered
GNOME a piece of baroque junk and simply avoided it.  I heard about
ridiculous misfeatures like a GNOME 'sound daemon' that worked only inside
the GNOME DE, which makes no sense because software support for sound
hardware is a low-level system function that should not depend on any
specific DE, or actually on graphics at all.  Your sound hardware should be
reachable by any sound-handling userspace software irrespective of your
graphical environment, using standard Unix devices system calls (i.e. POSIX
read, write, ioctl, etc.).  The software talks to /dev/dsp, and sound comes
out the speaker.  This should happen reliably with any graphics environment
or with no graphics environment at all.  But just avoiding GNOME sidestepped
such craziness, of which many others accumulated, e.g., see:  


The Freedesktop.org people branched out to create D-Bus, a general messaging
bus feature inside the Linux kernel*, usable as yet another novel (and
opaque) way to do interprocess communication.  Then, leveraging that, they
layered on top of that:

o  PolKit (formerly PolicyKit):   a framework for granting users access to
privileged operations

o  ConsoleKit (now deprecated in favour of systemd-logind /
systemd-loginctl):  service that tracks user sessions (i.e., where user is
logged in), allows switching users without logging out. (Many user can be
logged in on the same hardware at the same time with one user active.) Used
to check if session is 'local', i.e., if user has direct access to hardware.

o  PackageKit: software package front-end intended to introduce automatic
updates without having the authenticate as root (instead, uses PolKit),
fast-user-switching (PolKit), warnings translated into the correct locale,
common upstream GNOME and KDE tools.  Blocks system shutdown in some phases
of package operations.

o  systemd-logind / systemd-loginctl:  keeps track of users and sessions,
their processes and their idle state, provides PolKit-based access for users
to operations such as system shutdown or sleep, implements shutdown/sleep
inhibition logic for applications, handles power/sleep hardware keys, does
multi-seat management, manages session switching, regulates device access
for users, spawns text logins (gettys) on virtual console activation and
does user runtime directory management

o  udisks (now deprecated) / udisks2:  a D-Bus-based daemon to do
automounting of filesystems, enumeration / partitioning / monitoring /
configuration of storage device. Basically written as an internal GNOME
component.  As usual, when udisks was junked and replaced by udisks2,
command-line functionality was reduced and backwards compatibility broke:
Used to be taken care of by former Freedesktop.org codebase HAL

o  avahi: An implementation of IETF ZeroConf networking to auto-discover and
auto-configure services (such as printing).

o  NetworkManager: system daemon to centrally administer networking, so
that, for example, you can use it to centrally manage multiple WiFi
configurations instead of using iwconfig or wicd or wpa_supplicant

o  UPower (replaced Devicekit.power):  enumerates power devices, listens to
device events (D-Bus) and queries history and statistics. Intended to be an
interface to adjust latency of different operations on your computer, to
regulate power consumption.  Used to be taken care of by former
Freedesktop.org codebase HAL (deprecated).  Some operations (such as
suspending the system) are restricted using PolKit.

o  Sound got wrapped up in the over-engineered PulseAudio.  

o  urfkill:  Manages radio/bluetooth killswitches on laptop/mobile devices
to manage power consumption.  Used to be taken care of by former
Freedesktop.org codebase HAL (deprecated).

o  media-player-info: repository of data files describing media player
capabilities, mostly of mass-storage devices.  Used to be taken care of by
former Freedesktop.org codebase HAL (deprecated).

o  udev:  Dynamic /dev tree management software, not originally written by
these guys, but taken over by them and merged into the systemd source tree
(making it sort of separate but sort of joined at the hip to systemd).

Getting to the point: Most  of that stuff intercommunicates over D-Bus,
checks with PolKit to decide whether processes are to be permitted to do
things, and talks to udev (now part of the systemd project) to decide what
devices exist and how to talk to them.  So, it's all designed to be
event-driven and automagical - with the result that if something misbehaves
and you need to do debugging, you're pretty much screwed because it's nearly
impossible to do basic, normal troubleshooting.  There aren't the normal
procedural system scripts you would ordinarily edit, put breakpoints in, put
echo statements in, etc.  They don't exist.  Instead, you have a big,
mysterious code hairball involving some of the above-described pieces.

I was talking to a friend whose OpenSUSE laptop on which he had Oracle
running for some school classwork suddenly (two days ago) refused to boot
(on grounds that systemd services avahi and systemd-logind could not be
started for murky reasons) and he eventually had to reinstall, changing over
to Manjaro Linux (a new Arch Linux variant) on the OpenRC init to get away
from systemd, after trying to regain control and failing.  On grounds of the
very sketchy diagnostic information shown, he blamed systemd, but it's not
clear that's the piece where the problem originated, just where it
manifested.  It could have been a PolKit snafu, for example.  It's difficult
to determine - which is my point.
If my system shutdown controls failed to work the way yours did, it really
wouldn't readily occur to me that the required fix is 'You need to install
the XFCE4 power manager package'.  


'This software is a power manager for the Xfce desktop, Xfce power manager
manages the power sources on the computer and the devices that can be
controlled to reduce their power consumption (such as LCD brightness level,
monitor sleep, CPU frequency scaling). In addition, xfce4-power-manager
provides a set of freedesktop-compliant DBus interfaces to inform other
applications about current power level so that they can adjust their power
consumption, and it provides the inhibit interface which allows
applications to prevent automatic sleep actions via the power manager; as
an example, the operating system's package manager should make use of
this interface while it is performing update operations.'

Uh-huh.  See what I mean?  D-Bus interfaces to talk to the other
Freedesktop.org stuff, and deciding whether or not it's appropriate to
permit you to do the shutdown that you just told the system to do.
Personally, I regard shutdown as a fundamental system-level administrative
function that needs to Just Work, and, if it doesn't, my _own_ instinct
would be to start ripping out chunks of suspect system code that appears to
be standing in the way of normal, expected functionality.

Getting to my larger point:  I'm basically a server guy.  I expect that
processes start and stop when the admin tells them to, not when systemd and
PolKit decide.[0]  I expect filesystems mounted if and where I mount them,
not if and where an automounter (udisks/udisks2) decides.  I expect the
system to come up without fail even if two individual services (like avahi
and systemd-logind) have a problem.  I expect shutdown to occur when I
order shutdown.  And I need transparent, predictable, simple architecture
for reasons of security and management.

Those desirable traits go away if service startup is baroque, difficult to
debug, and involves murky event-driven communication among numerous obscure
system components I have no reason to trust.

And it's not systemd.  It's the whole interlocking, tight-coupled code

The proper remedy isn't shouting about how evil systemd is.  (It's not;
it's just a somewhat IMO inept, well intended, but overdesigned attempt to
tie in to a similarly overdesigned and similarly dodgy set of other
Freedesktop.org system pieces primarily for the convenience of desktop
Linux computing.)  The proper remedy isn't to urge political General
Resolutions against excessive init software coupling on Debian, like the
one that a poll of Debian developers just decided not to hold.  The proper
remedy isn't to scurry off to a new distribution.  The proper remedy isn't
calling a systemd package maintainer nasty names until he quits
The proper remedy isn't swarming a Redditor when he merely asks about
The proper remedy isn't to offend Joey Hess so badly with toxic politics
and abuse of distro governance (e.g., politically twisted GRs) that he
resigns from Debian.

IMO, it's to test and use combinations of packages (like some of Thomas
Glaser's prevent-* metapackages on
http://users.unixforge.de/~tglaser/debs/debidx.htm), and methods of system
management, that avoid the Freedesktop.org code hairball, without ranting,
without General Resolutions, without forking of distros.  This might mean
selecting and 'pinning' into place the OpenRC init package, for example.
(I'm warming to OpenRC.)  It might involve eschewing GNOME3 and XFCE4 if
their dependencies via systemd-logind[1] on the rest of the code hairball
become difficult to avoid (e.g., if the systemd-shim kludge ceases to be
maintained), but no big loss there.

Because Unix systems you have difficulty troubleshooting, hacking, and even
controlling and understanding (not to mention ensuring security of) are a
problem, especially for us server people.  And actually, the init part of
systemd is pretty good for an event-driven init -- a point that the
uselessd fork (systemd pared down to just the good bits) is making quite
clearly.  And contrary to many critics' claims, the init part is quite well
documented - but isn't where the problem lies.  Thus my point.

And, yeah, cgroups sandboxing is a cool Linux-only feature, but you don't
need systemd to manage it.  (IIRC, systemd being present prevents you from
managing them with anything else, though.)

RHEL7 is looking to be a problem, but that's not really deployed anywhere
significant, yet.

[0] If I want to supervise services and ensure their state, I can use
service managers of which there are a number of good choices including
runit, s6, etc.  I don't need the init to do that whether I want it to or

[1] Technically, GNOME3 doesn't yet absolutely require systemd-logind,
because instead it can use ConsoleKit, but the latter is moldy and

*Author of this posting noted this statement as an edit error, in 
a follow-up posting immediately after this one.  D-Bus is userspace; 
proposed replacement kdbus would be kernel-level.

More information about the svlug mailing list