:: [DNG] Another Tentacle
Top Page
Delete this message
Reply to this message
Author: Ken Dibble
Date:  
To: dng
Subject: [DNG] Another Tentacle
Having a few moments, I was going through a test Chimaera system looking

for artifacts of uninstalled packages, files that should have been
deleted, etc.

As part of that process I happened on a process that  I did not know
about running.

xscreensaver-systemd

From the man page:

The /xscreensaver-systemd/ program is a helper daemon launched by
xscreensaver(1) <https://man.archlinux.org/man/xscreensaver.1.en> for
systemd(1) <https://man.archlinux.org/man/systemd.1.en> or elogind(8)
<https://man.archlinux.org/man/elogind.8.en> integration. It does two
things:

***
    When the system is about to go to sleep (e.g., the laptop lid has
    just been closed) it locks the screen just /before/ the system
    sleeps, by running /xscreensaver-command --suspend/. When the system
    wakes up again, it runs /xscreensaver-command --deactivate/ to make
    the unlock dialog appear immediately. It does this through the
    org.freedesktop.login1(5)
    <https://man.archlinux.org/man/org.freedesktop.login1.5.en> D-Bus
    interface.
***
    When another process asks for the screen saver to be inhibited (e.g.
    because a video is playing) this program periodically runs
    /xscreensaver-command/ /--deactivate/ to keep the display
    un-blanked. It does this until that other program asks for it to
    stop, or exits. It does this through the
    org.freedesktop.ScreenSaver(5)
    <https://man.archlinux.org/man/org.freedesktop.ScreenSaver.5.en>,
    org.gnome.SessionManager(5)
    <https://man.archlinux.org/man/org.gnome.SessionManager.5.en> and
    org.kde.Solid.PowerManagement.PolicyAgent(5)
    <https://man.archlinux.org/man/org.kde.Solid.PowerManagement.PolicyAgent.5.en>
    D-Bus interfaces.


According to elogind's github page:

elogind is the systemd project's "logind", extracted to be a standalone
daemon


My understanding of the documentation is that communication with elogind
should be through the

D-Bus interface.


My questions, which I am sure that I will not be able to understand the
answer to, are

Why do we have something that looks like it belongs to systemd running?

Why do we need to have a separate daemon just to put something on the
DBus interface?


Confused as usual,

Ken