upcoming "systemd --user" dependency in gnome-settings-daemon
- From: Bastien Nocera <hadess hadess net>
- To: desktop-devel-list gnome org
- Subject: upcoming "systemd --user" dependency in gnome-settings-daemon
- Date: Thu, 12 May 2016 18:06:01 +0200
Hey,
"systemd --user" has been enabled in Fedora 24 beta, which will ship
with GNOME 3.20. For GNOME 3.22, I'd like to make some changes in
gnome-settings-daemon, first in the sharing plugin, then in gnome-
settings-daemon itself.
Now
===
When I implemented the per-network sharing for UPnP/DLNA, VNC and
WebDAV services:
http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html
it was always the plan to switch to a better way of tracking the
services that gnome-settings-daemon would start.
When gnome-settings-daemon crashes, it loses track of the services it
started, and cannot stop them when it should, when switching networks.
It is a potential privacy problem.
The bug for gnome-settings-daemon is here:
https://bugzilla.gnome.org/show_bug.cgi?id=766329
The necessary changes in rygel, vino and gnome-user-share are in the
blocking bugs.
Then
====
The second part of the plan for using "systemd --user" is probably a
bigger problem for non-systemd operating systems [1].
gnome-settings-daemon, to avoid inter-dependency between plugins,
ordering problems, and making it easier to disable and debug some parts
separately, is using D-Bus internally, and to offer those features
externally.
For example, both the media-keys plugin and the orientation plugin use
the xrandr plugin's D-Bus interface to rotate the screen, the former
for the laptop multimedia key, the latter for the accelerometer in
tablets.
Because the gnome-settings-daemon code interacts with so many different
services to implement policy and hardware enablement[2], it's not
uncommon for one particular plugin to cause gnome-settings-daemon to
crash.
This has consequences, such as, on X11, losing the default theme, font
and hi-dpi setting, even though something other than the XSettings
plugin crashes. Or network-facing services not being tracked any more.
Or the desktop-wide keyboard shortcuts not working any more.
So, I intend to use systemd to launch each gnome-settings-daemon plugin
as a separate service, which would be tracked, and relaunched through
"systemd --user":
- the "org.gnome.settings-daemon.plugins.* active" boolean would be
replaced by a call to "systemctl disable foo.service"
- inconsiderate uses of sync calls, crashes and memory leaks will be
easier to debug, and will stop affecting other parts of the system
- start-up will be heavily parallellised
- the wacom plugin won't eat memory on the user's system unless a Wacom
tablet is plugged in, or the orientation plugin without an
accelerometer
- the housekeeping plugin can be run at a regular interval, as
configured
- plugins that are only useful on X11 can be disabled on Wayland
I plan to work on this for the GNOME 3.22 release, though postponement
is a possibility, depending on the hurdles we encounter.
I expect that only gnome-settings-daemon and gnome-session would need
changes to implement this feature.
Comments?
I'd be especially interested in hearing from non-Linux developers about
what their plans would be.
Cheers
[1]: I have no interest, personally, supporting the fringe, non-
systemd, Linux distributions. Not using systemd is much more work for
me, and I'm not even talking about when the features just can't be
implemented on a paper-and-glue-quality init system.
[2]: It will interact with your keyboard, screen, accelerometer, sound
cards, buttons on USB speakers and Bluetooth headsets, Wacom tablets,
network, VNC, location, colour sensors, batteries, wireless
killswitches, and smartcards.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]